Strumenti per sviluppatori · Generatore UUID
GUID vs UUID: parentesi graffe, ordine dei byte e variante di Microsoft spiegati
· Sfondo
uuid crittografia API del browser
GUID è il nome Microsoft per UUID, ma le parentesi graffe, le lettere maiuscole e l'ordine dei byte possono far sì che lo stesso identificatore abbia un aspetto diverso tra le piattaforme. Questo post spiega ogni differenza e come confrontare in modo sicuro.
Lo stesso ID che non riesce a trovare corrispondenza tra i sistemi: un servizio .NET e un servizio Java in disaccordo su un record
Un servizio .NET genera un GUID e lo invia a un servizio Java, che tenta di far corrispondere il valore con un UUID da PostgreSQL. Il confronto delle stringhe non riesce e i sistemi segnalano che gli identificatori non corrispondono, anche se tutti e tre i servizi funzionano con lo stesso 16 bytes sottostante. Le differenze sono apparentemente estetiche (parentesi graffe, maiuscole e minuscole, ordine dei byte) ma causano il fallimento dei confronti tra stringhe e confondono i punti di integrazione che non si normalizzano al confine. GUID è la terminologia Microsoft per ciò che RFC 9562 chiama UUID: un identificatore di 128 bit con lo stesso layout di bit. I due nomi si riferiscono alla stessa struttura fondamentale, ma la rappresentazione differisce in modi che colgono di sorpresa gli sviluppatori. Capire dove ha origine la confusione previene i bug di integrazione.
GUID è un UUID: il formato condiviso 128-bit e da dove deriva la differenza di denominazione
GUID sta per Globally Unique Identifier e Globally Unique Identifier ed è il nome utilizzato da Microsoft per ciò che gli standard RFC chiamano UUID. Il layout 128-bit e il sistema versione/variant sono identici. RFC 4122 e RFC 9562 specificano il formato e il significato di UUID; Microsoft li implementa e utilizza il termine GUID. La differenza di denominazione è storica: Microsoft utilizzava GUID prima che gli UUID fossero standardizzati da IETF e la terminologia Microsoft è rimasta nell'ecosistema .NET. A livello di bit, un GUID e un UUID sono completamente intercambiabili. A livello di formattazione, differiscono nella presentazione: il codice .NET spesso scrive GUID con parentesi graffe e lettere maiuscole, mentre gli UUID canonici RFC utilizzano lettere minuscole e senza parentesi graffe.
Parentesi graffe e lettere maiuscole: il modulo {XXXXXXXX-...} in stile registro e come normalizzarlo
Un UUID nella forma canonica RFC è scritto come otto, quattro, quattro, quattro e dodici caratteri esadecimali minuscoli separati da trattini: 550e8400-e29b-41d4-a716-446655440000. A .NET GUID viene convenzionalmente visualizzato con parentesi graffe e lettere maiuscole: {550E8400-E29B-41D4-A716-446655440000}. Le parentesi graffe provengono dal formato del registro di Windows; il maiuscolo è una convenzione di visualizzazione. Entrambe le forme rappresentano l'identico 128 bits. Per abbinare un GUID da .NET con un UUID da PostgreSQL, rimuovi le parentesi graffe e normalizza l'involucro, quindi confronta le stringhe. Il controllo ToolAcre ben formato accetta la forma canonica e rimuove automaticamente le parentesi graffe. La normalizzazione è una trasformazione minore del testo che preserva tutto il significato.
Ordine dei byte mixed-endian: come i primi tre campi vengono archiviati little-endian nella struttura GUID e perché Guid.ToByteArray differisce dall'ordine dei byte RFC
La differenza pericolosa tra GUID e UUID è l'ordine dei byte. RFC 9562 specifica che i primi tre campi (8, 4 e 4 gruppi esadecimali) sono archiviati nell'ordine dei byte big-endian (rete). .NET La struttura Guid memorizza i primi tre campi in little-endian: i byte vengono invertiti prima di scrivere nello spazio di archiviazione. Lo stesso 16 bytes, quando scritto da .NET Guid.ToByteArray() e interpretato da codice compatibile con RFC, produce rappresentazioni di testo completamente diverse. A UUID 550e8400-e29b-41d4-a716-446655440000 nell'ordine dei byte RFC viene memorizzato come byte 55 0e 84 00 e2 9b 41 d4 a7 16 44 66 55 44 00 00.
La variante legacy di Microsoft: cosa significa una c o una d nel primo carattere del quarto gruppo
Oltre all'ordine dei byte, gli identificatori Microsoft legacy a volte utilizzano un campo variante non standard. Dove RFC 9562 specifica che il primo carattere del quarto gruppo deve essere 8, 9, a o b, i GUID Microsoft legacy potrebbero utilizzare c, d, e o f. Questi sono UUID ancora validi, ma sono conformi a una variante legacy che precede la standardizzazione RFC. Se riscontri un GUID con c o d nel primo carattere del quarto gruppo, hai un valore 128 bit valido che non è conforme ai bit della variante RFC. Il moderno .NET genera GUID conformi a RFC, quindi i nuovi identificatori non dovrebbero presentare questo problema. I bit delle varianti legacy sono rari ma importanti da riconoscere.
Esempio funzionante: lo stesso 16 bytes reso nell'ordine RFC e nell'ordine della struttura GUID, mostrando esattamente quali caratteri si scambiano
Prendi il UUID 550e8400-e29b-41d4-a716-446655440000 e convertilo in .NET GUID modulo di array di byte utilizzando la convenzione little-endian. Nell'ordine RFC, i byte sono: primo campo (550e8400) uguale a 55 0e 84 00, secondo campo (e29b) uguale a e2 9b, terzo campo (41d4) uguale a 41 d4, quarto e quinto uguale a7 16 44 66 55 44 00 00. In .NET little-endian: il primo campo diventa 00 84 0e 55, il secondo diventa 9b e2, il terzo diventa d4 41 e il resto rimane in big-endian. L'array di byte completo è 00 84 0e 55 9b e2 d4 41 a7 16 44 66 55 44 00 00. Se un sistema Java legge questi byte prevedendo l'ordine RFC, li interpreta come 00840e55-9be2-d441-a716-446655440000.
Cosa non copre: SQL NEWSEQUENTIALID del server e ordinamento, che sono un argomento di archiviazione a sé stante
Il comportamento della funzione SQL Server NEWSEQUENTIALID e le relative proprietà specifiche di ordinamento degli identificatori sono argomenti specifici del livello di archiviazione e del database. Questo post si concentra sulle differenze di formato e ordine dei byte a livello di applicazione e serializzazione. La gestione approfondita di UUID e i problemi relativi all'ordine dei byte specifici del database sono meglio affrontati nella documentazione specifica per quella piattaforma di database. Diversi sistemi di database hanno approcci e approcci diversi all'archiviazione, all'indicizzazione, all'ordinamento e al supporto nativo di UUID. Alcuni database rilevano automaticamente la versione e i bit delle varianti, mentre altri richiedono dichiarazioni di tipo esplicite e gestione dell'ordine dei byte al confine tra sistemi e storage.
Conclusione: normalizza al confine: il controllo ToolAcre accetta la forma canonica, che è la forma su cui standardizzarsi quando si scambiano gli ID
Normalizza al confine quando gli identificatori attraversano un confine di sistema .NET/non-.NET. Elimina le parentesi graffe, normalizza le maiuscole e minuscole in modo coerente e scambia i byte nei primi tre campi se i byte provengono da .NET Guid.ToByteArray(). La forma canonica RFC è lo standard di riferimento: otto, quattro, quattro, quattro e dodici caratteri esadecimali minuscoli con trattini, senza parentesi graffe, ordine dei byte big-endian. Quando si effettuano scambi con sistemi .NET, concordare un modulo normalizzato e applicare le conversioni esplicitamente nel codice di integrazione. Documentare la gestione dell'ordine dei byte e testare accuratamente le conversioni. Le somiglianze fondamentali tra GUID e UUID significano che la maggior parte di 128 bits sono identiche.