🧰 ToolPicoAlle Tools →

Startseite › Blog › UUID, ULID oder v7?

UUID, ULID oder v7? So kombinierst du die Modi im ToolPico-Generator richtig

v4-UUID, v7-UUID und ULID lösen auf den ersten Blick dasselbe Problem — einen eindeutigen Bezeichner erzeugen —, unterscheiden sich aber in Kodierung, Sortierbarkeit und typischem Einsatzort im System. Dieser Leitfaden zeigt, wie du die Modi in einem realistischen Beispiel-Workflow kombinierst und mit den Zusatzwerkzeugen des Generators (Konverter, Zeitstempel-Decoder) arbeitest.

Inhalt

Drei ähnliche Formate, drei unterschiedliche Jobs

Kurzantwortv4 ist rein zufällig und ideal für unabhängige, nicht sortierte Datensätze; v7 ist eine UUID mit eingebautem Zeitstempel für sortierte Datenbankschlüssel; eine ULID ist ebenfalls zeitlich sortierbar, nutzt aber ein 26-stelliges Base32-Format statt der klassischen Hex-Schreibweise.

Alle drei Formate sind letztlich 128-Bit-Werte, aber sie unterscheiden sich in zwei Dimensionen: ob ein Zeitstempel eingebettet ist und wie der Wert als Text dargestellt wird. Eine v4-UUID enthält keinerlei Zeitinformation und wird als 36-Zeichen-Hex-String mit Bindestrichen geschrieben. Eine v7-UUID nutzt dieselbe Hex-Schreibweise, beginnt aber mit einem Millisekunden-Zeitstempel in den ersten 48 Bit. Eine ULID enthält denselben Zeitstempel-Ansatz, wird aber komplett anders kodiert: 26 Zeichen aus dem Crockford-Base32-Alphabet, ohne Bindestriche, groß-/kleinschreibungsunabhängig lesbar.

FormatZeitstempel?TextkodierungTypischer Einsatzort
v4-UUIDNeinHex, 36 Zeichen mit BindestrichenSitzungs-Token, unabhängige Datensätze
v7-UUIDJa (ms-genau)Hex, 36 Zeichen mit BindestrichenDatenbank-Primärschlüssel
ULIDJa (ms-genau)Crockford Base32, 26 ZeichenLog-Dateinamen, Objektspeicher-Keys

Im ToolPico-UUID-Generator lassen sich alle drei direkt nebeneinander erzeugen: v4 und v7 über die entsprechenden Tab-Reiter mit Bulk-Generierung, ULID über das eigene Mini-Tool im Abschnitt der Zusatzwerkzeuge auf derselben Seite.

Beispiel-Workflow: v7 für die Datenbank, ULID für Log-Dateien

KurzantwortEin gängiges (hier beispielhaft skizziertes) Muster ist, v7-UUIDs als sortierte Datenbank-Primärschlüssel zu nutzen und parallel ULIDs für Dateinamen oder Objektspeicher-Keys derselben Ereignisse zu verwenden, weil beide Formate zeitlich sortierbar sind, sich aber für unterschiedliche Kontexte eignen.

Angenommenes Beispiel-Szenario: Ein Team baut eine Event-Pipeline, die eingehende Ereignisse zunächst in einer relationalen Datenbank protokolliert und gleichzeitig als Rohdaten-Datei in einem Objektspeicher (etwa S3-kompatibel) ablegt. Für die Datenbanktabelle wählt das Team v7-UUIDs als Primärschlüssel, weil die meisten modernen Datenbanken einen nativen UUID-Spaltentyp unterstützen und die Sortierbarkeit die Indexpflege bei hohem Ereignisaufkommen erleichtert (siehe dazu auch den Grundlagen-Beitrag zu v4 vs. v7 auf diesem Blog).

