ToolZen ToolZen
Developer generator client

UUID Generator

Generate multiple random UUID v4 identifiers in bulk directly in your browser. Copy individually or all at once.

Advertisement (Top Banner)
Advertisement (Bottom)

Un UUID è composto da 128 bit scritti come 32 cifre esadecimali nella familiare forma 8-4-4-4-12. La promessa è che puoi coniarne uno su qualsiasi macchina, in qualsiasi momento, senza chiedere il permesso a nessuno, e non collidere mai con un UUID coniato altrove. Questo strumento genera la versione 4, quella casuale.

La versione 4 sono 122 bit casuali, non 128

Sei dei 128 bit sono già impegnati. Quattro codificano la versione, ed è per questo che ogni UUID v4 ha un "4" letterale all'inizio del terzo gruppo. Altri due codificano la variante, ed è per questo che il quarto gruppo comincia sempre con 8, 9, a o b. Tutto il resto — 122 bit — è casuale.

Restano circa 5,3 × 10³⁶ valori possibili. Il numero che interessa davvero è la probabilità di collisione, e il paradosso del compleanno colloca il 50% di probabilità di un qualsiasi duplicato attorno ai 2,7 × 10¹⁸ UUID. Per arrivarci dovresti generarne un miliardo al secondo per circa ottantacinque anni. In pratica, se stai collidendo, è rotta la tua sorgente casuale — non la statistica.

Da dove viene la casualità conta più della versione

Questo generatore usa crypto.getRandomValues(), la sorgente casuale crittograficamente sicura del browser. Non è una scelta estetica. L'alternativa ovvia, Math.random(), non è un CSPRNG: V8 la implementa con xorshift128+, un algoritmo pensato per velocità e qualità statistica, non per imprevedibilità. Osserva abbastanza dei suoi output e puoi ricostruirne lo stato interno e prevedere ogni valore che produrrà.

Per un UUID che deve solo essere unico, la differenza non conta. Conta enormemente nel momento in cui a un UUID si chiede anche di essere non indovinabile: un link di reset password, un URL di invito, la condivisione "segreta" di un documento. Sono esattamente i posti dove gli UUID v4 vengono usati come token, e un generatore basato su Math.random li trasforma in una vulnerabilità che nessun test intercetterà mai. Se da questa pagina porti via una cosa sola: controlla cosa usa la tua libreria di UUID prima di trattarne l'output come un segreto.

La questione della chiave primaria

Gli UUID casuali sono ottimi identificatori e chiavi primarie clusterizzate mediocri, e conviene sapere perché prima di fissare uno schema. I database tengono gli indici B-tree in ordine. Gli interi auto-incrementanti si accodano sempre alla pagina più a destra, il che costa poco. Gli UUID v4 casuali finiscono ovunque, quindi gli inserimenti si sparpagliano su tutto l'indice, forzando split di pagina e sporcando pagine in giro per il buffer pool.

Morde più forte su MySQL con InnoDB, dove la chiave primaria è l'indice clusterizzato: la tabella stessa è ordinata fisicamente su di essa, e ogni indice secondario si porta dietro una copia della chiave primaria. Lì una chiave casuale da 16 byte costa il doppio. È esattamente il problema che la versione 7 degli UUID è stata standardizzata per risolvere: mette un timestamp in millisecondi nei bit alti, così i valori si ordinano all'incirca per data di creazione e gli inserimenti restano vicini al bordo destro, mantenendo abbastanza casualità da restare non indovinabili. Se vuoi UUID come chiavi primarie a volumi seri, v7 o ULID è la risposta moderna. Questo strumento genera v4, che è la scelta giusta per identificatori che non sono anche l'ordine fisico della tua tabella.

I formati sono cosmetici, quasi sempre

Con i trattini, senza, maiuscolo, con le graffe: tutti e quattro rappresentano gli stessi 128 bit e qualsiasi parser sensato li accetta tutti. Lo stile con le graffe viene dalle convenzioni GUID di Microsoft ed è quello che troverai nel registro di Windows e nelle interfacce COM. La forma compatta da 32 caratteri è comoda dove la lunghezza pesa, tipo un segmento di URL.

Un'avvertenza: la RFC 9562 prescrive il minuscolo in output, mentre i parser devono accettare entrambi i casi in input. Se conservi gli UUID come stringhe invece che come tipo nativo da 16 byte, un maiuscolo incoerente può produrre due righe che sono lo stesso UUID e non risultano uguali al confronto. È un bug che ti fai da solo, e normalizzare in minuscolo all'ingresso lo evita.

Domande frequenti

Gli UUID vengono generati su un server?

No. Questo strumento è marcato "client": ogni valore è prodotto nella scheda del tuo browser dalla sua sorgente casuale, e non viene trasmesso niente. È anche la risposta onesta alla domanda se siano solo tuoi: qui nessuno ne ha traccia, noi compresi.

Due UUID v4 possono mai essere uguali?

Matematicamente sì, praticamente no — con un grosso asterisco. Le probabilità sono trascurabili solo se la casualità sottostante è sana. Gli incidenti reali di UUID duplicati si riconducono quasi tutti a una sorgente rotta: un PRNG con seed fisso, una macchina virtuale clonata insieme al suo pool di entropia, o un dispositivo embedded che genera chiavi prima di aver raccolto entropia. Il rischio non è la matematica; è la sorgente casuale.

Un UUID v4 è sicuro come token segreto?

Se viene da una sorgente crittograficamente sicura, 122 bit casuali sono abbondanti — comodamente più di un tipico token di sessione da 128 bit. La condizione però è tutta la risposta. Verifica che il tuo generatore usi crypto.getRandomValues o l'equivalente della piattaforma invece di Math.random, e non dare mai per scontato che una libreria l'abbia azzeccato solo perché il suo output sembra casuale.

Meglio un UUID o un intero auto-incrementante?

Gli interi sono più piccoli, più veloci da indicizzare e si ordinano naturalmente. Gli UUID ti permettono di generare identificatori senza un giro fino al database, di unire dataset di sistemi diversi senza rinumerare, e di non rivelare quanti record hai: un ID sequenziale in un URL racconta a tutti il tuo numero di ordini. Molti schemi finiscono per avere entrambi: una chiave intera interna per il database e un UUID per il mondo esterno.

Perché il terzo gruppo inizia sempre con 4?

Quel nibble è il campo versione, e 4 significa "generato da numeri casuali". Non è casuale lui stesso: è un'etichetta. Vederlo è il modo in cui un parser sa che deve interpretare il resto come v4 e non come un timestamp v1 o un hash v5. Se ne generi 2000 qui, tutti e 2000 ce l'avranno.