Generatore UUID v4
Genera UUID v4 casuali con sicurezza crittografica
…
Formatta
UUID v4 è la versione UUID più diffusa nei software moderni. A differenza delle versioni correlate che derivano i bit da un timestamp o da un hash di namespace, UUID v4 è interamente costruito da dati casuali — rendendolo la scelta più semplice e portabile quando si ha bisogno di un identificatore univoco privo di metadati sulla sua origine.
Questo generatore utilizza crypto.randomUUID(), l'API nativa del browser e di Node.js, che attinge l'entropia dal generatore di numeri casuali crittograficamente sicuro del sistema operativo — la stessa fonte usata per le chiavi TLS.
Cos'è UUID v4?
Un Identificatore Universalmente Unico (UUID) è un'etichetta a 128 bit standardizzata in RFC 4122. È tipicamente rappresentato come 32 cifre esadecimali raggruppate con trattini nel pattern 8-4-4-4-12:
In UUID v4, 122 dei 128 bit sono casuali. I 6 bit rimanenti sono campi fissi imposti dalla specifica: 4 bit codificano la versione (0100 = 4) e 2 bit codificano la variante RFC 4122 (10). Questi bit fissi spiegano perché il terzo gruppo inizia sempre con 4 e il quarto gruppo inizia sempre con 8, 9, a o b.
Anatomia di un UUID v4
Scomposizione di 550e8400-e29b-41d4-a716-446655440000:
| Segmento | Bit | Significato |
|---|---|---|
| 550e8400 | 32 casuali | time_low (nome storico — completamente casuale in v4) |
| e29b | 16 casuali | time_mid (nome storico — completamente casuale in v4) |
| 41d4 | 4 fissi + 12 casuali | Nibble di versione 4 (binario 0100) + 12 bit casuali |
| a716 | 2 fissi + 14 casuali | Bit di variante 10 (MSB del primo byte) + 14 bit casuali |
| 446655440000 | 48 casuali | node (completamente casuale in v4) |
8, 9, a o b — perché i due bit più significativi di quel byte sono fissi a 10 (il marcatore di variante RFC 4122), lasciando liberi i due bit rimanenti.UUID v4 vs altre versioni
RFC 4122 definisce cinque versioni UUID. Ognuna risolve un problema diverso:
Combina un timestamp a 60 bit (intervalli di 100 nanosecondi da ott. 1582) con l'indirizzo MAC dell'host. Monotonicamente crescente su una macchina.
Use when: si ha bisogno di ID ordinati nel tempo e non ci si preoccupa di rivelare l'identità del server e il tempo di generazione.
Deterministico: lo stesso namespace + nome produce sempre lo stesso UUID. Usa l'hashing MD5.
Use when: si ha bisogno di ID riproducibili da un namespace noto (es. nomi DNS). Preferire v5 a v3.
122 bit di casualità crittograficamente sicura. Nessun timestamp, nessun MAC, nessun namespace. La scelta generica più comune.
Use when: si ha bisogno di ID univoci senza significato strutturale e con massima privacy.
Come v3 ma usa SHA-1. Ancora deterministico da namespace + nome.
Use when: si ha bisogno di identificatori riproducibili e content-addressed (es. ID stabili per risorse identificate da URL).
Più recente (RFC 9562, 2024). Codifica un timestamp Unix in millisecondi nei bit più significativi, poi bit casuali. Ordinabile e adatto ai database.
Use when: si ha bisogno di ID compatibili con gli indici dei database con ordinamento temporale naturale (preferire a v1 per i nuovi progetti).
Quando usare UUID v4
UUID v4 è lo strumento giusto nella grande maggioranza delle situazioni in cui si ha semplicemente bisogno di un ID univoco senza vincoli aggiuntivi:
ID utente e account
ID utente opachi che non rivelano nulla sul tempo di creazione dell'account o sull'identità del server. Impossibili da enumerare o indovinare.
Chiavi primarie di database
Funziona con qualsiasi motore di database. UUID v4 è sicuro da generare lato client e unire da fonti distribuite senza coordinazione — nessuna tabella di sequenze o servizio ID centrale richiesto.
ID di sessione e token
122 bit di casualità rendono la ricerca a forza bruta computazionalmente infeasible — paragonabile in forza a un token casuale da 122 bit.
Nomi di file e oggetti
Nomi di file sicuri per i duplicati per upload, chiavi oggetto S3 o voci di cache. Nessun rischio che due client scrivano sulla stessa chiave.
Chiavi di idempotenza
Generare un UUID lato client prima di inviare una richiesta. Il server può deduplicare in modo sicuro le richieste ripetute senza un contatore condiviso.
ID di correlazione e traccia
Allegare un UUID a ogni riga di log e span di traccia distribuita. Nessuna coordinazione necessaria tra servizi o macchine.
Probabilità di collisione
Con 122 bit casuali, lo spazio UUID v4 contiene 2122 ≈ 5,3 × 1036 valori possibili. La probabilità di una collisione segue il problema del compleanno:
Il benchmark comunemente citato: per avere una probabilità del 50% di una singola collisione, si dovrebbero generare circa 2,71 × 1018 UUID. A un ritmo di 1 miliardo di UUID al secondo, ci vorrebbero circa 85 anni di generazione continua. Per qualsiasi applicazione reale, le collisioni non sono una preoccupazione pratica.
Esempi di codice
JavaScript — Browser e Node.js 14.17+
Il metodo crypto.randomUUID() è disponibile nativamente in tutti i browser moderni (Chrome 92+, Firefox 95+, Safari 15.4+) e in Node.js 14.17+. Nessuna installazione di pacchetto richiesta.
// Browser or Node.js 14.17+
const id = crypto.randomUUID()
// → "110e8400-e29b-41d4-a716-446655440000"
// Generate multiple
const ids = Array.from({ length: 5 }, () => crypto.randomUUID())Node.js — versioni precedenti (pacchetto uuid)
const { v4: uuidv4 } = require('uuid')
const id = uuidv4()
// → "110e8400-e29b-41d4-a716-446655440000"Python
import uuid # Generate a UUID v4 id = str(uuid.uuid4()) # → '110e8400-e29b-41d4-a716-446655440000' # The uuid module uses os.urandom() — cryptographically secure print(uuid.uuid4().hex) # without hyphens # → '110e8400e29b41d4a716446655440000'
Go
import "github.com/google/uuid" id := uuid.New().String() // → "110e8400-e29b-41d4-a716-446655440000" // Or using the standard library (Go 1.20+ with math/rand/v2 is NOT cryptographic) // Always prefer github.com/google/uuid for production use
Rust
# Cargo.toml
[dependencies]
uuid = { version = "1", features = ["v4"] }use uuid::Uuid; let id = Uuid::new_v4().to_string(); // → "110e8400-e29b-41d4-a716-446655440000"
Domande Frequenti
UUID v4 è crittograficamente sicuro?
UUID v4 di per sé non è una primitiva di sicurezza — è un formato identificatore. Tuttavia, quando generato tramite crypto.randomUUID() (browser o Node.js) o API equivalenti a livello OS, l'entropia sottostante è crittograficamente sicura. Ciò significa che i valori UUID v4 sono adatti per token di sessione o chiavi di idempotenza, dove l'imprevedibilità conta. Non usare generatori UUID basati su Math.random() per contesti sensibili alla sicurezza — usare solo API che attingono esplicitamente dal CSPRNG dell'OS.
Due UUID v4 possono mai essere uguali?
Teoricamente sì, ma praticamente no. La probabilità di generare un duplicato in qualsiasi dataset realistico (miliardi di ID) è astronomicamente piccola — molto meno probabile di un guasto hardware che causa corruzione dei dati. La collisione UUID v4 è trattata come impossibile nel design dei sistemi di produzione. Se si ha davvero bisogno di una garanzia di zero collisioni, usare un contatore centralizzato o una sequenza di database.
UUID v4 vs nanoid — quale usare?
Entrambi sono generatori di ID casuali supportati da un CSPRNG. Le differenze chiave:
- UUID v4 segue lo standard RFC 4122, è riconosciuto da ogni database e framework, e non richiede dipendenze (nativo
crypto.randomUUID()). - nanoid usa un alfabeto URL-safe ed è più corto per default (21 chars vs 36). Utile quando la lunghezza URL o la leggibilità conta. Richiede un pacchetto npm.
Preferire UUID v4 quando l'interoperabilità con sistemi esterni conta (API, database, infrastruttura di logging). Preferire nanoid quando si vogliono ID più corti e si controlla lo stack completo.
Devo memorizzare gli UUID come stringhe o binari nei database?
Per la maggior parte dei database, memorizzare in una colonna UUID o BINARY(16) (16 byte) è più efficiente di una stringa VARCHAR(36) (36 byte). PostgreSQL ha un tipo uuid nativo. MySQL e MariaDB funzionano bene con BINARY(16) e gli helper UUID_TO_BIN() / BIN_TO_UUID(). Gli utenti SQLite tipicamente memorizzano come TEXT. La scelta di memorizzazione non ha effetto sull'unicità o sulla correttezza.
Perché UUID v4 ha i trattini — e posso ometterli?
I trattini fanno parte della rappresentazione UUID canonica definita da RFC 4122. Sono puramente cosmetici — non portano informazioni e non influenzano il valore a 128 bit. Ometterli dà una stringa esadecimale compatta di 32 caratteri funzionalmente equivalente. La maggior parte dei parser UUID accetta entrambe le forme. In caso di dubbio, usare la forma canonica con trattini per la massima compatibilità con strumenti e database di terze parti.
const id = crypto.randomUUID() // "550e8400-e29b-41d4-a716-446655440000"
const compact = id.replaceAll('-', '') // "550e8400e29b41d4a716446655440000"