Entwicklertools · UUID Generator
Lesen eines UUID von Hand: Wo die Versions- und Variantenbits leben
· Wie es funktioniert
UUID Kryptographie Browser-APIs
Zwei Hexadezimalzeichen in jedem UUID sagen Ihnen, welche Version es erstellt hat und welchem Variantenlayout es folgt. Lernen Sie, sie auf einen Blick zu lesen und zu wissen, was sie Ihnen nicht sagen können.
Welches System hat diese ID erstellt? – die Log-Forensik-Frage, die das Versionsnibble beantworten kann
Eine UUID-Zeichenfolge besteht aus 36 Zeichen: zweiunddreißig hexadezimale Ziffern und vier Bindestriche an den Positionen 8-4-4-4-12. Zwei Zeichen in jedem UUID – die an den Positionen 14 und 19 erscheinen – kodieren Metadaten: Das Versionsfeld sagt Ihnen, welcher Algorithmus die ID generiert hat, und das Variantenfeld sagt Ihnen, welchem Standardlayout sie folgt. Das Lesen dieser beiden Zeichen ohne Hilfsmittel ist die Fähigkeit der Protokollforensik: Sie entdecken ein UUID in einem Datenbank-Dump oder einer Fehlermeldung und wissen sofort, ob es sich um einen v1-Zeitstempel (der Erstellungszeit verliert), einen v4-Zufallswert (der aus einem CSPRNG generiert wurde) oder etwas anderes handelt. Die Versionsnummer belegt die Bits 48–51 von UUID, die dem ersten Hexadezimalzeichen der dritten Gruppe zugeordnet sind.
Das 128-Bit-Layout in fünf Gruppen – wie 8-4-4-4-12 auf Bytes abgebildet wird und warum die Gruppen historisch und nicht funktionsfähig sind
Für die Zeichenfolge xxxxxxxx-xxxx-4xxx-xxxx-xxxxxxxxxxxx ist das Zeichen an Position 14 die Version. RFC 9562 definiert die Versionen 1 bis 8: v1 basiert auf der gregorianischen Zeit und lässt Erstellungszeit verloren; v4 ist zufällig; v7 ist Unix-zeitbasiert und sortierbar. Version 0, 9 und höher sind reserviert oder nicht verwendet. Wenn Sie v1 UUID sehen, wissen Sie, dass die Zeit und die Hardwareadresse gemischt waren; Wenn Sie v4 sehen, besteht die ID aus zufälligen Bytes mit gesetzten Versionsbits. Wenn Sie v7 sehen, wird nach Erstellungszeit sortiert. Die Version ist nicht optional; Jeder korrekt gebildete UUID hat einen. Das Variantenfeld belegt die Bits 64–65 des UUID, die beiden höchstwertigen Bits des Oktetts 8.
Das Versionsnibble – das erste Zeichen der dritten Gruppe, was 1 bis 8 bedeuten und was ein 0 oder 9 dort anzeigt
In der Textdarstellung xxxxxxxx-xxxx-xxxx-Nxxx-xxxxxxxxxxxx kodiert das erste Zeichen der vierten Gruppe (Position 19) die Variante. Für die RFC-Variante 9562 (der Standard in der modernen Verwendung) muss dieses Zeichen 8, 9, a oder b sein – die hexadezimalen Darstellungen von 1000, 1001, 1010 und 1011 in Binärform. Jedes andere Zeichen (0–7, c–f) weist auf eine andere Variante hin: 0–7 sind NCS-Abwärtskompatibilität; c–d sind Microsoft-Legacy-GUIDs mit Little-Endian-Bytereihenfolge; e–f sind reserviert. Wenn Sie Position 19 lesen und 8, 9, a oder b sehen, sehen Sie einen RFC 9562 UUID. Jeder andere Wert bedeutet, dass die Bytes einer anderen Interpretation folgen. Das 128-Bit-Layout ist in die Oktette 0–15 unterteilt, aber das Textformat trennt sie aus Gründen der Lesbarkeit und nicht der Funktion nach Gruppen.
Das Variantenfeld – warum das erste Zeichen der vierten Gruppe 8, 9, a oder b für RFC-UUIDs ist und welches c/d (Microsoft Legacy) oder 0–7 (NCS) signalisiert
Die fünf Gruppen stellen historische Feldgrenzen dar: Die ersten drei Felder enthalten den Zeitstempel und die Version in v1-UUIDs, das vierte Feld enthält die Taktsequenz und -variante, das fünfte Feld enthält die Knotenkennung. Version 4 und spätere Versionen UUID verwenden diese Feldnamen nicht, aber die gleichen Bitpositionen tragen weiterhin die Version und Variante. Das Lesen eines v4 UUID bedeutet zu akzeptieren, dass die meisten 128-Bits zufällige Nutzdaten sind, aber zwei davon – an den Positionen 14 und 19 im Text – standardmäßig festgelegt sind. Diese festen Bits beweisen, dass es sich bei der ID um eine v4- und RFC-Variante handelt. Die Null UUID ist 00000000-0000-0000-0000-000000000000, alle Nullen und trägt überhaupt keine Version. Das maximale UUID ist ffffffff-ffff-ffff-ffff-ffffffffffff, alle f Zeichen, und ist außerdem reserviert und nicht versioniert.
Bearbeitetes Beispiel – Dekodierung von drei Beispiel-IDs Zeichen für Zeichen, einschließlich einer v4 und einer v7
Jedes andere wohlgeformte UUID hat eine Version in der dritten Gruppe und eine Variante in der vierten. Testen Sie sich selbst mit drei Beispiel-IDs: 123e4567-e89b-12d3-a456-426614174000 (v1, Variante RFC, da Position 19 a ist); 9b2e4f1a-4f3e-4c1a-8a7d-1b2c3d4e5f60 (v4, Variante RFC, weil Position 19 8 ist); 018f0c2e-1b5a-7c3d-9e4f-5a6b7c8d9e0f (v7, Variante RFC, da Position 19 9 ist). Der ToolAcre-Inspektor bestätigt Ihren Messwert. Eine Formatprüfung kann Ihnen nicht sagen, dass eine ID eindeutig ist, in Ihrer Datenbank vorhanden ist oder sicher generiert wurde. Version v1 verwendet Zeit und Hardware als Eingaben, sodass identische v1-UUIDs von verschiedenen Maschinen zu Taktabweichungen oder Synchronisierungsproblemen führen. Version v4 ist zufällig, daher bedeutet ein Duplikat v4 UUID entweder eine gebrochene Zufälligkeit oder eine astronomisch unwahrscheinliche Kollision (ungefähr eine pro 2. 7 Billionen UUIDs mit solider Zufälligkeit).
Nil und Max – die beiden Werte, die nur aus Nullen und nur aus F bestehen und überhaupt keine Version haben
Eine Version 0 oder 9 bedeutet, dass die Zeichenfolge überhaupt kein gültiger UUID ist. Das Lesen der Version und Variante ist der erste Schritt, um zu verstehen, was eine ID ist; Die Überprüfung, ob es existiert oder eindeutig ist, ist der zweite und dritte Schritt, der von Ihrer Datenbank und Geschäftslogik durchgeführt wird. Das Verständnis der Bitpositionen hilft beim Debuggen von Datenmigrationen. Beim Import von UUIDs aus Legacy-Systemen exportieren einige Tools Variantenfelder, die nicht dem RFC-Standard 9562 entsprechen. Ein Variantenfeld von c oder d gibt eine Microsoft-GUID in Little-Endian-Bytereihenfolge an. Diese GUIDs sind gültige Bezeichner innerhalb von Microsoft-Systemen, interagieren jedoch nicht mit RFC-9562-UUIDs ohne Konvertierung der Bytereihenfolge. Durch die Ablesung der Position 19 erfahren Sie sofort, welches System die ID generiert hat. Wenn Sie 8, 9, a oder b sehen, haben Sie einen RFC-Standard UUID.
Was Ihnen eine Formatprüfung nicht sagen kann – ob die ID in Ihrer Datenbank vorhanden ist, dass sie sicher generiert wurde oder dass sie eindeutig ist
Wenn Sie c oder d sehen, haben Sie eine Microsoft GUID. Wenn Sie ein anderes Zeichen sehen, ist die Kennung fehlerhaft oder stammt aus einem unklaren System. Der ToolAcre-Generator erzeugt immer RFC-9562-UUIDs mit der Position 19 als eine von 8, 9, a oder b. Das Drei-Bit-Versionsfeld kodiert sieben mögliche Werte (1–7; Version 0 und 8 haben besondere Bedeutungen). Version 1 ist ein gregorianischer Zeitstempel, Version 3 ist ein MD5-basierter Namespace, Version 4 ist zufällig, Version 5 ist ein SHA-1-basierter Namespace, Version 6 ist eine Unix-Zeitstempel-basierte (vorgeschlagene) Version 7 ist auf Unix-Zeitstempeln sortierbar (standardisiert in RFC 9562), Version 8 ist für benutzerdefinierte Formate reserviert. Wenn Sie das Zeichen position-14 lesen, erfahren Sie sofort, welcher Algorithmus verwendet wurde. Wenn Sie UUID-Kollisionen oder unerwartete Sortierungen debuggen, ist die Versionsnummer Ihr erster Hinweis. ToolAcre generiert v4-UUIDs ausschließlich aus Krypto.
Takeaway: zwei Zeichen, viel Kontext – verwenden Sie die wohlgeformte Prüfung von ToolAcre, um zu bestätigen, dass eine Zeichenfolge analysiert wurde, und lesen Sie dann selbst den Versions-Nibble
getRandomValues; Jeder UUID, den er erzeugt, hat einen 4 an Position 14. Das manuelle Analysieren der UUID-Struktur ist eine nützliche Fähigkeit zum Debuggen komplexer Systeme, für die keine Tools verfügbar sind. Bei einem Produktionsvorfall müssen Sie möglicherweise UUIDs aus einem Datenbank-Dump, einem Fehlerprotokoll oder einem Cache lesen, ohne ein spezielles Tool auszuführen. Sie suchen nach der Position 14, um die Version zu identifizieren (verliert sie Zeit? Ist sie zufällig? Ist sie sortierbar?). Sie suchen nach Position 19, um die Variante zu identifizieren (ist es RFC-Standard? Ist es eine Microsoft GUID? Ist sie reserviert?). Diese beiden Zeichen, von insgesamt 36, tragen die Metadaten. Die restlichen 34 Zeichen sind Nutzlast: Zeitstempel oder Zufallsbytes oder andere algorithmenspezifische Daten. Wenn Sie wissen, was die Nutzlast darstellt, können Sie die Rolle der ID in Ihrem System besser verstehen.