ToolActToolAct

Générateur UUID

Générer des identifiants uniques conformes RFC 4122

Résultats0 total

Cliquez "Générer UUID" pour commencer

Qu'est-ce qu'un UUID ?

Un UUID, pour Universally Unique Identifier, est un identifiant de 128 bits utilisé pour marquer des enregistrements, objets, sessions, fichiers, appareils, messages et autres entités dans des systèmes distribués. Sa forme textuelle courante utilise des groupes hexadécimaux selon le modèle 8-4-4-4-12. Les UUID sont utiles lorsque plusieurs serveurs, clients ou services doivent créer des identifiants sans demander un numéro séquentiel à une base centrale. Selon la version, ils reposent sur l’aléatoire, le temps ou des hash liés à un nom, ce qui influence confidentialité, tri, prédictibilité et risque de collision. L’outil sert à générer et examiner ces identifiants rapidement, pas à gérer l’autorisation.

Comment utiliser

Étapes de génération

  1. Sélectionnez la version UUID (v1, v4 ou Nil)
  2. Définissez le nombre de générations (1-100)
  3. Choisissez la casse de sortie (majuscule ou minuscule)
  4. Sélectionnez le format (avec tirets, sans tirets, ou accolades)
  5. Cliquez sur le bouton Generate pour créer les identifiants demandés

Raccourcis clavier

  • Ctrl + GGénérer un UUID
  • Ctrl + Shift + CTout copier

Notes sur les identifiants

  • UUID v4 est généralement le bon choix pour les identifiants aléatoires côté client ; il n'encode ni le temps ni les informations de l'appareil.
  • N'utilisez pas les UUID comme secrets. Ils identifient des enregistrements mais ne remplacent pas les jetons d'authentification ni les clés d'accès.

Cas d’utilisation

Générer des lots d’UUID pour des données de développementCréez 1, 5, 10, 20, 50 ou 100 UUID en une fois, puis copiez les valeurs individuellement, copiez tout ou téléchargez-les en fichier texte. UUID v4 utilise crypto.getRandomValues lorsque disponible, et la graine aléatoire est générée localement dans le navigateur — aucun service distant n’est consulté, ce qui garde les fixtures de test reproductibles sur des réseaux isolés.
Choisir la version et le format de sortieGénérez des UUID v4 aléatoires, des UUID v1 simulés de style horodatage, ou l’UUID nil, puis formatez-les avec tirets, sans tirets ou entre accolades et choisissez la casse. Chaque identifiant étant produit à partir d’une graine locale ou d’un horodatage avec un nœud incorporé, les ID résultants peuvent être partagés dans des fixtures sans exposer de token spécifique à l’environnement.
Travailler rapidement avec les raccourcis clavierLa page génère un UUID initial au chargement et supporte Ctrl+G pour régénérer et Ctrl+Shift+C pour tout copier. Pratique pour les ID dans les fixtures, les seeds de base de données, le traçage de requêtes et les exemples d’API. Chaque génération tire une nouvelle graine aléatoire locale, les ID n’entrent pas en collision entre les exécutions même sur une machine hors ligne depuis des heures.
Générer des identifiants triables de style v1Choisissez UUID v1 pour des ID qui doivent se trier chronologiquement dans un index de base de données. Notez qu’ils divulguent l’horodatage et l’adresse MAC, ne les exposez pas publiquement quand la date de création est sensible. La page utilise un horodatage navigateur pour les champs temporels, ce qui garde l’ordre correct en test mais ne doit pas être utilisé pour une corrélation d’horloge précise entre machines.
Valider un UUID existant avant insertionCollez une valeur candidate dans le champ de saisie ; la page réaffiche la version analysée et les bits de variante pour repérer des tirets malformés, une longueur incorrecte ou une casse non canonique avant l’écriture en base de données. La validation ne lit que la chaîne saisie, rien n’est journalisé ni envoyé, les identifiants fournis par l’utilisateur peuvent être vérifiés sans les divulguer.

Principe technique

L'UUID est un identifiant de 128 bits sous la forme standard 8-4-4-4-12, soit 36 caractères au total (incluant 4 tirets). Les 128 bits sont répartis en : time-low (32 bits), time-mid (16 bits), version-and-time-high (16 bits, les 4 bits supérieurs indiquent la version), variant-and-clock-seq (16 bits, les 2 à 3 bits supérieurs indiquent la variante) et node (48 bits). La RFC 4122 définit cinq versions, v1 à v5. La v1 est construite à partir d'un horodatage 60 bits (résolution de 100 nanosecondes, compté depuis le 15 octobre 1582) plus une adresse MAC 48 bits plus une séquence d'horloge 14 bits. Elle est théoriquement triable par ordre de génération, mais elle divulgue l'identité de la machine et l'heure de génération. La v4 est la version la plus utilisée : 122 bits remplis par une source aléatoire cryptographiquement sécurisée, avec des bits fixes de version (4) et de variante (10). La probabilité de collision est une préoccupation centrale dans la conception des UUID. La v4 dispose d'un espace aléatoire de 122 bits, et par le paradoxe des anniversaires, il faut un milliard d'UUID par seconde pendant 85 ans consécutifs pour atteindre 50 % de chances d'une seule collision, ce qui est largement suffisant en pratique. La v7 émergente place l'horodatage en premier et les bits aléatoires en dernier, équilibrant unicité et ordre temporel, et est mieux adaptée aux clés primaires de bases de données.

  • UUID v4 : 122 bits aléatoires avec bit de version fixe 4 et bit de variante 10 ; convient à presque tous les scénarios et ne divulgue aucune information personnelle.
  • UUID v1 : horodatage 60 bits + MAC 48 bits + séquence d'horloge 14 bits ; triable par temps mais expose l'empreinte de la machine, à utiliser avec précaution.
  • UUID v7 : horodatage en premier, bits aléatoires en dernier ; un standard en projet de 2024 conçu spécifiquement pour les clés primaires de bases de données.
  • Probabilité de collision : l'espace aléatoire de v4 est de 2^122, et il faut un milliard d'UUID par seconde pendant 85 ans consécutifs pour avoir 50 % de chances d'une seule collision.
  • UUID Nil : tous zéros 00000000-0000-0000-0000-000000000000, couramment utilisé comme espace réservé ou valeur par défaut.
  • Variantes de format : au-delà du format standard 8-4-4-4-12, il existe la forme à 32 caractères sans tirets, la forme {accolades} et la forme URN (urn:uuid:...).

