Entwicklertools · UUID Generator
GUID vs. UUID: Klammern, Bytereihenfolge und Variante von Microsoft erklärt
· Hintergrund
UUID Kryptographie Browser-APIs
GUID ist Microsofts Name für einen UUID, aber die geschweiften Klammern, Großbuchstaben und die Bytereihenfolge können dazu führen, dass derselbe Bezeichner auf verschiedenen Plattformen unterschiedlich aussieht. In diesem Beitrag werden die einzelnen Unterschiede erläutert und erläutert, wie ein sicherer Vergleich durchgeführt werden kann.
Dieselbe ID, die systemübergreifend nicht übereinstimmt – ein .NET-Dienst und ein Java-Dienst sind sich über einen Datensatz nicht einig
Ein .NET-Dienst generiert eine GUID und sendet sie an einen Java-Dienst, der versucht, den Wert mit einem UUID von PostgreSQL abzugleichen. Der Zeichenfolgenvergleich schlägt fehl und die Systeme melden, dass die Bezeichner nicht übereinstimmen, obwohl alle drei Dienste mit denselben zugrunde liegenden 16-Bytes arbeiten. Die Unterschiede sind scheinbar kosmetischer Natur – geschweifte Klammern, Groß-/Kleinschreibung, Bytereihenfolge –, aber sie führen dazu, dass Stringvergleiche fehlschlagen und Integrationspunkte verwechseln, die sich an der Grenze nicht normalisieren. GUID ist die Microsoft-Terminologie für das, was RFC 9562 als UUID bezeichnet: einen 128-Bit-Bezeichner mit demselben Bit-Layout. Die beiden Namen beziehen sich auf die gleiche Grundstruktur, die Darstellung unterscheidet sich jedoch in einer Weise, die Entwickler überrascht. Das Verständnis, wo Verwirrung entsteht, verhindert Integrationsfehler.
GUID ist ein UUID – das gemeinsame 128-Bit-Format und woher der Namensunterschied stammt
GUID steht für Globally Unique Identifier und Globally Unique Identifier und ist der Name, den Microsoft für das verwendet, was RFC-Standards als UUID bezeichnen. Das 128-Bit-Layout und die Version/variant des Systems sind identisch. RFC 4122 und RFC 9562 geben das Format und die Bedeutung von UUID an; Microsoft implementiert sie und verwendet den Begriff GUID. Der Namensunterschied ist historisch bedingt: Microsoft verwendete GUID, bevor UUIDs von der IETF standardisiert wurden, und die Microsoft-Terminologie blieb im .NET-Ökosystem hängen. Auf Bitebene sind eine GUID und ein UUID vollständig austauschbar. Auf der Formatierungsebene unterscheiden sie sich in der Darstellung: .NET-Code schreibt GUIDs häufig mit geschweiften Klammern und Großbuchstaben, während kanonische RFC-UUIDs Kleinbuchstaben und keine geschweiften Klammern verwenden.
Klammern und Großbuchstaben – die Registrierungsform {XXXXXXXX-...} und wie man sie normalisiert
Ein UUID in kanonischer RFC-Form wird als acht, vier, vier, vier und zwölf hexadezimale Kleinbuchstaben geschrieben, die durch Bindestriche getrennt sind: 550e8400-e29b-41d4-a716-446655440000. Eine .NET-GUID wird üblicherweise mit geschweiften Klammern und Großbuchstaben angezeigt: {550E8400-E29B-41D4-A716-446655440000}. Die geschweiften Klammern stammen aus dem Windows-Registrierungsformat. Bei Großbuchstaben handelt es sich um eine Anzeigekonvention. Beide Formen stellen die identischen 128-Bits dar. Um eine GUID aus .NET mit einer UUID aus PostgreSQL abzugleichen, entfernen Sie die geschweiften Klammern, normalisieren Sie die Groß-/Kleinschreibung und vergleichen Sie dann die Zeichenfolgen. Die wohlgeformte Prüfung von ToolAcre akzeptiert die kanonische Form und entfernt automatisch geschweifte Klammern. Bei der Normalisierung handelt es sich um eine geringfügige Texttransformation, bei der die gesamte Bedeutung erhalten bleibt.
Mixed-Endian-Bytereihenfolge – wie die ersten drei Felder Little-Endian in der GUID-Struktur gespeichert werden und warum sich Guid.ToByteArray von der RFC-Bytereihenfolge unterscheidet
Der gefährliche Unterschied zwischen GUID und UUID ist die Bytereihenfolge. RFC 9562 gibt an, dass die ersten drei Felder (hexadezimale Gruppen 8, 4 und 4) in Big-Endian-Bytereihenfolge (Netzwerk) gespeichert werden. Die .NET Guid-Struktur speichert die ersten drei Felder in Little-Endian: Die Bytes werden vor dem Schreiben in den Speicher umgekehrt. Dieselben 16 Bytes erzeugen, wenn sie von .NET Guid.ToByteArray() geschrieben und von RFC-kompatiblem Code interpretiert werden, völlig unterschiedliche Textdarstellungen. Ein UUID 550e8400-e29b-41d4-a716-446655440000 in RFC-Bytereihenfolge wird als Bytes 55 0e 84 00 e2 9b 41 d4 a7 gespeichert 16 44 66 55 44 00 00.
Die ältere Microsoft-Variante – was ein c oder d im ersten Zeichen der vierten Gruppe bedeutet
Zusätzlich zur Bytereihenfolge verwenden ältere Microsoft-Identifikatoren manchmal ein nicht standardmäßiges Variantenfeld. Wo RFC 9562 angibt, dass das erste Zeichen der vierten Gruppe 8, 9, a oder b sein muss, verwenden ältere Microsoft-GUIDs möglicherweise c, d, e oder f. Dies sind immer noch gültige UUIDs, sie entsprechen jedoch einer Legacy-Variante, die älter ist als die RFC-Standardisierung. Wenn Sie im ersten Zeichen der vierten Gruppe auf eine GUID mit c oder d stoßen, verfügen Sie über einen gültigen 128-Bit-Wert, der nicht den RFC-Variantenbits entspricht. Modernes .NET generiert RFC-kompatible GUIDs, daher sollte dieses Problem bei neuen Bezeichnern nicht auftreten. Legacy-Variantenbits sind selten, aber wichtig zu erkennen.
Funktioniertes Beispiel – die gleichen 16 Bytes, gerendert in RFC-Reihenfolge und in GUID-Strukturreihenfolge, zeigen genau, welche Zeichen ausgetauscht werden
Nehmen Sie UUID 550e8400-e29b-41d4-a716-446655440000 und konvertieren Sie es mithilfe der Little-Endian-Konvention in die .NET-GUID-Byte-Array-Form. In der RFC-Reihenfolge lauten die Bytes: erstes Feld (550e8400) entspricht 55 0e 84 00, zweites Feld (e29b) entspricht e2 9b, drittes Feld (41d4) entspricht 41 d4, viertes und fünftes entsprechen a7 16 44 66 55 44 00 00. In .NET Little-Endian: Das erste Feld wird zu 00 84 0e 55, das zweite wird zu 9b e2, das dritte wird zu d4 41 und der Rest bleibt im Big-Endian. Das vollständige Byte-Array ist 00 84 0e 55 9b e2 d4 41 a7 16 44 66 55 44 00 00. Wenn ein Java-System diese Bytes in der RFC-Reihenfolge liest, interpretiert es sie als 00840e55-9be2-d441-a716-446655440000.
Was hiervon nicht abgedeckt wird – die NEWSEQUENTIALID und Reihenfolge von SQL Server, die ein eigenes Speicherthema darstellen
Das Verhalten der SQL Server-Funktion NEWSEQUENTIALID und ihre spezifischen Eigenschaften für die Reihenfolge der Bezeichner sind speicherschicht- und datenbankspezifische Themen. Dieser Beitrag konzentriert sich auf die Format- und Bytereihenfolgeunterschiede auf Anwendungs- und Serialisierungsebene. Tiefgreifende datenbankspezifische UUID-Handhabung und Byte-Reihenfolge-Probleme werden am besten in der Dokumentation speziell für diese Datenbankplattform behandelt. Unterschiedliche Datenbanksysteme verfügen über unterschiedliche Ansätze und Ansätze zur UUID-Speicherung, Indizierung, Sortierung und nativen Unterstützung. Einige Datenbanken erkennen die Versions- und Variantenbits automatisch, während andere explizite Typdeklarationen und die Handhabung der Bytereihenfolge an der Grenze zwischen Systemen und Speicher erfordern.
Imbiss: An der Grenze normalisieren – die ToolAcre-Prüfung akzeptiert die kanonische Form, also die Form, auf die beim Austausch von IDs standardisiert werden soll
An der Grenze normalisieren, wenn Bezeichner eine .NET/non-.NET-Systemgrenze überschreiten. Entfernen Sie geschweifte Klammern, normalisieren Sie die Groß- und Kleinschreibung konsistent und tauschen Sie die ersten drei Felder durch Byte-Austausch aus, wenn Bytes von .NET Guid.ToByteArray() stammen. Die kanonische RFC-Form ist der Referenzstandard: acht, vier, vier, vier und zwölf hexadezimale Kleinbuchstaben mit Bindestrichen, keine geschweiften Klammern, Big-Endian-Bytereihenfolge. Vereinbaren Sie beim Austausch mit .NET-Systemen eine normalisierte Form und wenden Sie Konvertierungen explizit im Integrationscode an. Dokumentieren Sie die Handhabung der Bytereihenfolge und testen Sie Konvertierungen gründlich. Die wesentlichen grundlegenden Ähnlichkeiten zwischen GUID und UUID bedeuten, dass die meisten 128-Bits identisch sind.