Générateur d’UUID
Toutes les versions, en lot, avec lecteur

Ce que fait ce générateur d’UUID

Ce générateur d’UUID crée des ID uniques pour les bases de données, les API, les fichiers et les tests. D’abord, choisissez une version et une quantité, puis la liste apparaît aussitôt. Ensuite, vous pouvez la copier ou l’enregistrer en fichier texte.

Il couvre toutes les versions utilisées aujourd’hui. La version 4 est purement aléatoire, la 7 se trie par date, et les versions 3 et 5 transforment un nom toujours en même ID. De plus, il y a les anciennes versions 1 et 6, ainsi que les valeurs spéciales nil et max.

La page fonctionne aussi dans l’autre sens. Collez un UUID, puis le lecteur indique sa version et sa variante et, pour ceux basés sur le temps, le moment exact de leur création.

Qu’est-ce qu’un UUID ?

Un UUID, ou identifiant unique universel, est un nombre de 128 bits. On l’écrit souvent en 32 chiffres hexadécimaux répartis en cinq groupes, comme 017f22e2-79b0-7cc3-98c4-dc0c0c07398f. Comme il existe énormément de valeurs possibles, chacun peut en créer un sans demander à un serveur central, et il ne croisera celui de personne.

Deux petites parties indiquent le type d’UUID. Le premier chiffre du troisième groupe est la version, et le premier chiffre du quatrième groupe contient la variante. Tout le reste est donc du temps, du hasard ou un hachage, selon la version.

Quelle version d’UUID choisir ?

Pour la plupart des usages, prenez la version 4, car elle est aléatoire, simple et reconnue partout. Cependant, si les ID deviennent des clés de table, choisissez plutôt la version 7. Elle commence par l’heure, donc les nouvelles lignes sont rangées dans l’ordre, et les insertions restent rapides.

Quand un élément doit toujours recevoir le même ID, utilisez la version 5. Ainsi, une URL ou une adresse e-mail peut devenir un UUID stable que tout système peut recréer. En revanche, les versions 1, 3 et 6 servent surtout aux anciens systèmes.

Pourquoi UUID v7 convient mieux aux bases de données

Les ID aléatoires de version 4 se dispersent dans tout l’index, donc chaque insertion touche une page différente. Avec le temps, cela ralentit les écritures et gaspille de la mémoire. En revanche, UUID v7 commence par un horodatage en millisecondes, ainsi chaque nouvel ID arrive en fin d’index, comme un numéro auto-incrémenté.

De plus, ce générateur garde un lot dans l’ordre. Quand plusieurs ID partagent une milliseconde, un compteur dans les 12 bits suivants les garde triés, comme le recommande la RFC 9562, la norme des UUID.

UUID basés sur un nom : versions 3 et 5

Les UUID basés sur un nom viennent de deux entrées : un espace de noms, qui est lui-même un UUID, et un nom. Le couple est haché : à entrées identiques, UUID identique. Il existe des espaces standard pour les domaines, les URL, les OID et les noms X.500, et vous pouvez aussi utiliser le vôtre.

La version 5 utilise SHA-1 et la version 3 utilise MD5. Aucun de ces hachages ne protège quoi que ce soit ici. Tous deux répartissent seulement les bits de façon régulière. Pourtant, choisissez la version 5 pour un nouveau projet, car la norme la préfère.

Lisez n’importe quel UUID avec le lecteur

Collez un UUID dans le vérificateur et il se découpe aussitôt. Vous voyez la forme standard, la variante et la version. Les versions 1, 6 et 7 portent aussi un horodatage. Ensuite, le vérificateur montre cet instant en UTC et dans votre propre fuseau.

Pour les versions 1 et 6, il montre aussi la séquence d’horloge et le nœud. Autrefois, le nœud était l’adresse de la carte réseau, c’est pourquoi le lecteur indique s’il semble réel ou aléatoire. De plus, un clic sur un UUID de la liste le vérifie aussitôt.

Vérifier toute une liste avec le validateur d’UUID

Un UUID à la fois suffit, jusqu’au jour où vous en avez quatre cents. Collez plutôt toute la liste dans le validateur d’UUID et chaque ligne reçoit son verdict. La page découpe sur les espaces, les virgules, les points-virgules, les barres verticales et les sauts de ligne. Ainsi, une colonne de tableur, un tableau JSON et un résultat SQL se collent tels quels. Elle lit jusqu’à 5 000 identifiants d’un coup. Ensuite, tout ce qui dépasse ce nombre apparaît comme ignoré au lieu de disparaître en silence.

Notamment, il y a ici trois verdicts, pas deux. Une ligne compte comme valide quand la norme la décrit. Elle compte comme invalide quand ce n’est pas un UUID du tout. Entre les deux se place la remarque, pour une ligne de forme correcte qui mérite quand même un regard. Par exemple, une ancienne variante Microsoft ou NCS est un vrai UUID que de vrais systèmes émettent encore. Ces deux variantes viennent de RFC 4122, l’ancienne norme UUID. Ensuite vient la variante RFC qui porte un numéro de version que personne n’a encore attribué, et elle reçoit aussi une remarque. Les déclarer invalides serait un mensonge, car des systèmes en service en distribuent chaque jour.

