Outil en ligne de génération UUID

1. 1

   Choisissez la version de l'UUID

   La version 4 est aléatoire et constitue le choix par défaut sûr. La version 7 est ordonnée dans le temps et convient mieux à une clé de base de données. Les versions 3 et 5 transforment un nom en un identifiant qui ne change jamais. Les versions 1 et 6 intègrent un horodatage, et Nil et Max sont les deux valeurs spéciales fixes.

2. 2

   Indiquez la quantité

   Saisissez un nombre ou utilisez un préréglage. Cent par clic sont gratuits ; les lots plus grands, jusqu'à un million à la fois, relèvent de Pro. Pour les versions 3 et 5, la quantité provient de la liste de noms que vous collez.

3. 3

   Choisissez leur apparence

   Passez des minuscules aux majuscules, retirez les tirets pour la forme compacte, entourez les valeurs d'accolades ou du préfixe urn:uuid:, et ajoutez un préfixe ou un suffixe si vous les collez directement dans du code.

4. 4

   Générez

   Appuyez sur le bouton de génération. Chaque valeur est produite sur votre appareil à partir de sa source cryptographique d'aléa, sans rien envoyer à un serveur.

5. 5

   Copiez ou exportez

   Copiez une valeur avec le bouton situé à côté, copiez le lot entier d'un coup, ou téléchargez la liste en texte brut, JSON, CSV ou Base64.

6. 6

   Vérifiez des identifiants existants

   Passez en mode Vérifier et collez une liste, ou déposez un fichier texte, CSV, JSON ou journal. Chaque valeur est décrite avec sa version, sa variante, son heure de création intégrée et son nœud, et les doublons sont comptés.

La RFC 9562 a remplacé la RFC 4122 en mai 2024 et ajouté trois nouvelles versions ainsi que deux valeurs spéciales. Cette page génère toutes celles qu'un navigateur peut honnêtement produire. Chaque entrée indique ce que contient la valeur et la situation dont elle est la bonne réponse.

• Version 4 — aléatoire — 122 bits d'aléa et rien d'autre. Imprévisible, ne porte aucune information sur le moment ni le lieu de sa création, et constitue le bon choix par défaut dès lors que vous n'avez aucune exigence au-delà de l'unicité.
• Version 7 — ordonnée dans le temps — Un horodatage de 48 bits en millisecondes suivi d'aléa. Se trie par date de création en simple chaîne de caractères, ce qui en fait la recommandation moderne pour les clés primaires. Nouveauté de la RFC 9562.
• Version 1 — basée sur le temps — Un horodatage de 60 bits compté en intervalles de 100 nanosecondes depuis 1582, plus une séquence d'horloge et un nœud. Largement prise en charge et largement déployée, mais l'ordre de ses champs empêche les chaînes de se trier dans le temps.
• Version 6 — basée sur le temps, réordonnée — Les mêmes trois champs que la version 1, stockés en commençant par le poids fort pour que les chaînes se trient. Conçue comme remplaçante directe de la version 1 dans les systèmes qui ne peuvent pas passer à la version 7.
• Version 3 — espace de noms avec MD5 — Un hachage d'un espace de noms et d'un nom. Déterministe : les mêmes entrées donnent toujours le même identifiant. Conservée par compatibilité avec les systèmes qui l'utilisent déjà.
• Version 5 — espace de noms avec SHA-1 — La même idée que la version 3 avec un autre hachage, et celle à choisir pour tout nouvel identifiant déterministe.
• Nil — Trente-deux zéros. Une valeur spéciale définie, pas une version, et qui signifie par convention l'absence d'identifiant.
• Max — Trente-deux caractères f. L'autre valeur spéciale définie, et la plus grande qu'un UUID puisse valoir : utile comme borne supérieure d'une plage.

La version 2 est définie mais n'est pas générée ici, et c'est délibéré plutôt qu'un oubli. Elle réserve les 32 bits de poids faible de l'horodatage à un identifiant d'utilisateur ou de groupe POSIX, qu'une page web ne peut pas connaître : tous les générateurs de version 2 en ligne produisent donc quelque chose de structurellement correct et sémantiquement vide. La version 8 est réservée aux dispositions expérimentales et propres aux éditeurs, et n'a aucun sens fixe à générer.

