Generatore di UUID
Ogni versione, in blocco, con lettore

Ciò che offre questo generatore di UUID

Questo generatore di UUID crea ID unici per database, API, file e test. Prima scegli una versione e quanti te ne servono, poi la lista compare subito. Infine puoi copiarla o salvarla come file di testo.

Copre ogni versione in uso oggi. La versione 4 è puro caso, la 7 si ordina per tempo, e le versioni 3 e 5 trasformano un nome sempre nello stesso ID. Inoltre ci sono le vecchie versioni 1 e 6, e i valori speciali nil e max.

La pagina funziona anche al contrario. Incolla un UUID e poi il lettore ti dice versione e variante e, per quelli basati sul tempo, il momento esatto in cui è nato.

Cos’è un UUID?

Un UUID, cioè un identificatore unico universale, è un numero a 128 bit. Spesso si scrive con 32 cifre esadecimali in cinque gruppi, come 017f22e2-79b0-7cc3-98c4-dc0c0c07398f. Poiché i valori possibili sono tantissimi, chiunque può crearne uno senza chiedere a un server centrale, e non si scontrerà con quello di nessun altro.

Due piccole parti dicono che tipo di UUID è. La prima cifra del terzo gruppo è la versione, e la prima del quarto gruppo contiene la variante. Tutto il resto è quindi tempo, caso o un hash, a seconda della versione.

Quale versione di UUID usare?

Per la maggior parte dei lavori usa la versione 4, perché è casuale, semplice e supportata ovunque. Tuttavia, se gli ID diventano chiavi di una tabella, scegli invece la versione 7. Inizia con l’ora, quindi le nuove righe si salvano in ordine e gli inserimenti restano veloci.

Quando la stessa cosa deve avere sempre lo stesso ID, usa la versione 5. Così, per esempio, un URL o un’email diventa un UUID stabile che ogni sistema può ricreare. Invece le versioni 1, 3 e 6 servono soprattutto ai sistemi più vecchi.

Perché UUID v7 è migliore per i database

Gli ID casuali di versione 4 finiscono in tutto l’indice, quindi ogni inserimento tocca una pagina diversa. Col tempo, questo rallenta le scritture e spreca memoria. Invece UUID v7 inizia con un’ora in millisecondi, perciò ogni nuovo ID finisce in fondo all’indice, come un numero auto-incrementale.

Inoltre questo generatore tiene in ordine un blocco. Quando molti ID condividono un millisecondo, un contatore nei 12 bit successivi li mantiene ordinati, proprio come consiglia la RFC 9562, lo standard degli UUID.

UUID basati sul nome: versioni 3 e 5

Gli UUID basati sul nome nascono da due dati: uno spazio dei nomi, che è a sua volta un UUID, e un nome. La coppia passa in un hash: a dati uguali, UUID uguale. Esistono spazi standard per domini, URL, OID e nomi X.500, e inoltre puoi usarne uno tuo.

La versione 5 usa SHA-1 e la versione 3 usa MD5. Nessuno dei due hash protegge qualcosa qui. Entrambi distribuiscono soltanto i bit in modo uniforme. Tuttavia, scegli la versione 5 per un lavoro nuovo, perché lo standard la preferisce.

Leggi qualsiasi UUID con il lettore

Incolla un UUID nel controllo e si scompone subito. Vedi la forma standard, la variante e la versione. Anche le versioni 1, 6 e 7 portano un orario. Poi il controllo mostra quel momento in UTC e nel tuo fuso orario.

Per le versioni 1 e 6 mostra anche la sequenza di clock e il nodo. Un tempo il nodo era l’indirizzo della scheda di rete, perciò il lettore ti dice se sembra reale o casuale. Inoltre, un clic su un UUID della lista lo controlla subito.

Controlla un intero elenco con il validatore di UUID

Un UUID alla volta va bene, finché non ne hai quattrocento. Incolla invece l’intera lista nel validatore di UUID e ogni riga riceve il suo verdetto. La pagina divide su spazi, virgole, punti e virgola, barre verticali e ritorni a capo. Così una colonna di foglio di calcolo, un array JSON e un risultato SQL si incollano come sono. Legge fino a 5.000 ID in una volta. Poi tutto ciò che supera quel numero appare come saltato, invece di sparire in silenzio.

In particolare, qui ci sono tre verdetti, non due. Una riga conta come valida quando lo standard la descrive. Conta come non valida quando non è affatto un UUID. In mezzo sta la nota, per una riga di forma corretta che merita comunque uno sguardo. Per esempio, una vecchia variante Microsoft o NCS è un vero UUID che sistemi reali emettono ancora. Queste due varianti vengono da RFC 4122, il vecchio standard UUID. Poi c’è la variante RFC che porta un numero di versione che nessuno ha ancora assegnato, e anche quella riceve una nota. Chiamarle non valide sarebbe una bugia, perché sistemi in uso le distribuiscono ogni giorno.