Aussi, chaque ligne rejetée dit pourquoi. Une ligne d’une liste peut échouer à la lecture de trois façons seulement. Elle contient un caractère hors de 0-9, a-f et le trait d’union. Elle a le mauvais nombre de chiffres hexadécimaux. Ou elle a bien 32 chiffres avec les traits d’union au mauvais endroit. Les deux premiers cas signalent d’habitude une copie qui a happé un caractère parasite, ou qui a rogné un chiffre en route. Le troisième est un UUID dont les traits d’union tombent ailleurs qu’après le 8e, le 12e, le 16e et le 20e chiffre. La ligne le dit exactement. Les lignes vides ne sont pas des erreurs du tout, car la liste les écarte avant de compter.

L’habillage part avant le contrôle, car les vraies listes arrivent habillées. La page retire les guillemets, les accents graves, les crochets, les chevrons, les parenthèses et un deux-points ou un point final. Elle retire aussi le préfixe urn:uuid:. Les accolades reçoivent plus de soin que cela. Ainsi, un GUID Microsoft entre accolades se lit entier, tandis qu’une accolade égarée d’un objet JSON s’en va simplement. De plus, une suite nue de 32 chiffres hexadécimaux sans trait d’union se lit encore. Tout mélange de majuscules et de minuscules aussi. Un mot qui n’a jamais été un identifiant, comme une clé JSON, garde sa propre ligne au lieu de disparaître. Ainsi le compte reste honnête sur tout ce que contient le collage.

Ensuite, le validateur cherche les doublons dans toute la liste. La comparaison porte sur la forme canonique. Donc {X}, urn:uuid:X et le même identifiant en majuscules comptent pour un seul. La ligne répétée renvoie alors à la ligne où elle est apparue d’abord. Deux lignes de rebut identiques, en revanche, ne comptent jamais comme doublons. Une ligne qui n’est pas un UUID n’a aucune forme canonique à comparer. Après cela, le résumé compte la liste pour vous. Vous voyez combien de lignes sont passées, et combien la norme décrit. Trois autres compteurs couvrent les lignes à regarder, les lignes qui ne sont pas des UUID du tout et les doublons.

Ces compteurs restent séparés exprès, et la raison compte. Une ligne remarquée a une forme correcte plutôt qu’une forme cassée. La replier dans un seul chiffre réussi ou raté cacherait la seule chose qui mérite l’attention. Cependant, si vous ne voulez que les problèmes, le filtre laisse en vue les lignes qui ne sont pas des UUID. Ainsi les lignes remarquées gardent leur place et leur raison. Enfin, le rapport recopie ce que l’écran montre, donc la liste part directement dans un ticket.

UUID ou GUID ?

C’est la même chose. GUID, pour identifiant global unique, est simplement le nom employé par Microsoft. Cette page sert donc aussi de générateur de GUID : activez les majuscules et les accolades, et vous obtenez le style {XXXXXXXX-XXXX-...} que Windows et .NET affichent souvent.

Les très vieux GUID de COM utilisaient une autre variante. Le lecteur les repère et les signale, ainsi vous savez quand un ID vient de cet ancien système.

À quel point un UUID est-il unique ?

Sur les 128 bits d’un UUID v4, 122 sont aléatoires. Donc il faudrait environ 2,7 quintillions d’identifiants avant que le risque d’un doublon atteigne 50 %. En pratique, un bug dans votre propre code reste bien plus probable qu’un doublon.

Les versions basées sur le temps utilisent moins de bits aléatoires, mais ajoutent l’heure. Par conséquent, deux ID ne se heurtent que s’ils naissent dans la même milliseconde et tirent en plus les mêmes bits. L’article de Wikipédia sur les UUID détaille ces calculs.

UUID ou numéros auto-incrémentés ?

Les ID auto-incrémentés sont courts et rapides, mais ils ont des limites. D’abord, seule la base de données peut les attribuer, donc une app doit attendre l’insertion pour connaître l’ID. Ensuite, ils trahissent des informations, car la commande 1043 révèle que vous avez environ mille commandes.

Les UUID règlent ces deux problèmes. Tout serveur, téléphone ou navigateur peut en créer un hors ligne, et les ID de systèmes différents se fusionnent sans conflit. En revanche, ils prennent plus de place, c’est pourquoi la version 7 et le stockage binaire comptent sur les grandes tables.

Générer des UUID depuis votre code

Les options de format couvrent les besoins courants. Retirez les tirets pour un stockage compact, ajoutez le préfixe urn:uuid: pour XML et RDF, ou encore placez chaque ID entre guillemets avec des virgules, prêt à coller dans un tableau ou une liste SQL.

La plupart des bases ont un type natif pour les UUID. PostgreSQL a uuid, SQL Server a uniqueidentifier, et dans MySQL on choisit souvent BINARY(16). Par ailleurs, pour les horodatages de vos données, notre convertisseur de timestamp Unix les transforme en dates et inversement.

Peut-on se fier à ces UUID ?

Oui. Les bits aléatoires viennent de la source sûre de votre navigateur, la fonction getRandomValues de Web Crypto, conçue pour les clés et les jetons. De plus, rien n’est envoyé à notre serveur, donc personne d’autre ne voit vos ID.

Rappelez-vous qu’un UUID est un identifiant, pas un secret, car quiconque le voit peut le copier. Pour les mots de passe et les clés d’API, utilisez plutôt notre générateur de mots de passe.