C'est la décision avec laquelle les gens arrivent réellement, et elle a une réponse claire qui a changé ces deux dernières années.

• Utilisez la version 7 — pour toute nouvelle clé primaire. Ses valeurs croissent dans le temps, donc chaque insertion atterrit à la fin de l'index et non en un point aléatoire du milieu.
• Le problème des clés en version 4 — n'est pas l'unicité mais la localité d'écriture. Des clés aléatoires dispersent les insertions dans tout l'arbre B, si bien que les pages écrites sont réparties dans l'index et que celles dont vous avez besoin ont moins de chances d'être en mémoire. Sur une table volumineuse et sollicitée, cela se traduit par des insertions plus lentes et un index plus gros.
• N'utilisez pas la version 1 pour cela — même si elle est basée sur le temps. Son champ d'horodatage de poids faible vient en premier, les chaînes ne se trient donc pas par création et elle se comporte comme une clé aléatoire du point de vue de l'index.
• Stockez-les de façon compacte si possible — Un UUID fait 16 octets ; écrit avec des tirets il en fait 36. Les bases de données offrant une colonne UUID native ou binary(16) utiliseront le quart de la place d'un char(36) et compareront plus vite.
• Soyez cohérent sur la casse et les tirets — Deux services stockant le même identifiant sous des formes différentes ne correspondront pas lors d'une comparaison de chaînes. Choisissez une représentation à la frontière et normalisez à l'entrée.

Tous les réglages de cette page sont gratuits, et seule la taille du lot dépend du forfait. Les réglages se divisent en deux groupes au comportement différent : modifier un réglage de génération produit de nouveaux identifiants, tandis que modifier un réglage de mise en forme change seulement l'écriture de ceux déjà affichés.

Version

Choisit le type d'identifiant produit. C'est un réglage de génération : en changer remplace les valeurs affichées au lieu de les reformater. L'indication sous le sélecteur change avec votre choix et dit en une ligne à quoi sert cette version.

Combien

Saisissez un nombre ou appuyez sur un préréglage. Le champ n'acceptera pas de valeur au-dessus de la limite de votre forfait : il ne peut donc jamais demander un lot que l'outil refusera ensuite. Un réglage qui propose une valeur impossible est pire qu'un réglage qui ne la propose pas. Pour les versions 3 et 5, ce champ est remplacé par la liste de noms, car la quantité y est le nombre de noms fournis.

Casse, tirets, accolades et URN

Purement présentationnel, et appliqué sans rien régénérer. La forme compacte retire les quatre tirets et correspond à ce que beaucoup de bases de données stockent en interne. Les accolades sont la façon dont SQL Server et les anciennes API Windows écrivent un GUID. Le préfixe urn:uuid: est la forme que la RFC 9562 définit pour un usage en URI. Les quatre options se combinent.

Préfixe et suffixe

Entoure chaque ligne de votre propre texte, ce qui fait la différence entre une liste que l'on copie et une liste que l'on colle. Mettre INSERT INTO utilisateurs (id) VALUES (' en préfixe et '); en suffixe transforme un lot en SQL exécutable. Les affixes figurent dans tous les formats d'export, et le CSV les met correctement entre guillemets s'ils contiennent une virgule.

Format d'export

Le texte brut donne une valeur par ligne. La forme séparée par des virgules s'insère dans une clause IN. JSON produit un tableau prêt à l'emploi. Le CSV porte une ligne d'en-tête et, lorsque la version en possède une, une colonne de nom ou d'heure de création à côté de chaque valeur. Base64 encode la liste entière, pour les endroits qui attendent un bloc opaque.

Passez en mode Vérifier et collez n'importe quoi : une colonne issue d'un export de base de données, un fichier journal, un corps JSON, une seule valeur tirée d'un rapport de bug. Chaque jeton en forme d'UUID est repéré et décrit, dans n'importe quel mélange de formats et de casses, et un fichier peut être déposé à la place.

