Outils de développement · Générateur UUID
GUID vs UUID : explication des accolades, de l'ordre des octets et des variantes de Microsoft
· Contexte
uuid cryptographie API du navigateur
GUID est le nom donné par Microsoft pour un UUID, mais les accolades, les majuscules et l'ordre des octets peuvent donner au même identifiant un aspect différent selon les plates-formes. Cet article explique chaque différence et comment comparer en toute sécurité.
Le même ID qui ne correspond pas à tous les systèmes : un service .NET et un service Java en désaccord sur un enregistrement
Un service .NET génère un GUID et l'envoie à un service Java, qui tente de faire correspondre la valeur à un UUID de PostgreSQL. La comparaison de chaînes échoue et les systèmes signalent que les identifiants ne correspondent pas, même si les trois services fonctionnent avec les mêmes octets 16 sous-jacents. Les différences sont apparemment cosmétiques (accolades, casse, ordre des octets), mais elles provoquent l'échec des comparaisons de chaînes et confondent les points d'intégration qui ne se normalisent pas à la limite. GUID est la terminologie Microsoft pour ce que la RFC 9562 appelle un UUID : un identifiant 128 bits avec la même disposition de bits. Les deux noms font référence à la même structure fondamentale, mais la représentation diffère d’une manière qui surprend les développeurs. Comprendre d'où vient la confusion évite les bugs d'intégration.
GUID est un UUID — le format 128-bit partagé et d'où vient la différence de nom.
GUID signifie Globally Unique Identifier et Globally Unique Identifier et est le nom que Microsoft utilise pour ce que les normes RFC appellent un UUID. La disposition 128 bits et la version/variant du système sont identiques. Les RFC 4122 et RFC 9562 spécifient le format et la signification de UUID ; Microsoft les implémente et utilise le terme GUID. La différence de dénomination est historique : Microsoft utilisait le GUID avant que les UUID ne soient standardisés par l'IETF, et la terminologie Microsoft est restée dans l'écosystème .NET. Au niveau des bits, un GUID et un UUID sont complètement interchangeables. Au niveau du formatage, leur présentation diffère : le code .NET écrit souvent les GUID avec des accolades et des lettres majuscules, tandis que les UUID canoniques RFC utilisent des minuscules et sans accolades.
Accolades et majuscules : le formulaire {XXXXXXXX-...} de style registre et comment le normaliser
Un UUID sous forme canonique RFC s'écrit sous la forme de huit, quatre, quatre, quatre et douze caractères hexadécimaux minuscules séparés par des tirets : 550e8400-e29b-41d4-a716-446655440000. Un GUID .NET est classiquement affiché avec des accolades et des majuscules : {550E8400-E29B-41D4-A716-446655440000}. Les accolades proviennent du format de registre Windows ; majuscule est une convention d'affichage. Les deux formes représentent les bits 128 identiques. Pour faire correspondre un GUID de .NET à un UUID de PostgreSQL, supprimez les accolades et normalisez la casse, puis comparez les chaînes. Le chèque bien formé de ToolAcre accepte la forme canonique et supprime automatiquement les accolades. La normalisation est une transformation mineure du texte qui préserve tout son sens.
Ordre des octets mixte-endian — comment les trois premiers champs sont stockés en petit-boutiste dans la structure GUID et pourquoi Guid.ToByteArray diffère de l'ordre des octets RFC
La différence dangereuse entre GUID et UUID est l'ordre des octets. La RFC 9562 spécifie que les trois premiers champs (groupes hexadécimaux 8, 4 et 4) sont stockés dans l'ordre des octets big-endian (réseau). La structure .NET Guid stocke les trois premiers champs en petit-boutiste : les octets sont inversés avant d'écrire dans le stockage. Les mêmes octets 16, lorsqu'ils sont écrits par .NET Guid.ToByteArray() et interprétés par un code conforme à la RFC, produisent des représentations textuelles complètement différentes. Un UUID 550e8400-e29b-41d4-a716-446655440000 dans l'ordre des octets RFC est stocké sous forme d'octets 55 0e 84 00 e2 9b 41 d4 a7 16 44 66 55 44 00 00.
L'ancienne variante de Microsoft : ce que signifie un c ou un d dans le premier caractère du quatrième groupe
En plus de l'ordre des octets, les anciens identifiants Microsoft utilisent parfois un champ de variante non standard. Où RFC 9562 spécifie que le premier caractère du quatrième groupe doit être 8, 9, a ou b, les GUID Microsoft hérités peuvent utiliser c, d, e ou f. Ce sont toujours des UUID valides, mais ils sont conformes à une variante héritée antérieure à la standardisation RFC. Si vous rencontrez un GUID avec c ou d dans le premier caractère du quatrième groupe, vous disposez d'une valeur 128-bit valide qui n'est pas conforme aux bits des variantes RFC. Le .NET moderne génère des GUID conformes aux RFC, les nouveaux identifiants ne devraient donc pas présenter ce problème. Les bits de variantes héritées sont rares mais importants à reconnaître.
Exemple fonctionnel : les mêmes 16 octets rendus dans l'ordre RFC et dans l'ordre de la structure GUID, montrant exactement quels caractères échangent
Prenez le UUID 550e8400-e29b-41d4-a716-446655440000 et convertissez-le en forme de tableau d'octets GUID .NET en utilisant la convention petit-boutiste. Dans l'ordre RFC, les octets sont : le premier champ (550e8400) est égal à 55 0e 84 00, le deuxième champ (e29b) est égal à e2 9b, le troisième champ (41d4) est égal à 41 d4, les quatrième et cinquième égaux à a7 16. 44 66 55 44 00 00. Dans .NET little-endian : le premier champ devient 00 84 0e 55, le deuxième devient 9b e2, le troisième devient d4 41 et le reste reste en big-endian. Le tableau d'octets complet est 00 84 0e 55 9b e2 d4 41 a7 16 44 66 55 44 00 00. Si un système Java lit ces octets en attendant l'ordre RFC, il les interprète comme 00840e55-9be2-d441-a716-446655440000.
Ce que cela ne couvre pas : NEWSEQUENTIALID et l'ordre de SQL Server, qui constituent un sujet de stockage à part entière.
Le comportement de la fonction NEWSEQUENTIALID de SQL Server et ses propriétés spécifiques de classement des identifiants sont des sujets spécifiques à la couche de stockage et à la base de données. Cet article se concentre sur les différences de format et d’ordre des octets au niveau de l’application et de la sérialisation. Les problèmes profonds de gestion de UUID et d'ordre des octets spécifiques à la base de données sont mieux traités dans la documentation spécifique à cette plate-forme de base de données. Différents systèmes de bases de données ont différentes approches et approches en matière de stockage, d'indexation, de tri et de prise en charge native UUID. Certaines bases de données détectent automatiquement les bits de version et de variante, tandis que d'autres nécessitent des déclarations de type explicites et une gestion de l'ordre des octets à la frontière entre les systèmes et le stockage.
À retenir : normaliser à la limite – la vérification ToolAcre accepte la forme canonique, qui est la forme sur laquelle normaliser lors de l'échange d'identifiants
Normaliser à la limite lorsque les identifiants traversent une limite du système .NET/non-.NET. Supprimez les accolades, normalisez la casse de manière cohérente et échangez les trois premiers champs si les octets proviennent de .NET Guid.ToByteArray(). La forme canonique RFC est la norme de référence : huit, quatre, quatre, quatre et douze caractères hexadécimaux minuscules avec tirets, pas d'accolades, ordre des octets gros-boutiste. Lors d'un échange avec des systèmes .NET, convenez d'une forme normalisée et appliquez explicitement les conversions dans le code d'intégration. Documentez la gestion de l’ordre des octets et testez minutieusement les conversions. Les principales similitudes fondamentales entre le GUID et UUID signifient que la plupart des bits 128 sont identiques.