Strumenti per sviluppatori · Generatore UUID
UUID Versioni da 1 a 8 Spiegazione: quale dovresti generare?
· Sfondo
uuid crittografia API del browser
Otto versioni condividono lo stesso formato ma risolvono problemi diversi: ordinamento temporale, riproducibilità, casualità o layout personalizzati. Questo post spiega ciascuno e fornisce un percorso decisionale.
Un formato, otto ricette: perché la versione bocconcino è importante quando si sceglie una funzione di libreria
Lo standard UUID definisce un formato 128 bit come trentasei caratteri esadecimali con trattini. RFC 9562 definisce otto ricette distinte, versioni da uno a otto, per riempire quei bit con modelli e significati diversi. La versione nibble (primo carattere del terzo gruppo) identifica quale metodo ha prodotto il valore, fungendo da etichetta. Scegliere la versione sbagliata significa archiviare informazioni temporali non necessarie, mancare le garanzie di ordinamento per le prestazioni del database o fraintendere i ruoli di sicurezza degli identificatori. Questo post illustra ogni versione, quali problemi concreti risolve, quando gli sviluppatori lo incontrano nella pratica e fornisce un quadro decisionale per selezionare la versione giusta per i requisiti di sistema specifici.
v1 e v6: tempo più nodo: il layout originale basato sul tempo e la versione riordinata che ordina correttamente
La versione 1 combina un timestamp 60 bit con un identificatore di nodo (originariamente un indirizzo MAC, sebbene le implementazioni moderne utilizzino valori casuali per evitare perdite di informazioni sull'hardware). Il timestamp registra intervalli di 100-nanosecondi da ottobre 15, 1582. Il campo del nodo può rivelare quando l'identificatore è stato generato e dove ha avuto origine geograficamente, motivo per cui le implementazioni moderne evitano gli indirizzi MAC. La versione 6 riorganizza lo stesso timestamp e le stesse informazioni sul nodo per migliorare l'ordinabilità spostando i bit temporali di ordine superiore in primo piano, facendo in modo che gli UUID v6 vengano ordinati correttamente in ordine lessicografico. Se la tua applicazione necessita di UUID ordinati naturalmente in base all'ora di creazione con una località dell'indice superiore, la v6 è la scelta moderna.
v2: DCE Sicurezza: la variante usata raramente che incorpora gli identificatori POSIX
La versione 2 viene utilizzata raramente nei nuovi sistemi. Incorpora gli identificatori di utenti o gruppi POSIX nel layout UUID, rendendolo utile solo in ambienti legacy in cui tali identificatori hanno un significato organizzativo. Il design v2 presuppone un modello di elaborazione specifico (DCE Sicurezza) che non è comune nei moderni sistemi distribuiti. La maggior parte delle organizzazioni associa gli UUID a utenti o gruppi nel proprio livello di applicazione tramite join di database o tabelle di ricerca, non codificando l'ID utente nell'identificatore stesso. Questa separazione delle preoccupazioni semplifica la modifica dei modelli di autorizzazione, la migrazione dei dati degli utenti e la gestione degli audit trail. La codifica delle credenziali direttamente negli UUID crea un accoppiamento stretto e rende i sistemi più difficili da evolvere.
v3 e v5: basati sul nome: ID deterministici sottoposti ad hashing da uno spazio dei nomi e un nome con MD5 o SHA-1
Gli UUID delle versioni 3 e 5 sono deterministici: lo stesso spazio dei nomi e lo stesso nome producono sempre lo stesso identificatore, ideale per rappresentare mappature stabili da dati esterni. La versione 3 utilizza MD5 e la versione 5 utilizza SHA-1 come algoritmi hash, riflettendo le rispettive età e adozione. Quando un record cliente arriva per l'importazione, un UUID v5 derivato da uno spazio dei nomi fisso sarà identico in più esecuzioni di importazione, impedendo record duplicati. Questo determinismo significa che UUID è riproducibile e prevedibile per chiunque conosca lo spazio dei nomi e l'input. Il valore pratico emerge negli scenari di integrazione dei dati: riconciliazione dei record dei clienti da più sistemi, prevenzione dei duplicati nelle importazioni ricorrenti e assegnazione di ID stabili agli articoli.
v4: casuale — 122 bits da un CSPRNG e la scelta predefinita al momento dell'ordine non ha importanza
La versione 4 è la scelta predefinita quando non è richiesto l'ordine e si desidera una generazione indipendente senza coordinamento centrale. Un UUID v4 è composto da 122 bits da una fonte casuale crittograficamente sicura, con sei bit impostati su valori fissi (versione nibble 4 e RFC 9562 bit variante 10). Il punto centrale è la casualità: ogni chiamata produce un valore diverso, le collisioni rimangono estremamente improbabili e non è richiesto alcuno stato o coordinamento esterno. È la versione che ToolAcre genera utilizzando crypto.randomUUID() o crypto.getRandomValues(). Questa versione è adatta per riferimenti a oggetti, dati non strutturati e la maggior parte dei ruoli al di fuori delle chiavi primarie o dei contesti di ordinamento.
v7 e v8: Unix time and custom: la moderna versione cronologica per le chiavi del database e la via di fuga per layout personalizzati
La versione 7, standardizzata in RFC 9562, porta le moderne proprietà ordinate nel tempo nel formato UUID. Utilizza un timestamp Unix al millisecondo 48-bit, 12 bits con precisione inferiore al millisecondo e 62 bit casuali combinati. Il timestamp in millisecondi Unix è valido fino all'anno 10889, rendendolo adatto ai sistemi. Il risultato viene ordinato correttamente in ordine lessicografico e si inserisce in una colonna 128-bit standard UUID senza gestione speciale o conversione di codifica. Se la tua applicazione necessita di identificatori ordinati in base all'ora di creazione all'interno del formato standard UUID, la v7 è la best practice attuale. La versione 8 è un pacchetto standardizzato per formati definiti dall'implementazione, utile solo se sono necessari layout di bit specifici non coperti da v1-v7.
Esempio pratico: un percorso decisionale applicato a tre scenari: un riferimento API pubblico, una chiave primaria e un ID stabile per i record importati
Tre scenari reali illustrano la selezione della versione: in primo luogo, un riferimento API pubblico deve essere stabile tra le istanze API, non deve perdere tempo di creazione e deve essere lo stesso tra i riavvii del server in modo che istanze diverse generino lo stesso riferimento per lo stesso documento. Utilizza v5 con uno spazio dei nomi e un nome del documento stabili. In secondo luogo, una chiave primaria per una tabella in continua crescita deve essere univoca, non deve causare la frammentazione dell'indice e deve essere generabile da qualsiasi istanza dell'applicazione senza coordinamento centrale. Utilizza v7 per identificatori ordinabili con supporto dell'ecosistema UUID standard. In terzo luogo, i record archiviati che richiedono una ricerca stabile necessitano di identificatori immutabili.
Conclusione: scegli per proprietà, non per abitudine: il generatore ToolAcre produce UUID casuali dal CSPRNG del browser per i casi che richiedono la v4
La selezione della versione dipende dalla progettazione dello schema e dai requisiti di sistema, non dalla convenzione o dalla familiarità. Gli UUID casuali (v4) sono l'impostazione predefinita perché non richiedono stato o coordinamento e producono identificatori indipendenti adatti alla maggior parte dei ruoli. Le versioni ordinate nel tempo (v6, v7) risolvono i problemi di località dell'indice al costo della perdita di informazioni temporali o dei requisiti di sincronizzazione dell'orologio. Le versioni deterministiche (v3, v5) impediscono importazioni duplicate e consentono mappature esterne stabili a scapito della prevedibilità: chiunque conosca il tuo spazio dei nomi può ricalcolarle. ToolAcre genera UUID v4 casuali dal generatore crittograficamente sicuro del browser. Quando è necessaria una versione diversa, il controllo ben formato conferma che gli identificatori vengono analizzati come validi.