Générateur d’UUID : v4, v7, v5 et listes en lot

Quelle version doit vous donner un générateur d’UUID ?

Tout UUID fait 128 bits, écrits sous forme de 32 chiffres hexadécimaux répartis en cinq groupes, 8-4-4-4-12. Deux de ces chiffres servent à la tenue des comptes : le treizième est la version, et le dix-septième porte la variante (8, 9, a ou b pour les UUID de la RFC 9562). Tout le reste dépend de ce que la version y place : des bits aléatoires, un horodatage, un compteur ou un hachage. Choisir la version, c’est en réalité choisir ce que vous voulez trouver dans votre clé.

Ma règle empirique : v4, sauf si l’ID est une clé de base de données qui subit beaucoup d’insertions ; alors v7. La RFC 9562 elle-même recommande d’utiliser v7 plutôt que v1 et v6 quand c’est possible. Le v5 basé sur un nom fait figure d’exception : il ne vise pas l’unicité dans le temps, mais le fait d’obtenir deux fois la même réponse, exactement ce qu’il vous faut quand deux services doivent s’accorder sur l’ID de « https://example.com/item/42 » sans se parler. Le guide v4 vs v7 détaille le côté index de ce choix.

Un avertissement pratique sur v7 : ses 12 premiers chiffres hexadécimaux sont l’heure de création en millisecondes, lisible par n’importe qui. Collez 017f22e2-79b0-7cc3-98c4-dc0c0c07398f dans l’onglet Valider & décoder et vous obtenez l’instant exact de sa création. Si un ID est montré aux utilisateurs et que le moment de création est sensible, donnez-leur un v4.

Formats : les mêmes 128 bits, sept écritures

La plupart des erreurs « invalid UUID » que j’ai traquées ne venaient pas d’ID défectueux, simplement d’une écriture qui ne convenait pas au système d’en face. Le générateur d’UUID garde les bits et ne change que le texte, si bien que la même valeur peut aller dans chacun de ces formats :

L’option de séparateur (tiret, aucun, point ou tiret bas) ne s’applique qu’aux formes standard, majuscules et accolades ; une URN avec des points ne serait plus une URN valide, l’outil verrouille donc le séparateur pour elle. En entrée, c’est l’inverse : la RFC 9562 demande une sortie en minuscules mais une lecture insensible à la casse, et le décodeur accepte toutes les formes ci-dessus sauf Base64. Si vous avez besoin de l’ordre des octets de .NET ou des habitudes de SQL Server, lisez UUID vs GUID.

Listes en lot pour fixtures et fichiers de seed

L’onglet En lot du générateur d’UUID produit de 1 à 10 000 ID d’un coup et les exporte en texte brut, en CSV avec un en-tête uuid, en tableau JSON ou sous forme d’instruction INSERT INTO items (id) VALUES … prête à l’emploi (renommez la table et la colonne selon votre schéma). Deux détails comptent plus que la quantité :

• Les listes v7 sont strictement croissantes. Dix mille ID sont créés en quelques millisecondes, la plupart partagent donc un horodatage. Sans compteur, ils sortiraient dans un ordre aléatoire à l’intérieur de chaque milliseconde ; avec lui, la liste se trie de la même façon comme texte et comme octets, et la ligne d’info confirme « strictement croissants ».
• v5 et v3 prennent des noms, un par ligne. Collez une colonne de domaines, d’URL ou de codes produit et vous obtenez un ID déterministe par ligne, identique à ce que renvoie uuid5() de Python pour le même espace de noms et le même nom.

Deux UUID peuvent-ils être identiques ?

Pour des ID v4 aléatoires, la réponse honnête est « oui, avec une probabilité que l’on peut calculer, puis cesser de s’en soucier ». Avec 122 bits aléatoires, l’approximation du paradoxe des anniversaires donne :

Exemple chiffré : vous créez un milliard d’ID v4, n = 10⁹. Alors n² = 10¹⁸, 2 × 2¹²² ≈ 1,063 × 10³⁷, l’exposant vaut environ 9,4 × 10⁻²⁰, et p ≈ 9,4 × 10⁻²⁰. À mille milliards d’ID, on est à environ 9,4 × 10⁻¹⁴. Il faut à peu près 2,7 × 10¹⁸ ID avant que la probabilité d’un seul doublon atteigne une chance sur deux.

Le vrai risque ne vient jamais des maths, mais d’une source d’aléa faible : un extrait copié qui repose sur Math.random(), un processus forké qui réutilise sa graine, ou une image de VM clonée avec le même état. Ce générateur d’UUID tire chaque bit aléatoire de crypto.getRandomValues(), le générateur cryptographique du navigateur. Pour v7, deux générateurs indépendants n’entrent en collision que s’ils tombent sur la même milliseconde puis coïncident sur environ 73 bits aléatoires (le compteur est initialisé avec 41 bits aléatoires et 32 autres bits restent aléatoires). Mettez quand même une contrainte d’unicité sur la colonne : elle ne coûte rien et transforme un problème théorique en erreur bien visible.

