X (Twitter) Decodificatore di Snowflake ID

Introduzione

Ogni post su X porta un ID numerico, e quel numero non è casuale. Dal novembre 2010 X costruisce gli ID dei tweet nel formato snowflake — un intero a 64 bit che impacchetta l'ora esatta di pubblicazione, l'identità della macchina generatrice e un contatore di sequenza in un unico numero ordinabile. Il X (Twitter) Decodificatore di Snowflake ID di Toollect spacca quel numero — incolla un ID di tweet, 2089759704335482961, e restituisce l'istante preciso di pubblicazione, 18 agosto 2026 alle 17:01:54.028 UTC, insieme al numero di worker, alla sequenza e alla struttura binaria completa dell'ID.

Incollare invece un link di stato completo funziona allo stesso modo — il decodificatore estrae prima l'ID dalla URL, così https://x.com/jack/status/2089759704335482961 e il numero nudo producono risultati identici. In entrambi i casi appaiono otto righe di risultato mentre scrivi — quattro che descrivono quando (ora locale, UTC, ISO 8601 e millisecondi Unix, più un'età relativa compatta) e tre che descrivono cosa dicono i bit (worker ID, sequenza e il binario completo a 64 bit).

La decodifica è aritmetica di bit pura, non una consultazione. Nulla viene inviato a X, non serve chiave API e non esiste limite di richieste — il calcolo gira nel tuo browser mentre scrivi, e lo stesso ID si decodifica nello stesso istante ovunque nel mondo, per sempre.

Casi d'uso

Un numero che registra di nascosto il proprio momento di nascita si rivela utile in più lavori di quanti ci si aspetterebbe.

Giornalismo e verifica

Screenshot, repost e citazioni staccano un post dal suo ritmo originale. Decodificare l'ID lo ripristina — il millisecondo esatto della creazione è scritto dentro il numero, indipendentemente da ciò che la pagina intorno sostiene. I fact-checker lo usano per stabilire se un post precede o segue l'evento di cui parla — l'ID non si può modificare dopo, a differenza del testo attorno.

Analisi dei dati e archivi

Ordinare gli ID numericamente significa ordinare i post cronologicamente — senza bisogno di una colonna di timestamp. Gli analisti che esportano ID di tweet da API o dataset usano il decodificatore per ancorare quegli ID a date di calendario, individuare buchi di raccolta e deduplicare archivi dove lo stesso tweet è arrivato attraverso più forme di URL ma portava sempre lo stesso numero.

Moderazione e ricerca

Esaminando un'onda di attività, la riga relativa dà subito un senso della scala — minuti contro mesi — senza leggere i timestamp ad alta voce. I ricercatori che studiano i pattern di cancellazione o i comportamenti di ripubblicazione decodificano intervalli di ID per ricostruire linee temporali che non esistono più pubblicamente.

Sviluppatori e integrazioni

Il codice che memorizza ID di tweet spesso ha bisogno di un controllo di sanità durante lo sviluppo — questa costante è davvero un ID plausibile, e quale momento dichiara di essere? Incollare il valore qui risponde con una pressione, e copiare l'output ISO scende dritto in log, fixture o semi di database.

Come funziona

Lo strumento lavora mentre scrivi — non c'è nessun bottone. Ogni tasto percorre gli stessi quattro passaggi:

1. Classificare l'input — il testo viene confrontato con due forme — uno snowflake nudo di 15-19 cifre o un link di stato x.com/twitter.com che lo porta. Tutto il resto mostra il messaggio di input non valido.
2. Estrarre l'ID — da una URL viene ignorato tutto tranne la rotta di stato e il numero — sottodomini, varianti di vista come /photo/1 e parametri di query non raggiungono mai il calcolo.
3. Decodificare i bit — spostamenti BigInt tirano fuori timestamp, worker e sequenza dall'intero a 64 bit, e l'epoca di Twitter viene aggiunta per trasformare l'offset grezzo in una data vera — l'aritmetica è posata nel capitolo Come funziona la decodifica.
4. Validare la finestra — un ID il cui tempo decodificato cadde oltre un minuto nel futuro viene rifiutato invece che mostrato, così i numeri digitati male o inventati falliscono rumorosamente invece di produrre una data assurda in tutta sicurezza.

Tutto accade localmente in ben meno di un millisecondo. La finestra di validazione è l'unico giudizio del flusso, e pende verso il rifiuto — un numero che dice di essere pubblicato domani non è un tweet.

Formati di input supportati

Due famiglie di input si decodificano, e tutto il resto viene rifiutato con un messaggio chiaro. Il contratto è volutamente stretto — questo strumento fa una cosa a un solo genere di numero.

Formati accettati

