Valider un UUID

La forme peut être vérifiée complètement : trente-deux chiffres hexadécimaux en groupes de huit, quatre, quatre, quatre et douze, avec la version sur un quartet et la variante sur les bits de poids fort d’un autre. Tout cela se décide à partir de la chaîne seule, et c’est ce que « UUID valide » veut dire.

Ce qui ne peut pas être vérifié, c’est s’il a été produit correctement. Un UUID de version 4 fabriqué avec `Math.random` a la bonne forme, le bon quartet de version et les bons bits de variante — il est faible, et rien dans la chaîne ne le dit. La validation est un contrôle de syntaxe, et aucun contrôle de syntaxe ne voit l’entropie.

Le treizième chiffre hexadécimal — le premier du troisième groupe — est la version. Un 4 signifie que l’identifiant est aléatoire. Un 1 ou un 6 signifie qu’il embarque un horodatage et un identifiant de machine, et divulgue donc à peu près quand et sur quoi il a été fabriqué. Un 3 ou un 5 signifie qu’il est le hash d’un nom dans un espace de noms, et donc reproductible à partir de ce nom.

Un 7 est la nouvelle version ordonnée dans le temps, de plus en plus employée comme clé de base parce qu’elle s’insère séquentiellement. Tout autre chiffre correspond soit à un UUID issu d’un schéma antérieur aux règles de version, soit — bien plus souvent — à une chaîne hexadécimale aléatoire que quelqu’un a mise en forme pour ressembler à un UUID.

Les bits de poids fort du dix-septième chiffre disent quelle disposition le reste suit. Pratiquement tout ce qui est produit aujourd’hui relève de la variante RFC 4122, où ces bits valent `10`. Les autres sont historiques : la disposition Apollo NCS, la disposition GUID d’origine de Microsoft avec son ordre d’octets différent, et une plage réservée.

Cela vaut la peine d’être lu quand un identifiant est refusé par un analyseur strict alors qu’un analyseur permissif l’acceptait. Une valeur portant des bits de variante historiques est bien formée et n’est pas ce qu’une bibliothèque moderne attend, et ce désaccord reste invisible tant que rien ne vous dit quelle variante vous tenez.

Trente-deux zéros forment un UUID valide au sens défini : aucune valeur. Il apparaît là où une colonne qui aurait dû accepter le nul ne le pouvait pas, là où une valeur par défaut n’a jamais été remplacée, et là où un client a envoyé un espace réservé qu’il comptait remplir.

Il est signalé séparément ici parce que c’est la seule valeur qui passe tous les contrôles en étant presque toujours un défaut au vu du contexte. Une ligne dont l’identifiant est l’UUID nil est une ligne pour laquelle rien n’a généré d’identifiant.

L’outillage Windows — le registre, COM, `New-Guid` en PowerShell — écrit les UUID entourés d’accolades. Le RFC 4122 définit une forme URN avec un préfixe `urn:uuid:`. Les deux sont des façons ordinaires d’en rencontrer un, et un validateur qui refuserait l’une ou l’autre refuserait, pour un détail de mise en forme, précisément la chose qu’il existe pour inspecter.

Ce qui n’est pas accepté, c’est la forme sans tirets. Elle est courante dans les URL et dans certaines bases, et elle est réellement ambiguë : trente-deux chiffres hexadécimaux peuvent être un UUID, ou un MD5, ou la moitié d’un SHA-256. La signaler comme un UUID serait une supposition déguisée en verdict.

Un ULID fait vingt-six caractères en base 32 et se trie dans le temps ; un identifiant Nano fait vingt et un caractères d’un alphabet plus large ; un objet Mongo fait vingt-quatre chiffres hexadécimaux. Aucun n’a de tirets aux bonnes places, et tous sont refusés ici, ce qui est correct et parfois surprenant.

Le point utile est qu’un système qui documente un « UUID » et livre l’un de ces trois vous dit surtout que sa documentation a vieilli. La longueur tranche immédiatement : trente-six caractères avec quatre tirets, ou autre chose.

Le RFC 4122 demande de produire les UUID en minuscules et d’en accepter la lecture dans les deux casses. Une valeur en majuscules est donc valide, et cette page l’accepte, mais elle n’est pas canonique.

La conséquence se voit sur les comparaisons. Deux systèmes qui stockent le même identifiant dans deux casses différentes ne se joindront jamais si la comparaison se fait sur des chaînes, et les deux colonnes contiendront visiblement la même valeur. Normalisez en minuscules au moment de l’écriture ; c’est plus simple que de comparer sans tenir compte de la casse partout.

Un UUID bien formé ne prouve pas qu’il a été émis par votre système, ni qu’il correspond à quoi que ce soit. C’est une chaîne conforme, et n’importe qui peut en fabriquer une valide en quelques secondes.

C’est pourquoi une validation de format ne remplace jamais une vérification en base. Un point d’entrée qui accepte un identifiant fourni par l’extérieur doit vérifier qu’il existe et que l’appelant a le droit de le voir ; contrôler seulement la forme donne un système qui refuse les fautes de frappe et laisse passer tout le reste.

Un UUID est un nombre de 128 bits, c’est-à-dire seize octets. La forme textuelle en occupe trente-six avec les tirets, soit plus du double, ce qui explique pourquoi certaines bases proposent un type binaire dédié et pourquoi d’autres stockent la forme sans tirets.

Le choix a des conséquences mesurables sur une grande table : seize octets par ligne au lieu de trente-six, index compris, plus la comparaison qui devient numérique au lieu de textuelle. Le coût est la lisibilité — une valeur binaire ne se lit pas dans une console — et c’est un arbitrage à faire une fois, au moment de la conception du schéma.