Generatore UUID Gratuito

Informazioni sugli UUID

Un UUID (Universally Unique Identifier) è un identificatore 128-bit progettato per essere unico nello spazio e nel tempo. La versione più comune, UUID v4, viene generata utilizzando numeri casuali o pseudo-casuali. Il formato è 8-4-4-4-12 caratteri esadecimali, ad esempio 550e8400-e29b-41d4-a716-446655440000.

Quattro decenni di storia: da Apollo a RFC 9562

Il concetto di UUID ebbe origine nell'Apollo Network Computing System (NCS) a metà degli anni '80, progettato in Apollo Computer da Paul Leach e Rich Salz per supportare il calcolo distribuito senza registrazione centrale. Il formato fu adottato dall'Open Software Foundation Distributed Computing Environment (OSF DCE) nel 1989 e standardizzato internazionalmente nel 1995 come ITU-T X.667 / ISO/IEC 9834-8. L'IETF integrò la specifica in RFC 4122 (Leach, Mealling, Salz) nel luglio 2005, che divenne il riferimento canonico per due decenni. RFC 4122 fu aggiornata dalla RFC 9562 nel maggio 2024, che mantenne tutte le versioni originali (da v1 a v5), aggiunse tre nuove versioni (v6, v7, v8), e definì formalmente le costanti speciali "Nil UUID" (tutto zero) e "Max UUID" (tutto uno). La discendenza delle versioni conta perché ogni versione scambia proprietà diverse: basata sul tempo (ordinabile, fa trapelare informazioni); basata sul nome (deterministica dagli input); casuale (universale, opaca); custom (qualunque cosa ti serva). La best practice moderna per nuove applicazioni è passata dalla v4 (casuale) alla v7 (timestamp + casuale) per le chiavi primarie, mentre la v4 resta la risposta giusta per identificatori opachi dove l'ordinabilità è indesiderabile.

Le otto versioni, in italiano semplice

