Strumenti per sviluppatori · Generatore UUID
RFC 4122 vs RFC 9562: cosa è cambiato nello standard 2024 UUID
· Sfondo
uuid crittografia API del browser
Vengono citati due RFC per gli UUID e non dicono esattamente la stessa cosa. Questo post illustra ciò che RFC 9562 ha aggiunto, chiarito e deprecato rispetto a RFC 4122.
Quale RFC cito? — la confusione quando la documentazione e le biblioteche fanno riferimento a standard diversi
Due RFC vengono regolarmente citate nella documentazione UUID e non dicono cose identiche. RFC 4122, pubblicato in 2005, ha definito gli UUID e le loro cinque versioni (da v1 a v5). RFC 9562, pubblicato in 2024, rende completamente obsoleto RFC 4122, chiarisce le ambiguità su cui hanno lavorato i professionisti, aggiunge tre nuove versioni (v6, v7, v8) e aggiorna le linee guida sull'implementazione della casualità. Quando una libreria cita RFC 4122, non è sbagliato: quella libreria potrebbe essere stata rilasciata prima che RFC 9562 fosse pubblicato oppure i manutentori potrebbero non avere la documentazione aggiornata. Il controllo delle citazioni RFC ti dice quando una libreria è stata aggiornata in modo significativo l'ultima volta. Quando si scrivono nuove specifiche o si valutano implementazioni, RFC 9562 è il riferimento normativo.
Obsoleto, non sostitutivo del formato: tutto ciò che è valido in RFC 4122 rimane valido; il layout e i bit della variante rimangono invariati
RFC 9562 formalmente obsoleto RFC 4122 come documento di riferimento corrente pur mantenendo la familiare rappresentazione 128 bit, i gruppi esadecimali, la posizione della versione e il layout della variante principale. Non è necessario riemettere le stringhe UUID memorizzate esistenti semplicemente perché esiste una RFC più recente. La migrazione pratica riguarda la documentazione, i generatori e la politica di validazione: citare lo standard attuale, comprendere le versioni aggiunte e verificare se il vecchio codice si basava su un'ambiguità chiarita dalla revisione. La compatibilità dovrebbe comunque essere testata ai limiti del sistema, in particolare laddove una libreria serializza le strutture Microsoft GUID o impone un insieme di versioni più ristretto rispetto a quello descritto dallo standard.
Tre nuove versioni: v6 (tempo riordinato), v7 (epoca Unix ordinata) e v8 (definito dall'implementazione)
RFC 9562 aggiunge tre nuove versioni allo standard. La versione 6 riordina i bit del timestamp v1 per produrre identificatori ordinabili lessicograficamente per migliori prestazioni del database. La versione 7 utilizza un timestamp Unix in millisecondi 48-bit seguito da bit casuali, fornendo una generazione ordinata nel tempo senza i problemi di privacy della v1. La versione 8 è una via di fuga per layout definiti dall'implementazione. Nessuna di queste versioni altera il funzionamento delle versioni v1-v5 o il loro significato. Un v1 UUID da 2005 e un v7 UUID da 2024 possono coesistere nello stesso database, ciascuno con i suoi bit di versione che ne identificano il metodo di generazione. Le tre nuove versioni affrontano modelli comuni emersi nella pratica.
Max UUID si unisce a Nil: il valore tutto-F definito insieme a quello tutto-zero
RFC 4122 ha documentato il valore Nil UUID (tutti i bit zero) come valore di riferimento speciale negli esempi e nella documentazione. RFC 9562 include la stessa definizione Nil ma definisce formalmente il massimo UUID (tutti i bit impostati su uno) per i limiti dell'intervallo. Né Nil né Max sono una versione 4 casuale UUID perché non hanno bit di versione e variante corretti. Il valore massimo UUID è utile come limite superiore dell'intervallo nelle query del database: WHERE uuid_column <= MAX_UUID corrisponde a tutti gli UUID possibili. Nil è utile come sentinella per le colonne non assegnate UUID nullable. RFC 9562 documenti entrambi senza obbligarne l'uso nei dati dell'applicazione.
Linee guida chiarite: consiglio esplicito di utilizzare CSPRNG per campi casuali, su contatori monotonici entro un millisecondo e di preferire versioni ordinate cronologicamente per la località del database
La guida alle best practice di RFC 9562 distingue la resistenza alle collisioni dall'imprevedibilità. I campi casuali devono utilizzare un'origine appropriata al modello di minaccia dell'applicazione e l'opacità sensibile alla sicurezza richiede un CSPRNG. I generatori basati sul tempo hanno un problema di monotonia separato quando diversi identificatori condividono un tick di timestamp; lo standard descrive i contatori e la precisione aggiuntiva del timestamp come metodi possibili, ciascuno con regole di stato e rollover. Le versioni basate sul nome rimangono identificatori deterministici, non prove di autenticità. Questi chiarimenti sono importanti perché un parser UUID può accettare tutti i layout anche se i requisiti di generazione e le proprietà di divulgazione delle informazioni differiscono.
Dove vengono visualizzate le idee di ULID: in che modo il formato della community ha influenzato il design di v7
RFC 9562 afferma che i suoi autori hanno analizzato diversi schemi di identificatori ordinabili esistenti, tra cui ULID, Snowflake e KSUID, durante lo sviluppo dei nuovi layout. Ciò supporta una conclusione modesta: la richiesta operativa di identificatori distribuiti e ordinati nel tempo ha informato la revisione. Ciò non prova che un formato della comunità abbia donato un layout di campo esatto alla versione 7. La somiglianza pratica è sufficiente per il lavoro di architettura: queste famiglie collocano le informazioni temporali in primo piano in modo che l'ordinamento ordinario possa preservare un ampio ordine di creazione, quindi differiscono nella codifica, nella coordinazione e nel comportamento all'interno dei tick. Scegli tra loro in base alla compatibilità dell'ecosistema e alle garanzie documentate piuttosto che a una rivendicazione di discendenza diretta.
Ciò che questo non copre: una differenza riga per riga; questo post segue le conseguenze pratiche per gli implementatori
Questo post completo segue le conseguenze pratiche e l'implementazione di RFC 9562 per gli implementatori e gli utenti, non le differenze riga per riga con RFC 4122. Le specifiche complete sono disponibili presso gli organismi di standardizzazione e vale la pena leggerle per implementare la gestione di UUID in linguaggi o piattaforme: il testo fornisce dettagli autorevoli oltre ciò che una panoramica può coprire. Questo post non descrive i meccanismi a livello di bit di come v6 riordina i byte v1 o di come v7 codifica i millisecondi Unix. Sia gli standard che le guide di implementazione rimangono il principale riferimento autorevole per qualsiasi questione di implementazione riguardante il layout dei bit, la codifica o la verifica della conformità.
Conclusione: aggiorna le tue citazioni e le tue impostazioni predefinite: il generatore ToolAcre segue la guida CSPRNG condivisa da entrambe le RFC
Per qualsiasi nuovo lavoro, aggiorna la documentazione e le specifiche per citare RFC 9562. Ogni UUID da RFC 4122 rimane valido sotto RFC 9562: la migrazione è puramente lungimirante e di natura amministrativa. Le linee guida chiarite sulla casualità crittografica rafforzano il fatto che gli identificatori devono provenire da fonti crittograficamente sicure nei sistemi di produzione. ToolAcre segue le indicazioni sulla casualità crittografica di entrambe le RFC, utilizzando esclusivamente Web Crypto API del browser. Quando incontri un UUID da log, esportazioni di database o risposte API, il controllo ben formato ToolAcre segnala la sua versione e variante rispetto a RFC 9562. RFC 9562 è il chiarimento e la modernizzazione di uno standard già stabile.