Inoltre, ogni riga respinta dice perché. Una riga di una lista può non leggersi solo in tre modi. Contiene un carattere fuori da 0-9, a-f e il trattino. Ha il numero sbagliato di cifre esadecimali. Oppure ha tutte le 32 cifre con i trattini nel posto sbagliato. I primi due casi segnalano di solito una copia che ha preso un carattere di troppo, o che ha tagliato una cifra a metà. Il terzo è un UUID con i trattini fuori posto, non dopo l’ottava, la dodicesima, la sedicesima e la ventesima cifra. La riga lo dice con precisione. Le righe vuote non sono errori, perché la lista le scarta prima di contare.

L’involucro va via prima del controllo, perché le liste vere arrivano avvolte. La pagina toglie virgolette, apici inversi, parentesi quadre, parentesi angolari, parentesi tonde e i due punti o il punto finale. Toglie anche il prefisso urn:uuid:. Le graffe ricevono più cura di così. Così un GUID Microsoft tra graffe si legge intero, mentre una graffa sparsa di un oggetto JSON va via e basta. Inoltre, una sequenza nuda di 32 cifre esadecimali senza trattini si legge ancora. Lo stesso vale per qualsiasi misto di maiuscole e minuscole. Una parola che non è mai stata un ID, come una chiave JSON, tiene la sua riga invece di sparire. Così il conto resta onesto su tutto ciò che c’è nell’incolla.

Poi il validatore cerca i doppioni in tutta la lista. Il confronto avviene sulla forma canonica. Così {X}, urn:uuid:X e lo stesso ID in maiuscolo contano come uno solo. La riga ripetuta rimanda quindi alla riga in cui è comparsa per prima. Due righe di spazzatura identiche, invece, non contano mai come doppioni. Una riga che non è un UUID non ha una forma canonica da confrontare. Dopo di che il riepilogo conta la lista per te. Vedi quante righe sono passate, e quante lo standard descrive. Altri tre conteggi coprono le righe da guardare, le righe che non sono affatto UUID e i doppioni.

Quei conteggi restano separati di proposito, e il motivo conta. Una riga con nota ha una forma corretta, non una forma rotta. Ridurla a un unico numero di promossi o bocciati nasconderebbe la sola cosa che vale la pena notare. Però, se vuoi solo i problemi, il filtro lascia in vista le righe che non sono UUID. Così le righe con nota tengono il loro posto e il loro motivo. Infine il rapporto copia quello che lo schermo mostra, quindi la lista va diretta in un ticket.

UUID o GUID?

Sono la stessa cosa. GUID, identificatore unico globale, è solo il nome usato da Microsoft. Quindi questa pagina funziona anche come generatore di GUID: attiva maiuscole e parentesi graffe e ottieni lo stile {XXXXXXXX-XXXX-...} che Windows e .NET mostrano spesso.

I GUID molto vecchi di COM usavano un’altra variante. Il lettore li riconosce e li segnala, così sai quando un ID viene da quel vecchio schema.

Un UUID può mai ripetersi?

Dei 128 bit di un UUID v4, 122 sono casuali. Così servirebbero circa 2,7 quintilioni di ID prima che la probabilità di un doppione arrivi al 50%. In pratica, un bug nel tuo codice resta molto più probabile di un doppione.

Le versioni basate sul tempo usano meno bit casuali, ma aggiungono l’ora. Di conseguenza due ID si scontrano solo se nascono nello stesso millisecondo e inoltre pescano gli stessi bit. L’articolo di Wikipedia sugli UUID spiega i numeri nel dettaglio.

UUID o numeri auto-incrementali?

Gli ID auto-incrementali sono corti e veloci, ma hanno dei limiti. Prima di tutto, solo il database può assegnarli, quindi un’app deve aspettare l’inserimento per conoscere l’ID. Poi rivelano informazioni, perché l’ordine 1043 dice a chiunque che hai circa mille ordini.

Gli UUID risolvono entrambi i problemi. Qualsiasi server, telefono o browser può crearne uno offline, e gli ID di sistemi diversi si uniscono senza scontri. Tuttavia occupano più spazio, per questo la versione 7 e il salvataggio binario contano nelle tabelle grandi.

Gli UUID nel tuo codice

Gli interruttori di formato coprono i bisogni comuni. Togli i trattini per salvare meno spazio, aggiungi il prefisso urn:uuid: per XML e RDF, oppure metti ogni ID tra virgolette con le virgole, così è pronto per un array o una lista SQL.

Quasi tutti i database hanno un tipo nativo per gli UUID. PostgreSQL ha uuid, SQL Server ha uniqueidentifier e in MySQL si usa spesso BINARY(16). Inoltre, per le date nei tuoi dati, il nostro convertitore di timestamp Unix le trasforma in date e ritorno.

Questi UUID sono sicuri?

Sì. I bit casuali vengono dalla fonte sicura del tuo browser, la funzione getRandomValues di Web Crypto, pensata per chiavi e token. Inoltre nulla va al nostro server, quindi nessun altro vede gli ID che crei.

Ricorda che un UUID è un ID, non un segreto, perché chiunque lo veda può copiarlo. Per password e chiavi API usa invece il nostro generatore di password.