• v1 (timestamp + indirizzo MAC). 60 bit di timestamp (intervalli di 100 nanosecondi dall'epoca gregoriana 1582) più l'indirizzo MAC della macchina d'origine. Il difetto principale: rivela l'indirizzo MAC della macchina che genera, il che è un problema di privacy. L'autore del virus Melissa fu famosamente identificato nel 1999 in parte tracciando UUID v1 in documenti Word fino a una macchina specifica.
• v2 (sicurezza DCE). Variante di v1 che include UID/GID POSIX. Quasi mai usata in pratica; documentata per completezza.
• v3 (basata sul nome, MD5). UUID deterministico derivato dall'hash MD5 di (UUID di namespace + stringa nome). Stessi input producono sempre lo stesso UUID: utile per tradurre chiavi naturali (URL, nomi di dominio, distinguished name) in forma UUID.
• v4 (casuale). 122 bit di casualità (i 6 bit rimanenti sono i tag di versione + variante). La versione più ampiamente usata: il default che quasi ogni libreria "dammi un UUID" restituisce.
• v5 (basata sul nome, SHA-1). Stessa di v3 ma usando SHA-1 invece di MD5. Preferita rispetto a v3 per nuove applicazioni perché SHA-1 è meno compromessa di MD5, anche se entrambe hanno attacchi di collisione noti.
• v6 (RFC 9562, maggio 2024, ordinata nel tempo). Riordina i bit del timestamp v1 così che l'ordinamento lessicografico corrisponda all'ordinamento cronologico. Risolve il reclamo "v1 non si ordina nel tempo"; rivela ancora l'indirizzo MAC di default.
• v7 (RFC 9562, maggio 2024, timestamp Unix + casuale). I primi 48 bit sono il timestamp Unix in millisecondi; i restanti 74 bit sono casuali. Si ordina naturalmente per ora di creazione, include dati di timestamp senza rivelare l'identità della macchina, ed è la raccomandazione moderna per le chiavi primarie del database. Postgres 18+ ha uuidv7() integrato; SQL Server ha NEWSEQUENTIALID() con proprietà simili.
• v8 (custom). Riservata per layout specifici dell'applicazione. Il campo versione la marca come v8 e i bit della variante sono impostati correttamente; tutto il resto dipende dall'applicazione. Usala quando hai bisogno di incorporare i tuoi dati strutturati nella busta a forma di UUID.

Perché v7 è sempre più preferita a v4 per le chiavi del database

Le chiavi primarie casuali (UUID v4) hanno un costo di prestazioni ben documentato nei database che organizzano le righe per chiave primaria in un B-tree o indice simile. Ogni nuovo insert atterra a una posizione casuale nell'indice, il che frammenta le pagine dell'indice, aumenta l'amplificazione di scrittura su disco e svuota la cache delle pagine perché le righe inserite recentemente sono sparse su molte pagine invece di essere raggruppate. Le chiavi sequenziali (interi auto-incrementanti, ULID, UUID v7) inseriscono tutte sul bordo destro dell'indice, il che mantiene il working set piccolo e l'amplificazione di scrittura minima. La critica del "random key anti-pattern" risale alla prima documentazione SQL Server attorno a NEWID contro NEWSEQUENTIALID, ed è stata riarticolata dalla comunità Postgres per v4 vs v7. Il compromesso: v7 rivela l'ora di creazione di ogni riga, che può essere una preoccupazione di privacy o di leakage di informazioni in alcune applicazioni (es. puoi capire quando un account è stato creato leggendo il suo UUID). Per la maggior parte delle applicazioni la vittoria sulle prestazioni supera il leak del timestamp; per applicazioni ad alta privacy, v4 resta la risposta giusta.

Probabilità di collisione: la matematica del paradosso del compleanno

UUID v4 ha 122 bit di casualità, dando approssimativamente 5,3 × 10³⁶ possibili valori. Il paradosso del compleanno dice che hai bisogno approssimativamente della radice quadrata della dimensione del namespace per avere il 50% di probabilità di una qualunque collisione: circa 2,3 × 10¹⁸ UUID. Per metterlo in termini umani: se generi 1 miliardo di UUID al secondo continuamente, avresti bisogno di circa 86 anni per avere il 50% di probabilità di una singola collisione. Per i normali tassi di generazione su scala applicativa (migliaia o milioni al giorno), il rischio pratico di collisione è zero. La causa più probabile di "UUID duplicati" nei sistemi reali è un generatore con bug che usa Math.random() invece di un CSPRNG, o un generatore con entropia insufficiente all'avvio, o un processo che accidentalmente semina due generatori in modo identico, non la matematica sottostante. Questo generatore usa crypto.randomUUID() del browser (dove disponibile) o crypto.getRandomValues(), entrambi i quali attingono dal CSPRNG del sistema operativo (Linux getrandom(), Windows BCryptGenRandom, macOS SecRandomCopyBytes): la stessa fonte di entropia usata per le chiavi di sessione TLS.

Implementazione del browser: crypto.randomUUID()

La Web Crypto API espone crypto.randomUUID() come generatore one-call che restituisce una stringa UUID v4 conforme a RFC 4122. È arrivato in Chrome 92 (luglio 2021), Firefox 95 (dicembre 2021) e Safari 15.4 (marzo 2022), ed è stato disponibile come baseline in tutti i browser moderni dal 2022 circa. Per browser più vecchi, il fallback standard è di allocare un Uint8Array di 16 byte, riempirlo con crypto.getRandomValues(), impostare il nibble di versione a 4 (il nibble alto del 7° byte = 0x40), impostare i bit della variante a 10xxxxxx (i due bit alti del 9° byte = 0x80), e formattare i byte come la stringa hex 8-4-4-4-12. Questo generatore usa crypto.randomUUID() quando presente e il fallback manuale altrimenti: l'output è identico in entrambi i modi, solo leggermente più lento sul percorso di fallback. Entrambi i percorsi girano interamente nel tuo browser; nulla attraversa la rete.

Casi d'uso, e di cosa ognuno ha effettivamente bisogno

• Chiavi primarie del database: specialmente sistemi distribuiti o sharded dove coordinare un contatore intero è impraticabile. v7 è la raccomandazione moderna; v4 se hai bisogno di opacità sul timestamp.
• ID di correlazione delle richieste API. Ogni richiesta in entrata ottiene un UUID che viaggia attraverso ogni servizio downstream nella catena di chiamate; i log da qualsiasi servizio possono essere ricondotti alla richiesta originale tramite l'ID. Stripe, Twilio e AWS X-Ray fanno tutti questo.
• Chiavi di idempotenza per richieste HTTP. L'header Idempotency-Key di Stripe accetta un UUID; se il client ritenta la stessa richiesta con la stessa chiave, Stripe restituisce la risposta cached invece di addebitare la carta due volte. Questo pattern è ora standard tra le API di pagamento.
• Token di sessione, con avvertenze. Un UUID v4 è crittograficamente casuale e ha 122 bit di entropia, che è più che sufficiente per un session ID. Ma i token di sessione che sono solo un UUID sono vulnerabili ad attacchi di enumerazione se qualunque endpoint correlato li trapela; la best practice moderna è usare token più lunghi e firmati (JWT, Paseto) per lo stato di sessione.
• Nomi di file per la deduplicazione degli upload. Genera un UUID per ogni upload, salva il file in /uploads/{uuid}.ext: non avrai mai una collisione di nome indipendentemente dal nome di file originale, e non puoi accidentalmente servire il file di un altro utente indovinando l'URL.
• ID di messaggio in sistemi event-driven. Kafka, RabbitMQ, AWS SQS e la maggior parte delle piattaforme pub/sub raccomandano un UUID per messaggio per il tracing e la deduplicazione; v7 è sempre più il default per la proprietà di ordinabilità per timestamp.
• Generazione di dati di test. Le librerie Faker in ogni linguaggio usano UUID come ID di default per le righe di test generate.
• Identificatori di nodo in sistemi distribuiti. Un nuovo nodo che si avvia in un cluster genera un UUID per sé stesso; il coordinatore del cluster usa quell'ID per instradare il traffico e identificare il nodo nei log.

Alternative che vale la pena conoscere

UUID è il default universale ma non l'unica opzione, e diverse alternative valgono la pena per casi d'uso specifici. ULID (Universally Unique Lexicographically Sortable Identifier, Alex Knol, ~2016): 128 bit come UUID, ma codificato come 26 caratteri Crockford-Base32 invece di 32 cifre esadecimali: più compatto e URL-safe in modo case-insensitive. I primi 48 bit sono un timestamp Unix in millisecondi, quindi gli ULID si ordinano lessicograficamente per ora di creazione. Concettualmente molto vicino a UUID v7, anticipandolo di anni. Snowflake (Twitter, 2010): 64 bit, molto più piccolo di UUID, entra in un BIGINT SQL. 41 bit di timestamp + 10 bit di ID macchina + 12 bit di sequenza per millisecondo. Usato da Twitter/X, Discord, Instagram e molti sistemi su larga scala dove le chiavi primarie a 64 bit sono un vincolo rigido. KSUID (Segment, 2017): 27 caratteri, timestamp con precisione al secondo + 128 bit casuali. Scambia precisione al millisecondo per una rappresentazione di stringa più piccola di UUID. nanoid (Andrey Sitnik, 2017): una piccola libreria che produce identificatori URL-safe casuali di lunghezza configurabile. Il default di 21 caratteri offre resistenza alla collisione simile a UUID v4 in molti meno byte. Per un URL pubblico dove altrimenti incorporeresti un UUID, nanoid è più corto e più amichevole. Il compromesso: gli identificatori nanoid non hanno i bit marcatori di versione + variante che li distinguono come UUID, quindi non si inseriscono in sistemi che si aspettano valori a forma di UUID.

Sicurezza degli URL e variazioni di formato

Gli UUID nella loro forma canonica con trattini (550e8400-e29b-41d4-a716-446655440000) sono URL-safe: ogni carattere (lettere minuscole, cifre, trattini) è nel set unreserved definito da RFC 3986. Questo significa che puoi inserire un UUID direttamente in un percorso URL o stringa di query senza percent-encoding. Alcuni sistemi rimuovono i trattini per compattezza, producendo una stringa hex di 32 caratteri (550e8400e29b41d4a716446655440000) che è ancora URL-safe; la conversione è reversibile perché la struttura UUID è fissa. Alcuni sistemi avvolgono gli UUID in graffe ({550e8400-e29b-41d4-a716-446655440000}): la convenzione GUID di Microsoft; le graffe sono decorative e non viaggiano mai negli URL. Alcuni sistemi mettono i caratteri esadecimali in maiuscolo; gli UUID sono case-insensitive secondo la specifica, ma la coerenza all'interno di un sistema conta. Questo generatore offre tutte e tre le opzioni (maiuscolo, graffe, senza trattini) per la compatibilità con qualunque pipeline a cui stai dando in pasto gli UUID.

UUID contro GUID: la stessa cosa, nome diverso

UUID è il termine standard usato da IETF, ISO e dalla maggior parte dei progetti open-source. GUID (Globally Unique Identifier) è il termine Microsoft usato in Windows, .NET, COM/OLE, SQL Server, Active Directory e nel Registro di Windows. Entrambi si riferiscono all'identificatore identico a 128 bit nello stesso formato esadecimale 8-4-4-4-12. Funzionalmente intercambiabili: un GUID generato da Windows può essere usato ovunque ci si aspetti un UUID, e viceversa. L'unica differenza che vale la pena di conoscere: la generazione di GUID di Microsoft storicamente usava UUID v4 in molte API ma UUID v1 (con indirizzo MAC) in alcuni contesti COM/OLE più vecchi; questo è documentato nella specifica COM di Microsoft. Se ricevi un GUID da un sistema di origine Microsoft e vuoi sapere quale versione è, controlla il nibble di versione (il 13° carattere esadecimale: '1' per v1, '4' per v4, ecc.).

Privacy: perché solo browser conta anche qui

Un UUID non ha significato intrinseco, quindi perché conta che il generatore giri localmente? Due ragioni. Primo, quando un UUID viene usato come token di sessione, chiave di idempotenza o qualunque altro identificatore tipo-segreto, generarlo su un server di terzi significa che quel server ha visto il valore prima che lo usassi: un'esposizione piccola ma reale. Secondo, i generatori lato server che promettono "casualità crittografica" non possono essere verificati dall'utente; un server buggy o malizioso potrebbe restituire valori non casuali che sembrano casuali, e non avresti modo di rilevare il bias. Un generatore solo-browser esegue la stessa chiamata crypto.randomUUID() che la tua applicazione eseguirebbe lato server; l'entropia proviene dalla stessa fonte del sistema operativo (Linux getrandom(), Windows BCryptGenRandom, macOS SecRandomCopyBytes); nessuna terza parte vede l'output. Puoi verificarlo aprendo il pannello Network di DevTools mentre clicchi Genera: non ci sono richieste in uscita. Metti la pagina offline (modalità aereo) dopo che si è caricata e il generatore continuerà a funzionare.

Domande frequenti

Qual è la differenza tra UUID e GUID?

Sono essenzialmente la stessa cosa. UUID è il termine standard (RFC 4122), mentre GUID (Globally Unique Identifier) è la terminologia Microsoft. Entrambi si riferiscono a un identificatore 128-bit nello stesso formato esadecimale 8-4-4-4-12.

Due UUID possono mai essere uguali?

Teoricamente sì, ma la probabilità è astronomicamente bassa. UUID v4 ha 122 bit casuali, che danno circa 5.3 × 10³⁶ valori possibili. Dovresti generare miliardi di UUID al secondo per decenni per avere una probabilità del 50% di una singola collisione.

Questi UUID sono crittograficamente sicuri?

Sì. Questo generatore utilizza Web Crypto API (crypto.getRandomValues) che fornisce valori casuali crittograficamente forti. L'output è adatto per casi d'uso sensibili alla sicurezza come i token di sessione.

Dovrei usare UUID v4 o v7 per la chiave primaria del mio database?

v7 è la raccomandazione moderna se il tuo database lo supporta. v4 (casuale) inserisce a posizioni casuali negli indici B-tree, frammenta l'indice e svuota la cache delle pagine. v7 (timestamp + casuale, RFC 9562 maggio 2024) inserisce sul bordo destro dell'indice perché gli ID si ordinano per ora di creazione: stesse prestazioni di scrittura degli interi auto-incrementanti, con la distribuzione e l'unicità degli UUID. Postgres 18+ ha uuidv7() integrato. Il compromesso: v7 rivela l'ora di creazione di ogni riga, che può essere una preoccupazione di privacy in alcune applicazioni. Per la maggior parte dei casi d'uso la vittoria sulle prestazioni supera il leak del timestamp.

Cosa sono ULID, KSUID e nanoid?

Formati ID alternativi. ULID (Alex Knol, ~2016): 128 bit come UUID ma codificati come 26 caratteri Crockford-Base32; si ordina lessicograficamente per timestamp. KSUID (Segment, 2017): 27 caratteri, timestamp con precisione al secondo + 128 bit casuali. nanoid (Andrey Sitnik, 2017): piccola libreria che produce ID URL-safe casuali di lunghezza configurabile; i 21 caratteri di default offrono resistenza alla collisione simile a UUID v4 in molti meno byte. Snowflake (Twitter, 2010): ID a 64 bit che entrano in un BIGINT SQL, usati da Twitter, Discord e Instagram. Usa UUID quando il sistema ricevente si aspetta il formato UUID; usa le alternative quando hai requisiti specifici di dimensione, ordinabilità o URL-friendliness.

Gli UUID vengono inviati da qualche parte?

No. Ogni UUID è generato localmente nel tuo browser usando la Web Crypto API. Il generatore non fa mai una richiesta di rete: verifica nel pannello Network di DevTools mentre clicchi Genera, oppure metti la pagina offline dopo che si è caricata e conferma che lo strumento continui a funzionare. Sicuro per generare token di sessione, chiavi di idempotenza o altri identificatori dove non vuoi che una terza parte abbia visto il valore prima che tu lo usassi.

Strumenti correlati