Valider et décoder : ce qu’un ID vous apprend

Collez un UUID dans l’onglet Valider & décoder et vous obtenez sa forme canonique, sa version, sa variante, l’heure intégrée pour v1, v6 et v7 (en UTC et à votre heure locale), la séquence d’horloge et le nœud de v1/v6, ainsi que ses écritures hex BINARY(16) et Base64. Le contrôle du nœud vous dit si un ID v1 porte un nœud aléatoire (bit multicast à 1, comme le recommande la RFC 9562) ou quelque chose qui ressemble à l’adresse d’une vraie carte réseau, une fuite de vie privée qu’il vaut mieux connaître.

Collez plutôt toute une colonne et cela devient une vérification de liste : combien de lignes sont valides, lesquelles ne le sont pas et pourquoi (« 31 chiffres hexadécimaux trouvés », « les tirets doivent découper les chiffres en 8-4-4-4-12 »), combien sont des doublons, si la liste est en ordre croissant, et quelles versions elle contient. C’est le moyen le plus rapide que je connaisse pour auditer un fichier d’import avant qu’il ne bute sur un index unique.

Il est aussi strict là où les anciens validateurs étaient laxistes. Un UUID dont le chiffre de version vaut 0 n’est pas l’UUID nil, sauf si ses 32 chiffres sont tous à zéro ; un ID à la variante historique Microsoft (dix-septième chiffre c ou d) est bien formé, mais son chiffre de version ne signifie rien, et le résultat le dit au lieu d’inventer une version.

Stocker des UUID sans regret

1. Utilisez le type natif. Le type uuid de PostgreSQL et le uniqueidentifier de SQL Server stockent 16 octets. Une colonne texte de 36 caractères prend plus du double dans la table et dans chaque index qui l’inclut. Sous MySQL, utilisez BINARY(16) ; le format 0x vous donne le littéral.
2. Choisissez v7 pour les clés clusterisées ou à fort volume d’insertions. Les nouvelles valeurs v7 arrivent en fin d’index au lieu de tomber sur des pages au hasard.
3. Gardez une seule écriture canonique dans votre API. En minuscules, avec tirets. Comparez sans tenir compte de la casse si vous acceptez des entrées venant d’autres systèmes.
4. Ne traitez jamais un UUID comme un secret. La RFC 9562 dit de ne pas supposer qu’un UUID est difficile à deviner. Les liens de réinitialisation de mot de passe et les clés d’API exigent un jeton aléatoire dédié.
5. Ne livrez pas de v1 avec une vraie adresse MAC. Elle identifie la machine et l’instant. Cet outil utilise toujours un nœud aléatoire.

Pour les one-liners qui créent des UUID en PostgreSQL, JavaScript, Python, Java et C#, voyez comment générer un UUID dans le code.

D’où viennent les bits, et comment je les teste

Tout se passe dans votre navigateur ; la page n’envoie rien nulle part. Les bits aléatoires viennent de crypto.getRandomValues(). La version 7 suit la méthode 1 de la RFC 9562 §6.2 avec un compteur de 42 bits (le même schéma que uuid7() de Python) : une nouvelle graine aléatoire à chaque nouvelle milliseconde, puis +1 pour chaque ID supplémentaire dans cette milliseconde, et si l’horloge recule, le dernier horodatage est réutilisé pour que l’ordre ne soit jamais rompu. Les versions 1 et 6 comptent des intervalles de 100 nanosecondes depuis le début du calendrier grégorien, ajoutent un intervalle par ID dans la même milliseconde et utilisent un nœud aléatoire avec le bit multicast à 1. Les versions 5 et 3 hachent les 16 octets de l’espace de noms suivis du nom en UTF-8 avec SHA-1 ou MD5, puis fixent les bits de version et de variante, exactement comme le décrivent le texte de la RFC 9562 et le module uuid de Python.

Le script qui tournait auparavant sur ce site avait un vrai bug, que je préfère avouer : son calcul d’horodatage v1 débordait d’un entier signé sur 32 bits, si bien que pendant environ la moitié de chaque tranche de sept minutes, il produisait des ID commençant par un signe moins. Sa sortie v7 n’était pas non plus triée à l’intérieur d’une milliseconde. Les deux problèmes sont corrigés, et voici quelques-uns des cas de contrôle sur lesquels l’outil est testé à chaque modification :