Für die Dateinamen im Objektspeicher entscheidet sich dasselbe Team für ULIDs statt v7-UUIDs — aus einem praktischen Grund: Ein 26-Zeichen-Base32-String ohne Bindestriche ist als Dateiname oder URL-Segment kompakter, und die Groß-/Kleinschreibungsunabhängigkeit des Crockford-Alphabets reduziert das Risiko von Tippfehlern beim manuellen Kopieren im Vergleich zu einem längeren Hex-String. Beide IDs — die v7-UUID in der Datenbank und die ULID im Dateinamen — bleiben durch denselben eingebetteten Zeitstempel zeitlich vergleichbar, auch wenn sie unterschiedlich aussehen.

PraxishinweisWenn zwei verschiedene ID-Formate im selben System für dasselbe Ereignis existieren, lohnt es sich, in einer zentralen Stelle der Anwendung zu dokumentieren, welches Format wo erwartet wird — sonst entsteht schnell derselbe Formatierungs-Verwirrung wie zwischen zwei UUID-Darstellungen mit und ohne Bindestriche.

Zum Testen eines solchen Setups eignet sich die Bulk-Generierung im v7-Reiter (bis zu 1.000 Werte auf einmal) in Kombination mit dem separaten ULID-Mini-Tool auf derselben Seite — beide lassen sich unabhängig voneinander mit einem Klick kopieren oder als Datei herunterladen, um realistische Testdaten für beide Seiten der Pipeline zu erzeugen.

Base64/Hex-Konvertierung und Zeitstempel-Decoding als Debugging-Hilfe

KurzantwortDer UUID-⇄-Base64/Hex-Konverter und der Zeitstempel-Decoder im Validator-Reiter helfen dabei, IDs aus unterschiedlichen Systemteilen (Binärprotokoll, Log-Datei, Datenbank) auf ein gemeinsames, vergleichbares Format zu bringen.

Ein Konverter wird vor allem dann nützlich, wenn eine ID nicht im gewohnten 36-Zeichen-Format vorliegt — etwa wenn ein Binärprotokoll UUIDs als 16-Byte-Blob überträgt oder eine ältere API sie Base64-kodiert zurückgibt. Statt die Umrechnung manuell nachzuvollziehen, lässt sich der Wert direkt in den UUID-⇄-Base64/Hex-Konverter dieses Tools einfügen, um ihn in die Standarddarstellung zurückzuverwandeln — und umgekehrt.

Ähnlich hilfreich ist der eingebettete Zeitstempel-Decoder im Reiter „Validieren": Fügst du dort eine v1-, v7-UUID oder eine ULID ein, decodiert das Tool den eingebetteten Erstellungszeitpunkt automatisch in UTC und deiner lokalen Zeitzone. Das ist besonders praktisch bei der Fehlersuche in einer Pipeline wie der oben beschriebenen — etwa um schnell zu prüfen, ob ein Datenbankeintrag (v7) und eine zugehörige Log-Datei (ULID) tatsächlich zum selben Zeitpunkt erzeugt wurden, ohne den Zeitstempel von Hand aus dem Bit-Layout herauszurechnen.

  • Bei Formatabweichungen: zuerst mit dem Konverter auf ein gemeinsames Format (z. B. Standard-Hex) normalisieren, bevor du zwei IDs manuell vergleichst.
  • Bei Zeitfragen: den Validator-Reiter nutzen, statt den Zeitstempel manuell aus Hex- oder Base32-Zeichen zu extrahieren.
  • Bei gemischten v4/v7-Beständen: beachten, dass der Zeitstempel-Decoder bei v4- und v3/v5-UUIDs naturgemäß kein Datum liefern kann, da diese keine Zeitinformation enthalten.

v4, v7 und ULID direkt nebeneinander generieren, zwischen Base64/Hex konvertieren und eingebettete Zeitstempel decodieren — alles im Browser, ganz ohne Serveranfrage.

Zum UUID-Generator →

Häufig gestellte Fragen