Exemples

Format standard UUID v4 (aléatoire)

550e8400-e29b-41d4-a716-446655440000

Chiffre de version (13e caractère hex) : 4 -> v4, aléatoire
Bits de variant (17e caractère hex) : 8/9/a/b -> variant RFC 4122
Usage : clés primaires en base de données, identifiants de requête, identifiants d'asset - le choix par défaut quand l'ordre n'a pas d'importance
RFC: RFC 4122 section 4.4 définit la génération v4

Format UUID v1 (timestamp + MAC)

c232ab00-9414-11ec-b909-0242ac120002

Chiffre de version : 1 -> v1, basé sur le temps
Note : encode le timestamp de génération dans time_low ; les 12 derniers caractères hex sont le node id (souvent une MAC)
Usage : quand on a besoin d'IDs triables ou d'une source déterministe par hôte, mais attention : la MAC révèle l'identité de l'hôte
RFC: RFC 4122 section 4.1 définit la disposition v1

Génération en lot de 5 IDs v4

a1b2c3d4-e5f6-4789-a012-3456789abcde
f7e8d9c0-b1a2-43f4-95e6-7d8c9b0a1e2f
3c4d5e6f-7a8b-49c0-9d1e-2f3a4b5c6d7e
8e9f0a1b-2c3d-44e5-bf6a-7b8c9d0e1f2a
5f6a7b8c-9d0e-45f1-a2b3-c4d5e6f7a8b9

Note : chaque ID est tiré indépendamment via crypto.getRandomValues ; la probabilité de collision pour 2^122 IDs est négligeable selon l'annexe B de la RFC 4122

FAQ

Qu'est-ce qu'un UUID ?

Un Universally Unique Identifier est une valeur 128 bits (RFC 4122/9562) habituellement écrite en 32 chiffres hexadécimaux selon le motif 8-4-4-4-12, par ex. 550e8400-e29b-41d4-a716-446655440000. Différentes versions encodent du temps, des données aléatoires ou des hachages ; leur but est d'être uniques entre systèmes sans coordinateur central.

Quelle est la différence entre UUID v1, v4 et v7 ?

v1 mélange l'adresse MAC de l'hôte et un timestamp à 100 ns (bon ordonnancement, fuite d'info hôte). v4 est purement aléatoire (122 bits d'entropie, sans ordonnancement). v7 (RFC 9562) place un timestamp Unix-ms 48 bits dans les bits hauts avec des bits bas aléatoires — triable comme v1 mais sans fuite de MAC. v7 est le défaut moderne pour les clés de base de données.

Un UUID est-il réellement unique ?

Statistiquement, oui. Générer un milliard d'UUID v4 par seconde pendant 100 ans donne encore une probabilité de collision d'environ 50 % (la borne du paradoxe des anniversaires). Pour tout système pratique, vous pouvez traiter les UUID comme uniques sans coordination.

Les UUID sont-ils aléatoires et imprédictibles ?

Les UUID v4 sont aléatoires et effectivement imprédictibles (122 bits d'entropie). Les UUID v1 ne sont pas du tout aléatoires — ils exposent l'adresse MAC de l'hôte et l'horodatage, donc n'utilisez pas v1 comme jeton de sécurité. Le préfixe d'horodatage de v7 est aussi prévisible ; seuls les bits aléatoires de fin sont imprédictibles.

Dois-je utiliser un UUID comme clé primaire de base de données ?

C'est faisable mais avec des compromis. Les UUID v4 aléatoires causent une fragmentation des B-tree dans les bases qui clusterisent sur la clé primaire (MySQL InnoDB), nuisant aux performances d'insertion à grande échelle. Les UUID v7 triables évitent cela. Les entiers auto-incrémentés restent plus petits et plus rapides — utilisez les UUID quand la génération distribuée importe.

La génération d'UUID se fait-elle dans mon navigateur ?

Oui. La page utilise crypto.randomUUID (ou crypto.getRandomValues pour les anciens navigateurs), qui fait partie de l'API Web Crypto. Rien n'est envoyé à un serveur, et rafraîchir la page donne un nouveau flux d'entropie.

Pourquoi certains UUID se ressemblent-ils presque au début ?

Les UUID v1 et v7 encodent le temps dans leurs caractères de tête, donc les UUID générés dans la même milliseconde partagent un préfixe et ne diffèrent que dans les octets de fin. Cette propriété est ce qui les rend naturellement triables. Les UUID v4 sont aléatoires et n'exhibent pas ce comportement.