Validare un UUID

Si controlla la forma: trentadue cifre esadecimali disposte in cinque gruppi da 8, 4, 4, 4 e 12, e i due campi che la specifica riserva per la versione e per la variante. È un controllo puramente locale, che si fa guardando la stringa e nient’altro.

Non si controlla nulla che riguardi il mondo. Che quell’identificatore esista in una tabella, che sia mai stato assegnato, che appartenga al sistema da cui pensi che venga: sono tutte domande a cui può rispondere solo il database che lo contiene. Un UUID ben formato e completamente inventato è indistinguibile da uno reale, e questa è una proprietà del formato, non un limite dello strumento.

La versione è la prima cifra del terzo gruppo, sempre nella stessa posizione: in `xxxxxxxx-xxxx-4xxx-yxxx-xxxxxxxxxxxx` è quel `4`. Si legge a occhio, senza contare i caratteri, ed è il motivo per cui riconoscere un UUID versione 4 richiede mezzo secondo una volta che si sa dove guardare.

I valori che si incontrano davvero sono quattro. `1` è basato sul tempo e sull’indirizzo di rete, `3` e `5` sono derivati da un nome tramite un hash, `4` è casuale, `7` è ordinato nel tempo. Sapere quale hai in mano cambia il modo in cui va trattato: la versione 1 e la 7 dichiarano quando sono state create, la 3 e la 5 sono ricalcolabili da chi conosca il nome di partenza.

La variante sta nella prima cifra del quarto gruppo e dice a quale famiglia di specifiche l’identificatore appartiene. Quella normale, definita dalla RFC 4122 e poi dalla RFC 9562, si riconosce perché quella cifra vale `8`, `9`, `a` o `b`.

Gli altri valori esistono e appaiono raramente: `0`-`7` indica la variante riservata al vecchio spazio dei nomi NCS, e `c` o `d` quella di Microsoft, che si incontra in GUID prodotti da sistemi COM di parecchi anni fa. Non sono errori, e uno strumento che li segnalasse come tali sbaglierebbe: sono identificatori legittimi di un’altra famiglia, ed è utile saperlo prima di andare a cercare un difetto che non c’è.

La forma canonica è in minuscolo, senza decorazioni. Le maiuscole sono comunque ammesse dalla specifica in lettura, le parentesi graffe sono la convenzione di Windows e dell’ecosistema COM, e il prefisso `urn:uuid:` è la forma prevista per un identificatore usato come URN.

Tutte e tre vengono accettate qui, perché chi incolla un identificatore lo ha copiato da dove stava e non ha nessun motivo per ripulirlo prima. Il punto in cui la differenza fa danno è il confronto: due sistemi che scrivono lo stesso valore in due forme diverse producono un mancato riscontro che assomiglia a un dato mancante. Si normalizza al momento del salvataggio, non a quello del confronto.

Un UUID versione 1 non è casuale: contiene l’istante di creazione con precisione di cento nanosecondi e, nella forma classica, l’indirizzo MAC della scheda di rete della macchina che lo ha prodotto. Se ne trovi uno, quelle due informazioni sono già in tuo possesso.

Vuol dire che un identificatore del genere in una URL pubblica, in un file esportato o in una risposta di API racconta quando è stato creato un record e su quale macchina, il che permette anche di ricostruire l’ordine e la frequenza delle creazioni. Se in un sistema tuo compaiono UUID versione 1 in punti visibili all’esterno, è una cosa da annotare: non è un difetto di sicurezza acuto, ma è una divulgazione che nessuno aveva deciso.

La versione 7 mette un timestamp in millisecondi nella parte iniziale e riempie il resto di casualità. È stata standardizzata dalla RFC 9562 nel 2024, dopo anni di implementazioni che facevano la stessa cosa ciascuna a modo suo.

Il motivo del suo successo è l’indice di un database: le chiavi crescenti si inseriscono in coda a un B-tree, quelle casuali in punti sparsi, e su tabelle grandi la differenza in scritture e in uso della cache è misurabile. Il prezzo è che l’identificatore dichiara quando è stato creato, il che va benissimo per una chiave primaria interna e molto meno per qualcosa che comparirà in una URL pubblica.

L’UUID composto da soli zeri è previsto dalla specifica e si chiama nil: significa «nessuno», ed è la forma corretta per un valore assente dove il tipo richiede comunque un UUID. Qui viene riconosciuto come ben formato, perché lo è, con una nota che dice cos’è.

La RFC 9562 ha aggiunto anche il suo opposto, il max UUID fatto di sole `f`, usato come limite superiore in un intervallo. Entrambi passano la validazione di forma e nessuno dei due identifica qualcosa: se compaiono in dati reali, quasi sempre sono il segno di un campo non valorizzato che ha attraversato un sistema che non ammetteva un valore nullo.

Il difetto più comune non è un carattere sbagliato ma un carattere in meno, di solito per un copia-incolla che si è fermato presto. Un UUID sono trentasei caratteri con i trattini e trentadue senza; qualunque altro numero è la spiegazione, e viene detta esplicitamente.

Il secondo caso è un carattere fuori dal repertorio esadecimale. Le confusioni tipiche sono la `o` al posto dello zero e la `l` al posto dell’uno, che nascono da un identificatore letto a video e ridigitato a mano. È anche il motivo per cui un UUID non andrebbe mai trascritto: la forma è progettata per essere copiata, non per essere letta ad alta voce.

Il controllo guarda la stringa e basta: non c’è nessuna interrogazione verso un servizio, nessun registro di identificatori e nessuna richiesta di rete. È una conseguenza tecnica del fatto che versione e variante siano scritte nella stringa stessa, ed è anche la garanzia più semplice da verificare, perché nel pannello di rete non c’è niente da vedere.

Conta perché un UUID incollato qui è quasi sempre un identificatore reale di un record reale, spesso di una persona. Nel senso del GDPR un identificatore assegnato a qualcuno è un dato personale come lo sarebbe un numero cliente: il fatto che non contenga nulla di leggibile non lo toglie dal perimetro, e non farlo viaggiare è il modo più semplice di non doverlo giustificare.