Strumenti per sviluppatori · Generatore UUID
Leggere a mano un UUID: dove risiedono i bit della versione e della variante
· Come funziona
uuid crittografia API del browser
Due caratteri esadecimali in ogni UUID indicano quale versione lo ha prodotto e quale variante di layout segue. Impara a leggerli a colpo d'occhio e a sapere cosa non possono dirti.
Quale sistema ha creato questo ID? - la domanda di log-forensics a cui la versione nibble può rispondere
Una stringa UUID contiene 36 caratteri: trentadue cifre esadecimali e quattro trattini nelle posizioni 8-4-4-4-12. Due caratteri in ogni UUID—che appaiono nelle posizioni 14 e 19—codificano i metadati: il campo della versione indica quale algoritmo ha generato l'ID e il campo della variante indica quale layout standard segue. Leggere questi due caratteri senza strumenti è l'abilità forense dei log: individui un UUID in un dump del database o in un messaggio di errore e sai immediatamente se si tratta di un timestamp v1 (che fa trapelare l'ora di creazione), un valore casuale v4 (che è stato generato da un CSPRNG) o qualcos'altro. Il numero di versione occupa i bit 48–51 di UUID, che corrisponde al primo carattere esadecimale del terzo gruppo.
Il layout 128-bit in cinque gruppi: come 8-4-4-4-12 si associa ai byte e perché i gruppi sono storici, non funzionali
Per la stringa xxxxxxxx-xxxx-4xxx-xxxx-xxxxxxxxxxxx, il carattere nella posizione 14 è la versione. RFC 9562 definisce le versioni da 1 a 8: v1 è basata sul tempo gregoriano e perde l'ora di creazione; v4 è casuale; v7 è basato sul tempo Unix e ordinabile. La versione 0, 9 e successive sono riservate o non utilizzate. Se vedi una v1 UUID, sai che l'ora e l'indirizzo hardware sono stati mescolati; se vedi v4, l'ID è costituito da byte casuali con i bit di versione impostati; se vedi v7, viene ordinato in base all'ora di creazione. La versione non è facoltativa; ogni UUID formato correttamente ne ha uno. Il campo variante occupa i bit 64–65 del UUID, i due bit più significativi dell'ottetto 8.
Il bozzetto della versione: il primo carattere del terzo gruppo, cosa significano da 1 a 8 e cosa indica 0 o 9
Nella rappresentazione testuale xxxxxxxx-xxxx-xxxx-Nxxx-xxxxxxxxxxxx, il primo carattere del quarto gruppo (posizione 19) codifica la variante. Per la variante RFC 9562 (lo standard nell'uso moderno), questo carattere deve essere 8, 9, a o b: le rappresentazioni esadecimali di 1000, 1001, 1010 e 1011 in binario. Qualsiasi altro carattere (0–7, c–f) indica una variante diversa: 0–7 sono NCS compatibilità con le versioni precedenti; c–d sono GUID legacy Microsoft con ordine dei byte little-endian; e–f sono riservati. Quando leggi la posizione 19 e vedi 8, 9, a o b, stai guardando un RFC 9562 UUID. Qualsiasi altro valore significa che i byte seguono un'interpretazione diversa. Il layout 128-bit si divide in ottetti 0–15, ma il formato del testo li separa in gruppi per leggibilità, non per funzionalità.
Il campo variante: perché il primo carattere del quarto gruppo è 8, 9, aob per RFC UUID e cosa segnala c/d (Microsoft legacy) o 0–7 (NCS)
I cinque gruppi rappresentano i confini storici dei campi: i primi tre campi contengono il timestamp e la versione negli UUID v1, il quarto campo contiene la sequenza e la variante dell'orologio, il quinto campo contiene l'identificatore del nodo. La versione 4 e le versioni successive UUID non utilizzano questi nomi di campo, ma le stesse posizioni di bit riportano ancora la versione e la variante. Leggere un UUID v4 significa accettare che la maggior parte dei 128 bits sono carichi utili casuali, ma due di essi, nelle posizioni 14 e 19 nel testo, sono fissi per standard. Questi bit fissi dimostrano che l'ID è una variante v4 e RFC. Lo zero UUID è 00000000-0000-0000-0000-000000000000, tutto zeri e non contiene alcuna versione. Il massimo UUID è ffffffff-ffff-ffff-ffff-ffffffffffff, tutti i caratteri f, ed è anche riservato e senza versione.
Esempio realizzato: decodifica di tre identificatori di esempio carattere per carattere, inclusi v4 e v7
Ogni altro UUID ben formato ha una versione nel terzo gruppo e una variante nel quarto. Mettiti alla prova con tre ID di esempio: 123e4567-e89b-12d3-a456-426614174000 (v1, variante RFC perché la posizione 19 è a); 9b2e4f1a-4f3e-4c1a-8a7d-1b2c3d4e5f60 (v4, variante RFC perché la posizione 19 è 8); 018f0c2e-1b5a-7c3d-9e4f-5a6b7c8d9e0f (v7, variante RFC perché la posizione 19 è 9). L'ispettore ToolAcre conferma la tua lettura. Un controllo del formato non può dirti se un ID è univoco, esiste nel tuo database o è stato generato in modo sicuro. La versione v1 utilizza l'ora e l'hardware come input, quindi UUID v1 identici da macchine diverse significano problemi di disallineamento dell'orologio o di sincronizzazione. La versione v4 è casuale, quindi un duplicato v4 UUID significa casualità interrotta o una collisione astronomicamente improbabile (circa uno per 2. 7 trilioni di UUID con casualità del suono).
Nil e Max: i due valori tutto zero e tutto F che non riportano alcuna versione
Una versione 0 o 9 significa che la stringa non è affatto una UUID valida. Leggere la versione e la variante è il primo passo per capire cos'è un ID; verificare se esiste o è univoco è il secondo e il terzo passaggio, eseguiti dal database e dalla logica aziendale. Comprendere le posizioni dei bit aiuta a eseguire il debug delle migrazioni dei dati. Quando si importano UUID da sistemi legacy, alcuni strumenti esportano campi varianti che non corrispondono allo standard RFC 9562. Un campo variante di c o d indica un Microsoft GUID nell'ordine dei byte little-endian. Questi GUID sono identificatori validi all'interno dei sistemi Microsoft ma non interagiscono con gli UUID RFC 9562 senza conversione dell'ordine dei byte. La posizione di lettura 19 ti dice immediatamente quale sistema ha generato l'ID. Se vedi 8, 9, a o b, hai un RFC standard UUID.
Ciò che un controllo del formato non può dirti: se l'ID esiste nel tuo database, se è stato generato in modo sicuro o se è univoco
Se vedi c o d, hai un Microsoft GUID. Se vedi qualsiasi altro carattere, l'identificatore non è corretto o proviene da un sistema oscuro. Il generatore ToolAcre produce sempre UUID RFC 9562 con posizione 19 come uno tra 8, 9, a o b. Il campo della versione a tre bit codifica sette possibili valori (1–7; la versione 0 e 8 hanno significati speciali). La versione 1 è il timestamp gregoriano, la versione 3 è lo spazio dei nomi basato su MD5, la versione 4 è casuale, la versione 5 è lo spazio dei nomi basato su SHA-1, la versione 6 è Basato su Unix timestamp (proposto), la versione 7 è ordinabile basato su Unix timestamp (standardizzato in RFC 9562), la versione 8 è riservata ai formati personalizzati. Leggendo il carattere position-14 ti dice immediatamente quale algoritmo è stato utilizzato. Se stai eseguendo il debug di collisioni UUID o tipi imprevisti, il numero di versione è il tuo primo indizio. ToolAcre genera UUID v4 esclusivamente da crittografia.
Conclusione: due caratteri, molto contesto: utilizza il controllo ben formato ToolAcre per confermare l'analisi di una stringa, quindi leggi tu stesso la versione
ottienivaloricasuali; ogni UUID che produce ha un 4 nella posizione 14. L'analisi manuale della struttura UUID è un'abilità utile per eseguire il debug di sistemi complessi in cui gli strumenti non sono disponibili. In un incidente di produzione, potrebbe essere necessario leggere gli UUID da un dump del database, da un log degli errori o dalla cache senza eseguire uno strumento speciale. Cerchi la posizione 14 per identificare la versione (perde tempo? è casuale? è ordinabile? ). Cerchi la posizione 19 per identificare la variante (è RFC standard? è una Microsoft GUID? è riservata? ). Questi due caratteri, sul totale di 36, trasportano i metadati. I rimanenti caratteri 34 sono payload: timestamp o byte casuali o altri dati specifici dell'algoritmo. Sapere cosa rappresenta il carico utile ti aiuta a comprendere il ruolo dell'ID nel tuo sistema.