• Version et variante — Les deux, et ce ne sont pas la même question. La variante décide si le chiffre de version signifie quelque chose.
• Heure de création — Pour les versions 1, 6 et 7, l'horodatage intégré est converti en date lisible. C'est souvent le moyen le plus rapide de savoir quand un enregistrement a été créé si personne n'a stocké de created_at.
• Séquence d'horloge et nœud — Pour les versions 1 et 6, avec l'indication du caractère aléatoire ou réel du nœud : le bit multicast le dit, et une valeur portant une vraie adresse a été créée par quelque chose ayant accès à une carte réseau.
• Format — Avec tirets, compact, entre accolades ou préfixé urn:uuid:, indiqué valeur par valeur, pour repérer facilement une liste qui mélange les représentations.
• Doublons — Comptés sur toute la liste. C'est la seule statistique qui vaille sur une liste collée, et celle qui ne signifie rien sur une sortie fraîchement générée.

Pourquoi certaines valeurs sont non standard plutôt qu'invalides

Le premier chiffre du quatrième groupe porte les bits de variante. Seul le motif 10xx marque un identifiant RFC 9562 ; 110x est un GUID COM de Microsoft, 0xxx une valeur NCS héritée et 111x est réservé. Si la variante n'est pas celle de la RFC, le chiffre de version est une donnée ordinaire et l'annoncer comme version invente une information absente. Une valeur telle que 00000000-0000-9000-0000-000000000000 compte trente-deux chiffres hexadécimaux valides et n'a aucune version : les vérificateurs qui annoncent une version 9 lisent un chiffre et le présentent comme un fait.

Ces deux-là sont les exceptions : elles ne sont pas aléatoires et ne concernent pas le temps. Elles transforment un espace de noms et un nom en identifiant par hachage, et la même paire produit toujours le même résultat.

• Choisissez un espace de noms — La RFC 9562 en définit quatre par leur nom : DNS pour les noms d'hôte, URL pour les adresses, OID pour les identifiants d'objet et X500 pour les noms d'annuaire. N'importe quel UUID peut servir d'espace de noms, un projet peut donc définir le sien et obtenir un espace d'identifiants privé.
• Collez les noms — Un par ligne. Chacun produit un identifiant, et la quantité vient de la liste plutôt que du champ de lot.
• La reproductibilité est le but — Relancer la même liste l'an prochain sur une autre machine donne les mêmes identifiants, ce qui les rend utilisables pour rapprocher des enregistrements entre systèmes ne partageant pas de base de données.
• Ce n'est pas une fonction de sécurité — MD5 et SHA-1 sont tous deux cassés comme fonctions de hachage cryptographiques. La RFC 9562 les conserve ici parce que la sortie est un identifiant et non un authentifiant, et elle le dit elle-même. Ne considérez jamais une valeur de version 3 ou 5 comme indevinable.

Le nombre est assez grand pour que l'intuition n'aide guère, alors le voici concrètement.

• Un UUID fait 128 bits. La version 4 en fixe six pour la version et la variante, laissant 122 bits d'aléa, soit environ 5,3 × 10^36 valeurs possibles.
• Pour atteindre une chance sur un milliard d'une seule collision, il faudrait environ cent milliards d'identifiants. À un million par seconde, cela représente près de trois ans de génération continue.
• L'échec réaliste n'est jamais mathématique : c'est une source d'aléa faible. Cette page utilise le générateur cryptographique du navigateur, la même source que celle des clés de session, et jamais une simple fonction pseudo-aléatoire.
• La version 7 sacrifie un peu d'aléa au profit de l'ordre : 74 bits aléatoires par valeur au lieu de 122. Cela reste très au-delà de tout risque pratique de collision, et cet échange est précisément la raison d'être de cette version.
• Les versions 3 et 5 sont déterministes, des entrées identiques sont donc censées entrer en collision. C'est la fonctionnalité, pas un défaut.

L'essentiel des ennuis rencontrés avec les UUID vient de l'attente que l'une de ces quatre choses soit vraie.

