Outils de développement · Générateur UUID
UUID Versions 1 à 8 expliquées : laquelle devez-vous générer ?
· Contexte
uuid cryptographie API du navigateur
Huit versions partagent un format mais résolvent différents problèmes : ordre temporel, reproductibilité, caractère aléatoire ou mises en page personnalisées. Cet article explique chacun et donne un chemin de décision.
Un format, huit recettes : pourquoi la version est importante lorsque vous choisissez une fonction de bibliothèque
La norme UUID définit un format 128-bit comme trente-six caractères hexadécimaux avec des traits d'union. La RFC 9562 définit huit recettes distinctes (versions un à huit) pour remplir ces bits avec des modèles et des significations différents. Le quartet de version (premier caractère du troisième groupe) identifie la méthode qui a produit la valeur, servant d'étiquette. Choisir la mauvaise version signifie stocker des informations temporelles inutiles, manquer de garanties de commande pour les performances de la base de données ou mal comprendre les rôles de sécurité des identifiants. Cet article présente chaque version, le problème concret qu'elle résout, le moment où les développeurs le rencontrent dans la pratique, et fournit un cadre de décision pour sélectionner la version adaptée à vos exigences système spécifiques.
v1 et v6 : heure plus nœud – la disposition originale basée sur le temps et la version réorganisée qui trie correctement
La version 1 combine un horodatage 60 bits avec un identifiant de nœud (à l'origine une adresse MAC, bien que les implémentations modernes utilisent des valeurs aléatoires pour éviter les fuites d'informations sur le matériel). L'horodatage enregistre des intervalles de 100 nanosecondes depuis octobre 15, 1582. Le champ de nœud peut révéler quand l'identifiant a été généré et son origine géographique, c'est pourquoi les implémentations modernes évitent les adresses MAC. La version 6 réorganise les mêmes informations d'horodatage et de nœud pour améliorer la capacité de tri en déplaçant les bits de temps d'ordre élevé vers l'avant, ce qui permet aux UUID v6 de trier correctement dans l'ordre lexicographique. Si votre application a besoin d'UUID qui trient naturellement par heure de création avec une localité d'index supérieure, la v6 est le choix moderne.
v2 : DCE Security — la variante rarement utilisée qui intègre les identifiants POSIX
La version 2 est rarement utilisée dans les nouveaux systèmes. Il intègre les identifiants d'utilisateur ou de groupe POSIX dans la disposition UUID, ce qui le rend utile uniquement dans les environnements existants où ces identifiants ont une signification organisationnelle. La conception v2 suppose un modèle informatique spécifique (DCE Security) qui est rare dans les systèmes distribués modernes. La plupart des organisations associent les UUID aux utilisateurs ou aux groupes dans leur couche d'application via des jointures de bases de données ou des tables de recherche, et non en codant l'ID utilisateur dans l'identifiant lui-même. Cette séparation des préoccupations facilite la modification des modèles d'autorisation, la migration des données utilisateur et la maintenance des pistes d'audit. Le codage des informations d’identification directement dans les UUID crée un couplage étroit et rend les systèmes plus difficiles à faire évoluer.
v3 et v5 : basés sur le nom – ID déterministes hachés à partir d'un espace de noms et d'un nom avec MD5 ou SHA-1
3 et 5 sont déterministes : le même espace de noms et le même nom produisent toujours le même identifiant, idéal pour représenter des mappages stables à partir de données externes. La version 3 utilise MD5 et la version 5 utilise SHA-1 comme algorithmes de hachage, reflétant leurs âges et adoption respectifs. Lorsqu'un enregistrement client arrive pour importation, un UUID v5 dérivé d'un espace de noms fixe sera identique lors de plusieurs exécutions d'importation, évitant ainsi les enregistrements en double. Ce déterminisme signifie que UUID est reproductible et prévisible pour toute personne connaissant l'espace de noms et l'entrée. La valeur pratique brille dans les scénarios d'intégration de données : rapprochement des enregistrements clients de plusieurs systèmes, prévention des doublons dans les importations récurrentes et attribution d'identifiants stables aux articles.
v4 : aléatoire — 122 bits d'un CSPRNG et le choix par défaut lors de la commande n'a pas d'importance
La version 4 est le choix par défaut lorsque la commande n'est pas requise et que vous souhaitez une génération indépendante sans coordination centrale. Un UUID v4 est composé de 122 bits provenant d'une source aléatoire cryptographiquement sécurisée, avec six bits définis sur des valeurs fixes (nibble de version 4 et bits variantes RFC 9562 10). Le caractère aléatoire est tout l’enjeu : chaque appel produit une valeur différente, les collisions restent extrêmement improbables et aucun état ou coordination externe n’est requis. Il s'agit de la version que ToolAcre génère à l'aide de crypto.randomUUID() ou crypto.getRandomValues(). Cette version convient aux références d'objets, aux données non structurées et à la plupart des rôles en dehors des clés primaires ou des contextes de tri.
v7 et v8 : Unix time et custom — la version moderne ordonnée dans le temps pour les clés de base de données et la trappe de secours pour les mises en page sur mesure
La version 7, normalisée dans la RFC 9562, introduit les propriétés modernes ordonnées dans le temps au format UUID. Il utilise un horodatage Unix milliseconde 48 bits, 12 bits d'une précision inférieure à la milliseconde et 62 bits aléatoires combinés. L'horodatage Unix en millisecondes est valable jusqu'à l'année 10889, ce qui le rend adapté aux systèmes. Le résultat est trié correctement dans l'ordre lexicographique et tient dans une colonne 128-bit UUID standard sans traitement spécial ni conversion de codage. Si votre application a besoin d'identifiants triés par heure de création au format standard UUID, la version 7 est la meilleure pratique actuelle. La version 8 est un fourre-tout standardisé pour les formats définis par l'implémentation, utile uniquement si vous avez besoin de dispositions de bits spécifiques non couvertes par v1-v7.
Exemple concret : un chemin de décision appliqué à trois scénarios : une référence d'API publique, une clé primaire et un ID stable pour les enregistrements importés
Trois scénarios réels illustrent la sélection de version : Premièrement, une référence d'API publique doit être stable entre les instances d'API, ne doit pas perdre de temps de création et doit être la même lors des redémarrages du serveur afin que différentes instances génèrent la même référence pour le même document. Utilisez la version v5 avec un espace de noms et un nom de document stables. Deuxièmement, une clé primaire pour une table en croissance continue doit être unique, ne doit pas provoquer de fragmentation de l'index et doit pouvoir être générée par n'importe quelle instance d'application sans coordination centrale. Utilisez la version v7 pour les identifiants triables avec la prise en charge standard de l'écosystème UUID. Troisièmement, les enregistrements archivés nécessitant une recherche stable nécessitent des identifiants immuables.
À retenir : choisissez par propriété, pas par habitude – le générateur ToolAcre produit des UUID aléatoires à partir du CSPRNG du navigateur pour les cas qui nécessitent la v4.
La sélection de la version découle de la conception de votre schéma et de la configuration système requise, et non d'une convention ou d'une familiarité. Les UUID aléatoires (v4) sont la valeur par défaut car ils ne nécessitent aucun état ni coordination et produisent des identifiants indépendants adaptés à la plupart des rôles. Les versions ordonnées dans le temps (v6, v7) résolvent les problèmes de localité d'index au prix de fuites d'informations temporelles ou d'exigences de synchronisation d'horloge. Les versions déterministes (v3, v5) empêchent les importations en double et permettent des mappages externes stables au détriment de la prévisibilité : toute personne connaissant votre espace de noms peut les recalculer. ToolAcre génère des UUID v4 aléatoires à partir du générateur cryptographiquement sécurisé du navigateur. Lorsque vous avez besoin d'une version différente, la vérification bien formée confirme que les identifiants analysés sont valides.