Entrambi i domini — x.com e twitter.com — si comportano identicamente su tutte le forme di host, il prefisso https:// è facoltativo, e barre finali, varianti foto o video e stringhe di query vengono tollerate e scartate. Arrivi come arrivi, l'ID estratto è lo stesso — l'output decodificato è identico al byte sulle sette righe della tabella.

Formati rifiutati

Due rifiuti meritano una spiegazione. La rotta dell'app web x.com/i/web/status/… appare quando il client a pagina singola riscrive internamente gli indirizzi, ma omette il segmento del nome utente, quindi non entra nella grammatica sopra — incolla la forma canonica e lo stesso ID si decodifica normalmente. E guarda bene l'ultima riga — un ID di Discord supera il controllo di lunghezza e si decodifica verso una data di aspetto plausibile. Il decodificatore non può individuarlo, e quel limite è documentato onestamente invece di essere truccato.

Anatomia di un Snowflake ID

Uno snowflake è un intero a 64 bit tagliato in quattro campi. Leggendo dal bit più significativo:

L'epoca

I timestamp non contano dal 1970 — contano dal 4 novembre 2010 alle 01:42:54.657 UTC, il momento in cui il servizio snowflake ha sostituito gli ID sequenziali. Scegliere un'epoca fresca tiene piccolo il campo del timestamp — 41 bit contengono circa 2.200 miliardi di millisecondi, circa 69,7 anni di margine. Il formato quindi si esaurisce solo nel luglio 2080 — comodamente lontano, e uno dei motivi per cui il campo non può essere allargato senza rompere tutti i client esistenti.

Un esempio lavorato

Prendi l'ID usato in tutti gli strumenti X di questo sito — 2089759704335482961. Tagliato ai confini dei campi, si legge a colpo d'occhio ogni valore che il decodificatore stampa:

Lo zero iniziale nella riga del timestamp è il bit del segno, sempre zero. Ogni riga di output deriva da questo unico taglio — i bit del timestamp diventano l'istante di pubblicazione, il campo worker nomina la macchina 376, e la sequenza mostra che era l'ID numero 81 coniato da quella macchina in quel millisecondo.

Quantità di ID che ci stanno

La sequenza a 12 bit consente fino a 4.096 ID per macchina al millisecondo, e il campo worker a 10 bit nomina fino a 1.024 macchine. In pratica, la sequenza sale raramente vicino al suo tetto — esiste perché le raffiche, non il totale, non collidano mai. Due ID della stessa macchina nello stesso millisecondo differiscono solo in questi dodici bit bassi.

La cronologia delle cifre

Poiché il timestamp occupa i bit alti, il valore totale cresce senza sosta — il numero di cifre decimali dice più o meno quando un ID è stato coniato:

Per questo il decodificatore accetta da 15 a 19 cifre e nient'altro — 15 copre i primissimi post dell'era snowflake, 19 tutto ciò che è stato coniato dal 2018, e nessun ID legittimo di tweet è mai uscito da quell'intervallo.

Come funziona la decodifica

La matematica sono tre operazioni — uno spostamento, due maschere e una somma:

const TWEET_EPOCH = 1288834974657n;           // 2010-11-04T01:42:54.657Z in ms Unix

timestampMs = Number((id >> 22n) + TWEET_EPOCH);
workerId    = Number((id >> 12n) & 1023n);    // i 10 bit bassi del campo centrale
sequence    = Number(id & 4095n);             // i 12 bit bassi

Spostare di 22 bit a destra butta via i campi worker e sequenza e lascia l'offset del timestamp dall'epoca propria; aggiungere l'epoca lo converte in normali millisecondi Unix. Le maschere isolano poi i due campi bassi — & 1023 conserva dieci bit, & 4095 dodici. Rielaborando l'esempio, 2089759704335482961 spostato dà un offset di 498237539371 millisecondi, che sommato all'epoca vale 1787072514028, cioè 2026-08-18T17:01:54.028Z; il worker mascherato è 376 e la sequenza 81.

Due dettagli di precisione contano. Primo, lo strumento fa tutta l'aritmetica in BigInt, perché un ID a 19 cifre supera l'intervallo intero sicuro di JavaScript (9.007.199.254.740.991) e un numero normale arrotonderebbe silenziosamente i bit bassi — corrompendo proprio i valori di worker e sequenza che lo strumento riporta. Secondo, una volta convertito, il timestamp risultante sta comodamente nell'intervallo sicuro, così presentarlo come numero ordinario a Date non perde nulla.

Un'altra cosa che vale la pena sapere — altre piattaforme tagliano quegli stessi 22 bit bassi diversamente, e i decodificatori generici li etichettano spesso con i nomi dei campi di un altro sistema:

