UUID-/ULID-Decoder

Der UUID-Decoder liest die verborgene Struktur in einer UUID oder einer ULID. Fügen Sie eine Kennung ein, und das Tool validiert ihr Format, meldet Version und Variante und extrahiert die Metadaten, die das Layout trägt: Erstellungszeitstempel, das Knotenfeld und die Clock-Sequence. Entwickler nutzen es, um zu bestätigen, welche Version eine Bibliothek tatsächlich erzeugt, um einen Datensatz aus seinem Primärschlüssel zu datieren und um Kennungen vor einer Migration zu prüfen. Die gesamte Auswertung findet im Browser statt.

Die fünf Gruppen lesen

Eine UUID ist ein 128-Bit-Wert, geschrieben als 32 Hexadezimalstellen, aufgeteilt in 8-4-4-4-12 mit Bindestrichen. Jede Gruppe hat eine konventionelle Rolle, und der Decoder beschriftet sie: Die erste Gruppe ist time_low, die zweite time_mid, die dritte kombiniert die 4-Bit-Version mit den hohen Zeitbits, die vierte kombiniert die Variante mit der Clock-Sequence, und die fünfte ist der Knoten. Zwei Positionen entscheiden über den größten Teil der Bedeutung. Die dreizehnte Hexadezimalstelle — das erste Zeichen der dritten Gruppe — ist das Versions-Nibble, eine 4 dort bedeutet also zufällig und eine 1 zeitbasiert. Die neunzehnte Stelle, die erste der vierten Gruppe, enthält die Variantenbits, die einem Parser sagen, ob der Wert RFC 4122, einem älteren NCS-Layout oder der Microsoft-GUID-Konvention folgt.

Versionen im Überblick

Version	Grundlage	Hier dekodierter Zeitstempel
v1	Zeit seit 1582 plus Knoten	Ja
v2	DCE-Sicherheit	Nein
v3	MD5-namensbasiert	Nein
v4	Zufällig	Nein
v5	SHA-1-namensbasiert	Nein
v6	Neu geordnete Zeit	Nein (nicht geparst)
v7	Unix-Millisekunden plus Zufall	Ja
v8	Benutzerdefiniert, herstellerspezifisch	Nein

Die praktische Erkenntnis: Wenn Sie wissen müssen, wann eine Kennung erstellt wurde, antworten nur v1 und v7. Ein v4-Wert ist konstruktionsbedingt undurchsichtig, und v3 und v5 sind deterministische Hashes aus Namespace und Name und verraten daher nichts über die Zeit.

Praxisbeispiele: v4, v1 und v7

Für die übliche Zufallskennung 550e8400-e29b-41d4-a716-446655440000 meldet der Decoder Version 4, Variante RFC 4122/DCE, Knoten 44:66:55:44:00:00, Clock-Sequence 0x2716 und das Random-Kennzeichen. Es erscheint keine Zeitstempelzeile, weil v4 keine hat.

Für die Kennung der Version 1 04afc000-833b-11ee-a716-446655440000 meldet es Version 1 und einen eingebetteten Zeitstempel von 2023-11-14T22:13:20.000Z. Der Knoten ist 44:66:55:44:00:00 und die Clock-Sequence 0x2716. Der Knoten ist hier echte Generatorinformation, was das unten erörterte Datenschutzproblem darstellt.

Für die Kennung der Version 7 018bcfe5-6800-7abc-8def-0123456789ab meldet es Version 7 und denselben Zeitstempel 2023-11-14T22:13:20.000Z, gelesen aus dem führenden 48-Bit-Millisekundenwert. Die Knotenzeile wird weiterhin gerendert, weil das Layout diese Bytes immer enthält, doch bei v7 sind sie zufällig statt einer Hardwareadresse.

Zeitstempel in ULIDs und sortierbare Schlüssel

Eine ULID hat ebenfalls 128 Bit und wird als 26 Zeichen in Crockford Base32 geschrieben, einem Alphabet, das die leicht verwechselbaren Buchstaben I, L, O und U auslässt. Die ersten 10 Zeichen kodieren einen 48-Bit-Unix-Millisekunden-Zeitstempel, die restlichen 16 sind Zufall. Das Einfügen von 01HF7YAT007ZZZZZZZZZZZZZZZ ergibt einen Zeitstempel von 2023-11-14T22:13:20.000Z, einen Zeitstempelteil von 01HF7YAT00 und einen Zufallsteil von 7ZZZZZZZZZZZZZZZ. Weil die Zeit vorne steht und die Kodierung lexikografisch ist, sortieren ULIDs genau wie v7-UUIDs nach Erstellungszeit, aber in einer kürzeren, URL-sicheren Zeichenkette.

Die Wahl der Datenbank-Engine entscheidet oft mehr über die Version als jede Spezifikation. Zufällige v4-Schlüssel verteilen Einfügungen über einen B-Baum, was Schreibvorgänge ausgeglichen hält, aber Indexseiten in zufälliger Reihenfolge aufspalten lässt und den Speicher mit der Zeit aufblähen kann. Zeitgeordnete v7- und ULID-Schlüssel hängen sich nahe dem Ende des Index an, sodass Einfügungen auf der heißen Seite bleiben und Bereichsabfragen nach Erstellungszeit günstig sind, zum Preis eines leicht erratbaren Erstellungsfensters. Eine ULID wird als 26-Zeichen-String gespeichert, der in jeder Sprache gleich sortiert, während v7 die vertraute UUID-Form behält und in bestehende uuid-Spalten passt. Wenn eine Tabelle bereits auf 36-Zeichen-UUIDs schlüsselt, ist v7 das reibungsärmere Upgrade; wenn Sie das Schema kontrollieren und kompakte, groß-/kleinschreibungsunabhängige Schlüssel wollen, passt eine ULID oft besser.

Wo der Decoder endet

Dies ist ein Leser, kein Generator und kein Validator für kryptografische Zwecke. Er rekonstruiert nicht den Namespace und Namen hinter einer v3- oder v5-UUID, dekodiert nicht die DCE-Domain einer v2 und interpretiert kein v8-Herstellerlayout. Version 6 ist zeitbasiert, aber das Tool packt sie nicht aus. Ein v1-Wert mit einem Zeitstempel vor der Unix-Epoche liefert kein Datum, und die strenge Formatprüfung weist geschweifte Klammern, fehlende Bindestriche und urn-Präfixe zurück. Er kann Ihnen auch nicht sagen, ob eine gegebene Kennung authentisch oder eindeutig ist — nur, ob ihre Struktur in sich konsistent ist.

Datenschutzhinweise zu v1

Das Knotenfeld einer UUID der Version 1 ist historisch die MAC-Adresse der erzeugenden Maschine, und die Clock-Sequence plus der 60-Bit-Zeitstempel grenzen sowohl das Gerät als auch den Moment ein. Ein v1-Schlüssel, der in einer öffentlichen API, einer geteilten Tabelle oder einem Support-Ticket offenliegt, kann daher mehr preisgeben als beabsichtigt. Moderne Bibliotheken ersetzen den Knoten oft durch Zufallsbytes, aber das lässt sich dem Wert allein nicht ansehen. Behandeln Sie bei der Prüfung von Kennungen einen v1-Knoten als sensibel; bevorzugen Sie v4, wenn nur Eindeutigkeit zählt, und v7, wenn Sie sortierbare Schlüssel wollen und akzeptieren, dass die Erstellungszeit sichtbar ist.

Verwandte Tools

• UUID-Generator
• Zeitstempel-Konverter
• JWT-Decoder
• Hash-Generator