• Ce n'est pas un secret — Les identifiants finissent dans des URL, des journaux, des rapports d'erreur et des outils d'analyse. Les versions 1, 6 et 7 annoncent en plus leur date de création. Autorisez chaque requête ; la possession d'un id ne doit jamais tenir lieu de contrôle.
• Ce n'est pas triable, sauf si vous avez choisi une version qui l'est — Les versions 4, 3 et 5 n'ont aucun ordre, et la version 1 fait seulement semblant d'en avoir un. Si vous avez besoin de l'ordre de création à partir de la clé elle-même, cela veut dire version 7 ou version 6.
• Ce n'est pas gratuit comme clé — Seize octets contre quatre pour un entier, et trente-six s'il est stocké en chaîne. Sur une table portant plusieurs index, cette différence est réelle, et c'est la raison de les stocker dans une colonne native ou binaire.
• Ce ne remplace pas une clé naturelle — Un UUID dit que deux enregistrements sont différents. Il ne dit jamais que deux enregistrements sont la même chose, ce que fait une vraie clé métier.

La taille du lot est le seul réglage de cette page lié à un forfait. Toutes les versions, toutes les options de mise en forme et tous les formats d'export fonctionnent à l'identique sur les deux forfaits.

Ce que comprend la formule gratuite

Les huit types d'identifiant, toute la mise en forme, les cinq formats d'export, le vérificateur complet avec rapport CSV, et cent identifiants par clic. De quoi couvrir des données de test, une fixture, une poignée de clés, ou savoir ce que contient un id qu'on vous a envoyé.

Ce qu'ajoute Pro

Des lots plus grands — mille, dix mille, cent mille ou un million à la fois — et jusqu'à vingt-cinq fichiers de liste simultanés du côté vérification. Un million d'identifiants est le point où la limite devient le navigateur plutôt que le forfait, et au-delà vous êtes averti plutôt que refusé.

Mesuré sous Chromium sur une machine de bureau : cent mille identifiants de version 4 sont produits en environ 20 millisecondes, cent mille valeurs collées sont analysées en moins d'un dixième de seconde, et l'export de cent mille valeurs en CSV prend environ 4 millisecondes. Seules les deux cents premières valeurs sont affichées, ce qui explique qu'un lot d'un million apparaisse instantanément.

Un générateur d'identifiants qui appelle un serveur demande une double confiance : qu'il produise de bonnes valeurs, et qu'il ne les conserve pas. Celui-ci supprime la seconde question en n'envoyant rien.

• Rien n'est envoyé — Ni les identifiants, ni les noms que vous collez pour les versions 3 et 5, ni la liste que vous déposez pour vérification. Ouvrez le panneau réseau de votre navigateur pendant l'utilisation : il n'y a rien à voir.
• Cela fonctionne hors ligne — Une fois la page chargée, la génération et la vérification continuent sans aucune connexion — utile sur un réseau verrouillé ou en avion.
• La source d'aléa est celle du navigateur — Le même générateur cryptographique que le navigateur utilise pour ses propres clés, tiré par blocs puis mis en forme, ce qui rend un grand lot rapide sans l'affaiblir.

Les versions 2 et 8 ne sont pas générées, pour les raisons exposées plus haut. Les versions 3 et 5 reposent sur MD5 et SHA-1, cryptographiquement cassés et utilisés ici uniquement pour leur déterminisme. Le vérificateur lit n'importe quels 32 chiffres hexadécimaux dans n'importe quelle enveloppe courante, mais il ne peut pas dire si un identifiant a réellement été émis par votre système : seulement ce qu'il contient. Tout ce que propose cette page fonctionne dans les versions actuelles de Chrome, Edge, Firefox et Safari, sur ordinateur comme sur mobile.

• Générateur de hachage
• Encodeur/décodeur Base64
• Encodeur/décodeur d'URL
• Générateur de QR code
• Générateur de code-barres
• Formateur JSON
• Convertisseur de couleurs
• Générateur de palettes
• Convertisseur date et heure
• Validateur JSON
• CSV vers JSON
• Supprimer les lignes en double
• Supprimer les lignes en double (texte)
• Diviser un texte
• Trier un texte
• Convertisseur de casse
• Tous les convertisseurs