Outils de développement · Générateur UUID
RFC 4122 vs RFC 9562 : ce qui a changé dans la norme 2024 UUID
· Contexte
uuid cryptographie API du navigateur
Deux RFC sont citées pour les UUID et elles ne disent pas tout à fait la même chose. Cet article passe en revue ce que la RFC 9562 a ajouté, clarifié et obsolète par rapport à la RFC 4122.
Quelle RFC dois-je citer ? — la confusion lorsque la documentation et les bibliothèques font référence à des normes différentes
Deux RFC sont régulièrement citées dans la documentation UUID, et elles ne disent pas des choses identiques. La RFC 4122, publiée dans 2005, définit les UUID et leurs cinq versions (v1 à v5). La RFC 9562, publiée dans 2024, rend entièrement obsolète la RFC 4122, clarifie les ambiguïtés sur lesquelles les praticiens ont travaillé, ajoute trois nouvelles versions (v6, v7, v8) et met à jour les conseils sur la mise en œuvre du caractère aléatoire. Lorsqu'une bibliothèque cite la RFC 4122, ce n'est pas faux : cette bibliothèque peut avoir été publiée avant la publication de la RFC 9562 ou les responsables peuvent ne pas avoir mis à jour la documentation. La vérification des citations RFC vous indique quand une bibliothèque a été mise à jour de manière significative pour la dernière fois. Lors de la rédaction de nouvelles spécifications ou de l'évaluation d'implémentations, la RFC 9562 est la référence normative.
Obsolète, ne remplaçant pas le format — tout ce qui est valide sous RFC 4122 reste valide ; la disposition et les bits de variante sont inchangés
RFC 9562 rend formellement obsolète la RFC 4122 en tant que document de référence actuel tout en conservant la représentation familière 128 bits, les groupes hexadécimaux, la position de la version et la disposition des variantes principales. Les chaînes UUID stockées existantes n'ont pas besoin d'être rééditées simplement parce qu'une RFC plus récente existe. La migration pratique concerne la documentation, les générateurs et la politique de validation : citer la norme actuelle, comprendre les versions ajoutées et vérifier si l'ancien code reposait sur une ambiguïté clarifiée par la révision. La compatibilité doit toujours être testée aux limites du système, en particulier lorsqu'une bibliothèque sérialise les structures Microsoft GUID ou applique un ensemble de versions plus restreint que celui décrit par la norme.
Trois nouvelles versions : v6 (heure de réorganisation), v7 (ordonnancement de l'époque Unix) et v8 (définie par l'implémentation)
RFC 9562 ajoute trois nouvelles versions à la norme. La version 6 réorganise les bits d'horodatage v1 pour produire des identifiants triables lexicographiquement pour de meilleures performances de base de données. La version 7 utilise un horodatage Unix milliseconde 48 bits suivi de bits aléatoires, permettant une génération ordonnée dans le temps sans les problèmes de confidentialité de la v1. La version 8 est une trappe de secours pour les mises en page définies par l'implémentation. Aucune de ces versions ne modifie le fonctionnement des v1-v5 ou leur signification. Un UUID v1 de 2005 et un UUID v7 de 2024 peuvent coexister dans la même base de données, chacun avec ses bits de version identifiant sa méthode de génération. Les trois nouvelles versions abordent des modèles courants apparus dans la pratique.
Max UUID rejoint Nil - la valeur tout-F définie à côté de celle tout-zéro
RFC 4122 a documenté Nil UUID (tous les bits zéro) comme valeur de référence spéciale dans les exemples et la documentation. La RFC 9562 inclut la même définition Nil mais définit formellement le Max UUID (tous les bits mis à un) pour les limites de plage. Ni Nil ni Max ne sont une version 4 aléatoire UUID car ils n'ont pas de version et de bits de variante corrects. Le Max UUID est utile comme limite supérieure de plage dans les requêtes de base de données : WHERE uuid_column <= MAX_UUID correspond à tous les UUID possibles. Nil est utile comme sentinelle pour les colonnes non attribuées dans les colonnes UUID nullables. La RFC 9562 documente les deux sans imposer leur utilisation dans les données d'application.
Conseils clarifiés — conseils explicites sur l'utilisation d'un CSPRNG pour les champs aléatoires, sur les compteurs monotones en une milliseconde et sur la préférence pour les versions ordonnées dans le temps pour la localité de la base de données Les lignes directrices sur les meilleures pratiques de
RFC 9562 font la distinction entre la résistance aux collisions et l'imprévisibilité. Les champs aléatoires doivent utiliser une source appropriée au modèle de menace de l'application, et l'opacité sensible à la sécurité nécessite un CSPRNG. Les générateurs basés sur le temps ont un problème de monotonie distinct lorsque plusieurs identifiants partagent un même tick d'horodatage ; la norme décrit les compteurs et une précision d'horodatage supplémentaire comme méthodes possibles, chacune avec des règles d'état et de basculement. Les versions basées sur le nom restent des identifiants déterministes et non des preuves d'authenticité. Ces clarifications sont importantes car un seul analyseur UUID peut accepter toutes les mises en page même si leurs exigences de génération et leurs propriétés de divulgation d'informations diffèrent.
Où les idées de l'ULID apparaissent : comment le format de la communauté a influencé la conception de la v7
RFC 9562 indique que ses auteurs ont analysé plusieurs schémas d'identification triables existants, notamment ULID, Snowflake et KSUID, tout en développant les nouvelles mises en page. Cela conforte une conclusion modeste : la demande opérationnelle d’identifiants distribués et ordonnés dans le temps a éclairé la révision. Cela ne prouve pas qu'un format communautaire ait fait don d'une disposition exacte des champs à la version 7. La similitude pratique est suffisante pour le travail d'architecture : ces familles placent les informations temporelles près du premier plan afin que l'ordre ordinaire puisse préserver un ordre de création large, puis diffèrent par l'encodage, la coordination et le comportement à l'intérieur des ticks. Choisissez entre eux en fonction de la compatibilité de l'écosystème et des garanties documentées plutôt que d'une revendication d'ascendance directe.
Ce que ceci ne couvre pas : une différence ligne par ligne ; cet article suit les conséquences pratiques pour les implémenteurs
Cet article complet suit les conséquences pratiques et la mise en œuvre de la RFC 9562 pour les implémenteurs et les utilisateurs, et non les différences ligne par ligne par rapport à la RFC 4122. Les spécifications complètes sont disponibles auprès des organismes de normalisation et valent la peine d'être lues pour implémenter la gestion UUID dans des langages ou des plates-formes : le texte fournit des détails faisant autorité au-delà de ce qu'un aperçu peut couvrir. Cet article ne décrit pas les mécanismes au niveau des bits sur la façon dont la v6 réorganise les octets de la v1 ou sur la façon dont la v7 encode les millisecondes Unix. Les normes et les guides de mise en œuvre restent la principale référence faisant autorité pour toute question de mise en œuvre concernant la disposition des bits, le codage ou la vérification de la conformité.
À retenir : mettez à jour vos citations et vos valeurs par défaut – le générateur ToolAcre suit les directives CSPRNG que partagent les deux RFC
Pour tout nouveau travail, mettez à jour la documentation et les spécifications pour citer la RFC 9562. Chaque UUID de la RFC 4122 reste valide sous la RFC 9562 : la migration est de nature purement prospective et administrative. Les orientations clarifiées sur le caractère aléatoire cryptographique renforcent le fait que les identifiants doivent provenir de sources cryptographiquement sécurisées dans les systèmes de production. ToolAcre suit les directives cryptographiques aléatoires des deux RFC, en utilisant exclusivement l'API Web Crypto du navigateur. Lorsque vous rencontrez un UUID provenant de journaux, d'exportations de bases de données ou de réponses d'API, la vérification bien formée de ToolAcre rapporte sa version et sa variante par rapport à la RFC 9562. La RFC 9562 est une clarification et une modernisation d'une norme déjà stable.