Ist eine ULID einfach nur eine anders formatierte UUID?
Nicht ganz. Beide sind 128-Bit-Werte, aber eine ULID wird immer im 26-stelligen Crockford-Base32-Alphabet dargestellt, nicht als Hex-String mit Bindestrichen. Zusätzlich sind bei einer ULID die ersten 48 Bit immer ein Millisekunden-Zeitstempel — das ist bei einer v4-UUID nie und bei einer v7-UUID zwar auch der Fall, aber in anderer Zeichenkodierung. Eine ULID lässt sich nicht einfach durch Neuformatieren aus einer beliebigen UUID gewinnen, weil die zugrunde liegenden Bit-Layouts unterschiedlich definiert sind.
Wie wandle ich eine UUID in Base64 oder Hex um, und wofür ist das nützlich?
Der Konverter-Abschnitt dieses Tools rechnet eine UUID direkt in ihre Base64- und reine Hex-Darstellung um. Das ist z. B. hilfreich, wenn ein Binärprotokoll oder eine ältere API-Schnittstelle UUIDs nicht im Standard-8-4-4-4-12-Format erwartet, sondern als kompakteren Base64-String, oder wenn du beim Debuggen eines Binär-Dumps schnell prüfen willst, ob eine Hex-Sequenz einer bekannten UUID entspricht.
Kann ich in einer Event-Pipeline v7-UUIDs und ULIDs gleichzeitig sinnvoll einsetzen?
Ja, das ist ein gängiges Muster: Manche Systeme verwenden v7-UUIDs als interne Datenbankschlüssel (weil viele ORMs und Datenbanktreiber nativ UUID-Spaltentypen unterstützen), während dieselbe Zeitreihe zusätzlich mit ULIDs für Log-Dateinamen oder Objektspeicher-Keys arbeitet, wo das kürzere, groß-/kleinschreibungsunabhängige Base32-Format praktischer ist. Wichtig ist nur, konsistent zu dokumentieren, welches Format an welcher Stelle des Systems erwartet wird.
Wie finde ich heraus, zu welcher Sekunde ein bestehender v7-Wert oder eine ULID gehört?
Füge den Wert in den Reiter „Validieren“ des ToolPico-UUID-Generators ein. Bei v7-UUIDs und ULIDs wird der eingebettete Millisekunden-Zeitstempel automatisch erkannt und sowohl in UTC als auch in deiner lokalen Zeitzone als lesbares Datum angezeigt — praktisch, um z. B. beim Debugging schnell zu sehen, wann ein bestimmter Datensatz oder ein Log-Eintrag tatsächlich erzeugt wurde, ohne den Wert manuell dekodieren zu müssen.
Warum sollte ich beim Vergleich von IDs aus unterschiedlichen Systemen auf das Format achten?
Wenn ein System UUIDs im Standardformat und ein anderes ULIDs oder Base64-kodierte Werte für denselben Datensatz verwendet, sehen die beiden IDs auf den ersten Blick völlig unterschiedlich aus, selbst wenn sie inhaltlich verwandt sind oder aus derselben Quelle stammen. Ein direkter String-Vergleich zwischen den Formaten schlägt praktisch immer fehl. Für Debugging- oder Migrationszwecke lohnt es sich, alle beteiligten Werte zunächst mit einem Konverter auf ein gemeinsames Format zu bringen, bevor man sie manuell vergleicht.

Ähnliche Rechner

UUID vs. GUID: Welche Version für die Datenbank?Der Grundlagen-Vergleich zu v1, v3/v5, v4 und v7 — Format, Kollisionswahrscheinlichkeit und Performance-Überlegungen. 5 typische UUID-Fehler in Code-ReviewsFalscher Spaltentyp, verwechselte v1/v4-Modi und uneinheitliche Formatierung — mit praktischen Korrekturen.
Hinweis zur Methodik: Dieser Artikel dient der allgemeinen Information zu UUID-, v7- und ULID-Formaten gemäß RFC 4122/9562 und der ULID-Spezifikation und ersetzt keine individuelle Architektur- oder Datenbankberatung. Der beschriebene Event-Pipeline-Workflow ist ein angenommenes, illustratives Beispiel und kein dokumentierter Fall eines konkreten Projekts.