Strumenti per sviluppatori · Generatore UUID
Da 128 Bits a 36 Caratteri: come funziona la codifica del testo UUID
· Come funziona
uuid crittografia API del browser
A UUID è 16 bytes, ma la sua forma familiare è composta da 36 caratteri. Questo post spiega il raddoppio esadecimale, i trattini, le regole del maiuscolo/minuscolo e le codifiche più brevi utilizzate dalle persone quando il modulo standard è troppo lungo.
Perché la colonna è più larga del valore: il valore 16-byte che costa 36 caratteri nel testo e cosa significa per URL e spazio di archiviazione
La larghezza della colonna di archiviazione esplode quando scegli un formato UUID. Un valore 128 bit è 16 bytes, ma la sua rappresentazione testuale dipende dalla codifica: esadecimale (36 caratteri con trattini, 32 senza), base64url (22 caratteri), base58 (22–23 caratteri), Crockford base32 (26 caratteri). Se il tuo schema memorizza gli UUID come VARCHAR(36), stai spendendo 36 caratteri in ogni riga. In una tabella con 1 miliardi di righe e nessun'altra colonna, si tratta di 36 gigabyte di testo in più rispetto a 16 gigabyte di codice binario. La scelta non è solo estetica; influisce sulle dimensioni delle query, sui andata e ritorno della rete e sulla pressione della cache. Il formato canonico è 36 caratteri: otto cifre esadecimali, trattino, quattro cifre esadecimali, trattino, quattro cifre esadecimali, trattino, quattro cifre esadecimali, trattino, dodici cifre esadecimali.
L'esadecimale raddoppia tutto: ogni byte diventa due caratteri e quattro trattini completano 36
Ogni byte diventa esattamente due caratteri esadecimali (0–9, a–f). I trattini sono presenti per motivi di leggibilità e legacy da quando gli UUID sono stati specificati per la prima volta. La codifica esadecimale raddoppia il conteggio dei byte: 16 bytes diventano 32 cifre esadecimali più 4 trattini. È la codifica più lenta e la più lunga, ma leggibile dall'uomo e supportata ovunque. Regole maiuscole e minuscole: RFC 9562 richiede lettere minuscole per l'output canonico, ma l'input non fa distinzione tra maiuscole e minuscole. Memorizzare le lettere maiuscole spreca l'opportunità di normalizzare, quindi memorizza le lettere minuscole e confronta senza distinzione tra maiuscole e minuscole durante l'input. La codifica Base64url rappresenta tre byte come quattro caratteri utilizzando un alfabeto di caratteri 64 (A–Z, a–z, 0–9, meno, trattino basso). Sedici byte diventano 21 caratteri più un carattere di riempimento, per un totale di 22 caratteri. Base64url rimuove il riempimento e i caratteri standard (più e barra) riservati negli URL.
Regole maiuscole e minuscole: minuscolo nell'output, senza distinzione tra maiuscole e minuscole nell'input e perché i confronti misti causano discrepanze silenziose
Un UUID in formato base64url salva i caratteri 14 rispetto a quelli esadecimali ed è valido negli URL senza codifica percentuale. Il compromesso: è meno leggibile (le lettere minuscole sembrano cifre; b, 8, B e 8 sono facili da confondere). Base58 è utilizzato da Bitcoin e altre blockchain e rimuove i caratteri ambigui (0, O, I, l), rendendo i caratteri 22–23 rimanenti pur rimanendo leggibili. Crockford base32 (progettato per formati tipo ISBN con checksum) utilizza i caratteri 26 e dà priorità alla correttezza rispetto alla brevità. Il trap dell'ordine dei byte Microsoft GUID si applica all'archiviazione UUID in alcuni database. RFC 9562 specifica l'ordine dei byte di rete (big-endian) per tutti i byte. Alcune configurazioni del server Microsoft SQL archiviano i GUID con ordine dei byte little-endian nei primi tre campi.
Codifiche più brevi: base64url con caratteri 22, base58 e Crockford base32, con i relativi compromessi in termini di leggibilità e sicurezza del copia-incolla
Lo stesso valore 128-bit memorizzato in big-endian e little-endian produce stringhe esadecimali diverse. Un UUID 550e8400-e29b-41d4-a716-446655440000 archiviato come Microsoft GUID potrebbe essere recuperato come 00840e55-9be2-d441-a716-446655440000 (byte 0–3 e 4–5 e 6–7 invertite). Se il tuo sistema fa da ponte tra i sistemi RFC e quelli Microsoft, devi esserne consapevole e normalizzare al limite o documentare quale formato stai utilizzando in ciascuna colonna. Esempio realizzato: v4 UUID 9b2e4f1a-4f3e-4c1a-8a7d-1b2c3d4e5f60 in esadecimale occupa 36 caratteri. Come 16 bytes è 9b 2e 4f 1a 4f 3e 4c 1a 8a 7d 1b 2c 3d 4e 5f 60. In base64url: diviso in blocchi da tre byte, convertito in base64, imbottitura a strisce: my5PGk8-TBqKfRssPTRPX2A. In esadecimale senza trattini: 9b2e4f1a4f3e4c1a8a7d1b2c3d4e5f60 (32 caratteri).
La trappola dell'ordine dei byte di Microsoft: come vengono archiviati i primi tre campi di GUID little-endian, in modo che gli stessi byte possano essere stampati come due stringhe diverse
Base64url salva 14 caratteri; base58 risparmierebbe più o meno lo stesso; lo standard è esadecimale. Scegli in base al tuo caso d'uso: se l'identificatore appare negli URL e ogni carattere è importante, usa base64url; se appare nei log e nelle interfacce utente in cui gli esseri umani lo leggono, utilizza la forma canonica esadecimale; se stai costruendo un sistema blockchain o un sistema distribuito in cui il checksum è importante, usa base58 o Crockford base32. Quando scegli un tipo di colonna, memorizza il valore che ottimizza il tuo modello di accesso effettivo. Se esegui query frequenti sugli UUID e hai bisogno di corrispondenze senza distinzione tra maiuscole e minuscole, archivia il file binario (16) e lascia che sia il database a gestire la rappresentazione. Se esegui una query per sottostringa (cercando UUID che iniziano con un prefisso), l'esadecimale è più leggibile nell'output di debug.
Esempio realizzato: un identificatore scritto come byte, esadecimale canonico e una forma abbreviata, che mostra ogni passaggio della conversione
Se esporti in CSV e invii email a utenti non tecnici, il formato esadecimale è più riconoscibile. Se hai limiti di spazio (app mobile con cache locale), base64url o base58 risparmia larghezza di banda. Il generatore ToolAcre restituisce il formato esadecimale canonico di caratteri 36; se è necessaria una codifica diversa, il controllo ben formato funziona comunque perché normalizza qualsiasi rappresentazione valida prima del controllo del formato. Le considerazioni sulle prestazioni sono importanti quando si codificano o decodificano milioni di UUID. La codifica esadecimale è semplice: converti ogni byte in due caratteri in tempo O(1) per byte. La decodifica è altrettanto semplice. La codifica e la decodifica Base64 utilizzano tabelle di ricerca e sono leggermente più lente (circa 2–3 volte più lente di quelle esadecimali per byte, a seconda dell'hardware e dell'implementazione). Base58 è significativamente più lento perché è essenzialmente una conversione di base e richiede aritmetica modulare.
Cosa non copre: scelte delle colonne del database come i tipi uuid nativi rispetto a quelli binari (16), trattati separatamente
Se il tuo sistema codifica o decodifica gli UUID in un hot loop (generazione di identificatori ad alta frequenza, esportazione in blocco), il formato esadecimale è più veloce. Se la codifica avviene raramente e il risparmio di caratteri 14 è importante, base64url è un compromesso ragionevole. Il generatore ToolAcre restituisce esadecimali, quindi ottieni il vantaggio in termini di prestazioni senza sacrificare la compatibilità. La semantica del confronto tra stringhe differisce in base alla codifica. Gli UUID esadecimali possono essere confrontati come stringhe: 550e8400-e29b-41d4-a716-446655440000 < 550e8400-e29b-41d4-a716-446655440001 (il confronto lessicografico funziona). Gli UUID binari possono essere confrontati come byte: il confronto byte per byte è uguale al confronto numerico. Gli UUID codificati Base64url e base58, tuttavia, non preservano l'ordine numerico nel confronto delle stringhe lessicografiche. Se il tuo sistema si basa sull'ordinamento lessicografico degli UUID (un modello sorprendentemente comune per la creazione di indici o chiavi di database), devi utilizzare la variante esadecimale, binaria o una variante UUID ordinabile (v6 o v7).
Conclusione: mantieni la forma canonica ai limiti: il generatore ToolAcre genera UUID di caratteri 36 standard e il suo controllo accetta stringhe in quella forma
Il generatore ToolAcre attualmente produce UUID v4, che non sono ordinabili in base all'ordine di codifica. L'interoperabilità richiede la standardizzazione su un'unica codifica. Un sistema che accetta simultaneamente UUID in formato esadecimale, base64 e base58 deve normalizzare tutti gli input in una forma canonica prima dell'elaborazione. Questo è possibile ma aggiunge complessità. API o database esterni potrebbero richiedere una codifica specifica: alcune API si aspettano urn:uuid: esadecimale con prefisso, altre si aspettano esadecimale senza trattino, altre ancora si aspettano base64url. Documenta chiaramente le aspettative di codifica UUID del tuo sistema nei contratti API. Il generatore ToolAcre restituisce sempre un valore esadecimale canonico; se hai bisogno di altre codifiche, esegui la conversione in modo esplicito e documenta i compromessi (spazio, prestazioni, leggibilità, ordinabilità) per il team.