Outils de développement · Générateur UUID
Lecture manuelle d'un UUID : où se trouvent les bits de version et de variante
· Comment ça marche
uuid cryptographie API du navigateur
Deux caractères hexadécimaux dans chaque UUID vous indiquent quelle version l'a produit et quelle variante de mise en page elle suit. Apprenez à les lire d’un coup d’œil et à savoir ce qu’ils ne peuvent pas vous dire.
Quel système a créé cet identifiant ? — la question de journalisation à laquelle le version nibble peut répondre
Une chaîne UUID contient 36 caractères : trente-deux chiffres hexadécimaux et quatre tirets aux positions 8-4-4-4-12. Deux caractères dans chaque UUID (apparaissant aux positions 14 et 19) codent les métadonnées : le champ de version vous indique quel algorithme a généré l'ID et le champ de variante vous indique la présentation standard qu'il suit. La lecture de ces deux caractères sans outils est la compétence d'investigation des journaux : vous repérez un UUID dans un vidage de base de données ou un message d'erreur et savez immédiatement s'il s'agit d'un horodatage v1 (qui fuit l'heure de création), d'une valeur aléatoire v4 (qui a été générée à partir d'un CSPRNG) ou autre chose. Le numéro de version occupe les bits 48–51 du UUID, qui correspond au premier caractère hexadécimal du troisième groupe.
La disposition 128 bits en cinq groupes - comment 8-4-4-4-12 est mappé sur les octets et pourquoi les groupes sont historiques et non fonctionnels
Pour la chaîne xxxxxxxx-xxxx-4xxx-xxxx-xxxxxxxxxxxx, le caractère en position 14 est la version. La RFC 9562 définit les versions 1 à 8 : la v1 est basée sur le temps grégorien et perd le temps de création ; la v4 est aléatoire ; La v7 est basée sur le temps Unix et triable. Les versions 0, 9 et supérieures sont réservées ou inutilisées. Si vous voyez un UUID v1, vous savez que l'heure et l'adresse matérielle ont été mélangées ; si vous voyez v4, l'ID est constitué d'octets aléatoires avec des bits de version définis ; si vous voyez la v7, il trie par heure de création. La version n'est pas facultative ; chaque UUID correctement formé en a un. Le champ variante occupe les bits 64–65 du UUID, les deux bits les plus significatifs de l'octet 8.
Le quartet de version - le premier caractère du troisième groupe, ce que signifient 1 à 8 et ce qu'indique un 0 ou 9
Dans la représentation textuelle xxxxxxxx-xxxx-xxxx-Nxxx-xxxxxxxxxxxx, le premier caractère du quatrième groupe (position 19) code la variante. Pour la variante RFC 9562 (la norme en usage moderne), ce caractère doit être 8, 9, a ou b – les représentations hexadécimales de 1000, 1001, 1010 et 1011 en binaire. Tout autre caractère (0–7, c–f) indique une variante différente : 0–7 sont rétrocompatibles NCS ; c–d sont les GUID hérités de Microsoft avec un ordre d'octets little-endian ; e–f sont réservés. Lorsque vous lisez la position 19 et voyez 8, 9, a ou b, vous consultez une RFC 9562 UUID. Toute autre valeur signifie que les octets suivent une interprétation différente. La disposition 128 bits se divise en octets 0–15, mais le format de texte les sépare par groupes pour des raisons de lisibilité et non de fonction.
Le champ de variante - pourquoi le premier caractère du quatrième groupe est 8, 9, a ou b pour les UUID RFC, et quel signal c/d (héritage Microsoft) ou 0–7 (NCS)
Les cinq groupes représentent les limites historiques des champs : les trois premiers champs contiennent l'horodatage et la version dans les UUID v1, le quatrième champ contient la séquence d'horloge et la variante, le cinquième champ contient l'identifiant du nœud. La version 4 et les versions ultérieures UUID n'utilisent pas ces noms de champ, mais les mêmes positions de bits portent toujours la version et la variante. Lire un UUID v4 signifie accepter que la plupart des 128 bits sont des charges utiles aléatoires, mais deux d'entre eux, aux positions 14 et 19 dans le texte, sont corrigés par la norme. Ces bits fixes prouvent que l'ID est une variante v4 et RFC. Le nul UUID est 00000000-0000-0000-0000-000000000000, tous des zéros et ne comporte aucune version du tout. Le UUID maximum est ffffffff-ffff-ffff-ffff-ffffffffffff, tous les caractères f, et est également réservé et sans version.
Exemple pratique : décodage de trois échantillons d'identifiants caractère par caractère, dont un v4 et un v7
Tout autre UUID bien formé a une version dans le troisième groupe et une variante dans le quatrième. Testez-vous avec trois exemples d'ID : 123e4567-e89b-12d3-a456-426614174000 (v1, variante RFC car la position 19 est a) ; 9b2e4f1a-4f3e-4c1a-8a7d-1b2c3d4e5f60 (v4, variante RFC car la position 19 est 8) ; 018f0c2e-1b5a-7c3d-9e4f-5a6b7c8d9e0f (v7, variante RFC car la position 19 est 9). L'inspecteur ToolAcre confirme votre lecture. Une vérification de format ne peut pas vous indiquer qu'un identifiant est unique, qu'il existe dans votre base de données ou qu'il a été généré de manière sécurisée. La version v1 utilise l'heure et le matériel comme entrées, donc des UUID v1 identiques provenant de différentes machines entraînent des problèmes de décalage d'horloge ou de synchronisation. La version v4 est aléatoire, donc une v4 en double UUID signifie soit un caractère aléatoire brisé, soit une collision astronomiquement improbable (environ une par 2. 7 billions d'UUID avec un caractère aléatoire sonore).
Nil et Max — les deux valeurs entièrement nulles et entièrement F qui ne comportent aucune version du tout
Une version 0 ou 9 signifie que la chaîne n'est pas du tout un UUID valide. La lecture de la version et de la variante est la première étape pour comprendre ce qu'est un identifiant ; vérifier s'il existe ou s'il est unique constitue les deuxième et troisième étapes, effectuées par votre base de données et votre logique métier. Comprendre les positions des bits aide à déboguer les migrations de données. Lors de l'importation d'UUID à partir de systèmes existants, certains outils exportent des champs de variantes qui ne correspondent pas à la norme RFC 9562. Un champ de variante de c ou d indique un GUID Microsoft dans l’ordre des octets petit-boutiste. Ces GUID sont des identifiants valides dans les systèmes Microsoft, mais n'interagissent pas avec les UUID RFC 9562 sans conversion de l'ordre des octets. La position de lecture 19 vous indique immédiatement quel système a généré l'ID. Si vous voyez 8, 9, a ou b, vous disposez d'une norme RFC UUID.
Ce qu'une vérification de format ne peut pas vous dire : que l'ID existe dans votre base de données, qu'il a été généré de manière sécurisée ou qu'il est unique
Si vous voyez c ou d, vous disposez d'un GUID Microsoft. Si vous voyez un autre caractère, l'identifiant est mal formé ou provient d'un système obscur. Le générateur ToolAcre produit toujours des UUID RFC 9562 avec la position 19 comme l'une des 8, 9, a ou b. Le champ de version à trois bits code sept valeurs possibles (1–7 ; les versions 0 et 8 ont des significations particulières). La version 1 est un horodatage grégorien, la version 3 est un espace de noms basé sur MD5, la version 4 est aléatoire, la version 5 est un espace de noms basé sur SHA-1, la version 6 est basée sur un horodatage Unix (proposé), la version 7 est triable basé sur l'horodatage Unix (normalisé dans la RFC 9562), la version 8 est réservée aux formats personnalisés. La lecture du caractère position-14 vous indique immédiatement quel algorithme a été utilisé. Si vous déboguez des collisions UUID ou des tris inattendus, le numéro de version est votre premier indice. ToolAcre génère des UUID v4 exclusivement à partir de crypto.
À retenir : deux caractères, beaucoup de contexte - utilisez la vérification bien formée de ToolAcre pour confirmer une analyse de chaîne, puis lisez vous-même la version
getRandomValues ; chaque UUID qu'il produit a un 4 à la position 14. L'analyse manuelle de la structure UUID est une compétence utile pour déboguer des systèmes complexes où les outils ne sont pas disponibles. Lors d'un incident de production, vous devrez peut-être lire les UUID à partir d'un vidage de base de données, d'un journal d'erreurs ou d'un cache sans exécuter d'outil spécial. Vous recherchez la position 14 pour identifier la version (est-ce qu'elle fuit dans le temps ? est-elle aléatoire ? est-elle triable ? ). Vous recherchez la position 19 pour identifier la variante (est-ce la norme RFC ? est-ce un GUID Microsoft ? est-il réservé ? ). Ces deux personnages, sur 36 au total, portent les métadonnées. Les 34 caractères restants sont des données utiles : horodatage ou octets aléatoires ou autres données spécifiques à l'algorithme. Savoir ce que représente la charge utile vous aide à comprendre le rôle de l'ID dans votre système.