Se uno strumento ti mostra il tuo ID di tweet diviso tra workerOrShard e processId, sta applicando le etichette di Discord ai bit di X — i numeri si calcolano, ma un tweet non ha un campo processo, e i dodici bit bassi sono un contatore di sequenza, non un identificativo di processo. Questo decodificatore resta sui campi che X definisce davvero.

Uso

Quattro passaggi, nessun bottone:

1. Incolla il tuo input — un ID di tweet nudo, o qualsiasi link di stato x.com/twitter.com nelle forme elencate sopra.
2. Leggi il gruppo dei tempi — ora locale, UTC, ISO 8601 e millisecondi Unix si riempiono all'istante, e la riga relativa dà l'età a colpo d'occhio.
3. Leggi il gruppo dell'anatomia — worker ID, sequenza e il binario raggruppato mostrano com'è costruito il numero.
4. Copia ciò che ti serve — ogni riga ha il suo pulsante di copia; la riga ISO scende pulita in fogli di calcolo e log.

L'input invalido svuota le righe e mostra una singola riga di errore; correggere l'input cancella l'errore con la stessa automaticità.

Tutorial

Percorri una decodifica dall'inizio alla fine.

Passaggio 1 — Decodificare un ID nudo. Incolla 2089759704335482961 nell'input. Il gruppo dei tempi si riempie subito — riga ISO 2026-08-18T17:01:54.028Z, riga Unix 1787072514028 — e il gruppo dell'anatomia riporta worker 376, sequenza 81, con il binario nei suoi gruppi 42/10/12.

Passaggio 2 — Decodificare da un link completo. Svuota l'input e incolla https://x.com/jack/status/2089759704335482961?s=20&t=abc. I parametri di tracciamento non cambiano nulla — ogni riga si legge identica al passaggio 1, perché solo la rotta di stato e l'ID sopravvivono all'estrazione.

Passaggio 3 — Confermare l'indipendenza dal dominio. Incolla https://www.twitter.com/someone/status/2089759704335482961/ — il vecchio dominio con prefisso del nome utente e barra finale. Stesso ID, stesso timestamp. Come arriva il link, il numero che porta dentro è l'unica fonte di verità.

Passaggio 4 — Vedere fallire un ID impossibile. Incolla 20 — l'ID del primo tweet mai pubblicato, dall'era precedente allo snowflake. Il decodificatore lo rifiuta — due cifre non possono portare un timestamp codificato, perché quell'ID fu emesso anni prima che il formato esistesse. Il rifiuto è corretto, non un bug.

Passaggio 5 — Portare l'output dove serve. Premi il pulsante di copia della riga ISO e incolla in una cella del foglio di calcolo — 2026-08-18T17:01:54.028Z si ordina cronologicamente come testo, sopravvive ai viaggi di andata e ritorno CSV e non ha bisogno di contesto di fuso orario per essere letto.

Consigli pro

• Ordinare per ID è ordinare per tempo. Ovunque gli ID di tweet vivano in una colonna — esportazioni, database, log — l'ordine per ID è l'ordine cronologico. Il decodificatore aiuta a etichettare quell'ordine con date vere.
• Preferisci la riga ISO per l'archiviazione. L'ora locale dipende dalle impostazioni del dispositivo di chi legge; ISO 8601 con il suffisso Z è inequivocabile ovunque e si ordina bene come testo semplice.
• UTC per i team tra fusi orari. Quando un archivio copre continenti, mettetevi d'accordo sulla riga UTC e nessuno discuterà se il post ha attraversato la mezzanotte.
• Usa la riga relativa per il triage. Ripassando un lotto di ID, l'età compatta — 3h, 2d, 5mo — separa il fresco dal vecchio più veloce che leggere date complete.
• La riga binaria è materiale didattico. Mostrare a qualcuno quali bit sono esattamente il timestamp fa scattare tutto il formato più veloce di qualunque diagramma.
• Abbinalo al parser di URL. Il parser pulisce e canonizza i link; il decodificatore li data. Passa lo stesso link di stato per entrambi ed esci con una URL ordinata e un timestamp verificato.

Alternative

In quali altri modi un ID di tweet può diventare una data?

Decodificare a mano significa potenze del due e lunghe catene binarie — fattibile una volta, tedioso per sempre, e un bit slittato rovina la data. I decodificatori online generici puntano spesso prima a Discord, etichettano male i campi X e a volte sbagliano epoca, e comunemente inviano l'ID a un server. Questo strumento esegue l'aritmetica esatta in locale, etichetta i campi come X li definisce e rifiuta gli input impossibili invece di mostrare un anno falso in tutta sicurezza.

Contro le API ufficiali

Leggere un'ora di creazione è il raro caso in cui la via ufficiale è strettamente peggiore:

Dal febbraio 2026, l'API di X è a pagamento per uso senza piano gratuito — ottenere created_at anche per un solo tweet costa denaro ed exige credenziali registrate. oEmbed restituisce HTML renderizzato per l'incorporamento, senza un campo di timestamp strutturato analizzabile in modo affidabile. L'aritmetica snowflake consegna lo stesso millisecondo gratis, offline e per sempre — il prezzo è che non rivela nulla oltre il numero stesso, precisamente il limite documentato sotto.

Decodificatore vs. parser di URL

Toollect spedisce due strumenti X che leggono entrambi link di stato e conoscono entrambi gli ID snowflake. Rispondono a domande diverse:

Il parser è il generalista dei link; il decodificatore, lo specialista dei numeri. La sua accettazione di URL complete è una comodità — appena un link chiede pulizia, digitazione o spiegazione, è territorio del parser, e i due strumenti si passano il testimone pulitamente all'ID.

Cosa non fa

I limiti valgono la pena di essere nominati perché il decodificatore non venga mai fidato troppo:

• Non va a prendere nulla. Zero richieste — lo strumento non può vedere se il tweet esiste ancora, chi l'ha scritto o cosa dice. Dall'ID esce solo ciò che vi è stato infornato alla nascita.
• Non può invertire la conversione. Riportare una data a un ID fabbrica un numero che nessun tweet ha mai ricevuto — apri x.com/i/status/{fabbricato} e X risponde che la pagina non esiste. Gli ID sintetici hanno servito solo come soglie di paginazione nella vecchia API gratuita; sul web di oggi, gli operatori di ricerca per data fanno quel lavoro direttamente.
• Non distingue le piattaforme. Uno snowflake di Discord condivide la struttura e qui si decodifica senza errori — a una data in anticipo di circa quattro anni, perché Discord conta dal 2015. Se l'input viene da un'altra piattaforma, considera l'output sbagliato per costruzione.
• Non decodifica gli ID anteriori al 2010. I tweet più vecchi del servizio snowflake portano piccoli numeri sequenziali senza orologio incorporato — letteralmente non c'è niente da decodificare.
• Non indovina. Un input che non corrisponde a nessuna forma accettata mostra il messaggio di errore invece di un risultato parziale.

Risoluzione dei problemi

Privacy e gestione dei dati

Questo decodificatore opera sotto il modello di privacy più rigoroso del sito — non effettua nessuna richiesta di rete.

• Nulla viene caricato. Decodificare è aritmetica di bit nel tuo browser. L'ID o il link che incolli non raggiunge mai alcun server.
• Nessun account, nessuna analitica, nessuno script di terze parti. La pagina esegue solo il proprio codice.
• Nulla viene conservato. Niente cookie, nessuno stato tra le visite — chiudi la scheda e la sessione sparisce.

Per i flussi di lavoro che coinvolgono ID da archivi privati, dataset di ricerca o code di moderazione, la decodifica avviene interamente sul tuo dispositivo.

Specifiche tecniche

Dettagli:

• Formato — snowflake a 64 bit — segno (1 bit) + timestamp (41 bit, ms dal 2010-11-04T01:42:54.657Z) + worker (10 bit) + sequenza (12 bit)
• Precisione — aritmetica BigInt capillare; risultati esatti per tutti gli ID a 19 cifre oltre l'intervallo intero sicuro di JavaScript
• Finestra di validazione — il tempo decodificato non può superare quello attuale oltre i 60 secondi; i valori anteriori all'epoca sono irraggiungibili da 15 cifre in su
• Formati di input — \d{15,19} nudo, o URL di stato x.com/twitter.com con protocollo opzionale, sottodomini www./mobile./m., varianti di vista e stringhe di query
• Output — ora locale, stringa UTC, ISO 8601, millisecondi Unix, età relativa, worker ID, sequenza, binario a 64 bit raggruppato — ogni riga copiabile individualmente
• Elaborazione — JavaScript 100% lato client, zero richieste di rete, nessuna chiave API, nessun componente server
• Supporto browser — tutti i browser moderni (BigInt e Clipboard API)

Caratteristiche

• Decodifica qualsiasi ID snowflake di X o Twitter nel suo momento esatto di pubblicazione, al millisecondo
• Accetta ID di tweet nudi e link di stato completi su x.com o twitter.com — l'ID viene estratto automaticamente
• Presenta l'istante decodificato in quattro modi — ora locale, UTC, ISO 8601 e millisecondi Unix
• Scompone l'ID nelle sue parti — worker ID, contatore di sequenza e binario completo a 64 bit
• Rifiuta i valori impossibili — gli ID con data futura mostrano un errore invece di una supposizione
• Funziona interamente nel tuo browser senza richieste di rete — senza chiave API né account
• Copia con un clic per ogni riga di risultato

Domande frequenti