UUID-Generator: v4, v7, v5 und Bulk-Listen

Welche Version sollte ein UUID-Generator liefern?

Jede UUID besteht aus 128 Bit, geschrieben als 32 Hex-Ziffern in fünf Gruppen, 8-4-4-4-12. Zwei dieser Ziffern sind reine Verwaltung: Die 13. Ziffer ist die Version, die 17. trägt die Variante (8, 9, a oder b bei UUIDs nach RFC 9562). Alles andere füllt die Version: Zufallsbits, einen Zeitstempel, einen Zähler oder einen Hash. Wer die Version wählt, entscheidet also, was davon im eigenen Schlüssel stecken soll.

Meine Faustregel: v4, außer die ID ist ein Datenbankschlüssel mit vielen Inserts – dann v7. RFC 9562 selbst empfiehlt, wo möglich v7 statt v1 und v6 zu verwenden. Das namensbasierte v5 fällt aus der Reihe: Hier geht es nicht um Eindeutigkeit über die Zeit, sondern darum, zweimal dieselbe Antwort zu bekommen. Genau das brauchen Sie, wenn sich zwei Services auf die ID von „https://example.com/item/42“ einigen müssen, ohne miteinander zu reden. Der Leitfaden zu v4 vs. v7 beleuchtet die Index-Seite dieser Entscheidung.

Eine praktische Warnung zu v7: Die ersten 12 Hex-Ziffern sind die Erstellungszeit in Millisekunden, für jeden lesbar. Fügen Sie 017f22e2-79b0-7cc3-98c4-dc0c0c07398f im Tab „Prüfen & dekodieren“ ein, und Sie sehen den exakten Zeitpunkt der Erzeugung. Wenn Nutzer die ID zu sehen bekommen und der Zeitpunkt heikel ist, geben Sie ihnen eine v4.

Formate: dieselben 128 Bit, sieben Schreibweisen

Die meisten „invalid UUID“-Fehler, denen ich hinterhergejagt bin, waren gar keine kaputten IDs, sondern schlicht die falsche Schreibweise für das System am anderen Ende. Der UUID-Generator behält die Bits und ändert nur den Text, sodass derselbe Wert in jedes dieser Formate passt:

Die Option Trennzeichen (Bindestrich, keins, Punkt oder Unterstrich) gilt nur für die Standardform, die Großbuchstaben und die Klammern; eine URN mit Punkten wäre keine gültige URN mehr, deshalb sperrt das Tool dort das Trennzeichen. Bei der Eingabe ist es umgekehrt: RFC 9562 verlangt Kleinbuchstaben in der Ausgabe, beim Einlesen aber Unabhängigkeit von Groß- und Kleinschreibung, und der Decoder akzeptiert alle obigen Formen außer Base64. Wenn Sie die Byte-Reihenfolge von .NET oder die Eigenheiten von SQL Server brauchen, lesen Sie UUID vs. GUID.

Bulk-Listen für Fixtures und Seed-Dateien

Der Tab „Bulk-Liste“ erzeugt 1 bis 10.000 IDs auf einmal und exportiert sie als reinen Text, als CSV mit der Kopfzeile uuid, als JSON-Array oder als fertiges INSERT INTO items (id) VALUES …-Statement (Tabelle und Spalte einfach auf Ihre umbenennen). Zwei Details sind wichtiger als die Anzahl:

• v7-Listen sind streng aufsteigend. Zehntausend IDs entstehen innerhalb weniger Millisekunden, die meisten teilen sich also einen Zeitstempel. Ohne Zähler kämen sie innerhalb jeder Millisekunde in zufälliger Reihenfolge heraus; mit Zähler sortiert sich die Liste als Text genauso wie als Bytes, und die Infozeile bestätigt „streng aufsteigend“.
• v5 und v3 erwarten Namen, einen pro Zeile. Fügen Sie eine Spalte mit Domains, URLs oder Produktcodes ein, und Sie erhalten pro Zeile eine deterministische ID – identisch mit dem, was Pythons uuid5() für denselben Namespace und Namen zurückgibt.

Können zwei UUIDs jemals gleich sein?

Bei zufälligen v4-IDs lautet die ehrliche Antwort: „Ja, mit einer Wahrscheinlichkeit, die man ausrechnen kann, um sich danach keine Sorgen mehr zu machen.“ Mit 122 Zufallsbits liefert die Näherung aus dem Geburtstagsproblem:

Ein Rechenbeispiel: Sie erzeugen eine Milliarde v4-IDs, n = 10⁹. Dann ist n² = 10¹⁸, 2 × 2¹²² ≈ 1,063 × 10³⁷, der Exponent beträgt etwa 9,4 × 10⁻²⁰, und p ≈ 9,4 × 10⁻²⁰. Bei einer Billion IDs sind es etwa 9,4 × 10⁻¹⁴. Sie brauchen ungefähr 2,7 × 10¹⁸ IDs, bis die Chance auf ein einziges Duplikat die Hälfte erreicht.

Das echte Risiko ist nie die Mathematik, sondern eine schwache Zufallsquelle: ein kopiertes Snippet auf Basis von Math.random(), ein geforkter Prozess, der seinen Seed wiederverwendet, oder ein VM-Image, das samt Zustand geklont wurde. Dieser UUID-Generator holt jedes Zufallsbit aus crypto.getRandomValues(), dem kryptografischen Zufallsgenerator des Browsers. Bei v7 kollidieren zwei unabhängige Generatoren nur, wenn sie dieselbe Millisekunde erwischen und dann in rund 73 Zufallsbits übereinstimmen (der Zähler startet mit 41 Zufallsbits, weitere 32 Bit bleiben zufällig). Setzen Sie trotzdem einen Unique-Constraint auf die Spalte: Er kostet nichts und macht aus einem theoretischen Problem einen lauten Fehler.

Prüfen und dekodieren: was eine ID verrät

Fügen Sie eine UUID im Tab „Prüfen & dekodieren“ ein, und Sie erhalten ihre kanonische Form, Version und Variante, die eingebettete Zeit bei v1, v6 und v7 (in UTC und in Ihrer Ortszeit), Clock-Sequenz und Node bei v1/v6 sowie die Schreibweisen als BINARY(16)-Hex und Base64. Die Node-Prüfung zeigt, ob eine v1-ID einen zufälligen Node trägt (Multicast-Bit gesetzt, wie RFC 9562 es empfiehlt) oder etwas, das nach der Adresse einer echten Netzwerkkarte aussieht – ein Datenleck, von dem man wissen sollte.

Fügen Sie stattdessen eine ganze Spalte ein, wird daraus eine Listenprüfung: wie viele Zeilen gültig sind, welche nicht und warum („31 Hex-Ziffern gefunden“, „Bindestriche müssen die Ziffern 8-4-4-4-12 trennen“), wie viele Duplikate es gibt, ob die Liste aufsteigend sortiert ist und welche Versionen sie enthält. Das ist der schnellste Weg, den ich kenne, um eine Importdatei zu prüfen, bevor sie auf einen Unique-Index trifft.

Außerdem ist die Prüfung dort streng, wo alte Validatoren schlampig waren. Eine UUID mit der Versionsziffer 0 ist nicht die Nil-UUID, solange nicht alle 32 Ziffern null sind; eine ID mit der alten Microsoft-Variante (17. Ziffer c oder d) ist formal korrekt, aber ihre Versionsziffer bedeutet nichts – und das Ergebnis sagt genau das, statt eine Version zu erfinden.

UUIDs speichern, ohne es später zu bereuen

1. Nutzen Sie den nativen Typ. PostgreSQL uuid und SQL Server uniqueidentifier speichern 16 Bytes. Eine Textspalte mit 36 Zeichen braucht mehr als das Doppelte, in der Tabelle und in jedem Index, der sie enthält. In MySQL nehmen Sie BINARY(16); das 0x-Format liefert Ihnen das passende Literal.
2. Nehmen Sie v7 für geclusterte Schlüssel oder Schlüssel mit vielen Inserts. Neue v7-Werte landen am Ende des Index statt auf zufälligen Seiten.
3. Halten Sie in Ihrer API eine kanonische Schreibweise ein. Kleinbuchstaben mit Bindestrichen. Vergleichen Sie unabhängig von Groß- und Kleinschreibung, wenn Sie Eingaben aus anderen Systemen annehmen.
4. Behandeln Sie eine UUID nie als Geheimnis. RFC 9562 sagt ausdrücklich, man solle nicht davon ausgehen, dass UUIDs schwer zu erraten sind. Links zum Zurücksetzen von Passwörtern und API-Keys brauchen ein eigenes zufälliges Token.
5. Liefern Sie kein v1 mit echter MAC-Adresse aus. Sie verrät die Maschine und den Zeitpunkt. Dieses Tool verwendet immer einen zufälligen Node.

Die Einzeiler, mit denen Sie UUIDs in PostgreSQL, JavaScript, Python, Java und C# erzeugen, finden Sie unter UUIDs im Code erzeugen.

Woher die Bits kommen und wie ich sie teste

Der UUID-Generator arbeitet komplett in Ihrem Browser; die Seite sendet nichts irgendwohin. Die Zufallsbits stammen aus crypto.getRandomValues(). Version 7 folgt RFC 9562 §6.2, Methode 1, mit einem 42-Bit-Zähler (dasselbe Schema wie Pythons uuid7()): ein frischer Zufalls-Seed in jeder neuen Millisekunde, plus eins für jede weitere ID in dieser Millisekunde, und springt die Uhr zurück, wird der letzte Zeitstempel weiterverwendet, damit die Reihenfolge nie bricht. Die Versionen 1 und 6 zählen 100-Nanosekunden-Ticks seit Beginn des gregorianischen Kalenders, addieren pro ID innerhalb derselben Millisekunde einen Tick und verwenden einen zufälligen Node mit gesetztem Multicast-Bit. Die Versionen 5 und 3 hashen die 16 Namespace-Bytes, gefolgt vom UTF-8-kodierten Namen, mit SHA-1 bzw. MD5 und setzen danach die Versions- und Variantenbits, genau wie es der Text von RFC 9562 und das Python-Modul uuid tun.

Das frühere Skript auf dieser Seite hatte einen echten Bug, den ich gestehen muss: Seine v1-Zeitstempel-Arithmetik ließ einen vorzeichenbehafteten 32-Bit-Integer überlaufen, sodass es in etwa der Hälfte von jeweils sieben Minuten IDs mit einem Minuszeichen am Anfang erzeugte. Auch die v7-Ausgabe kam innerhalb einer Millisekunde unsortiert heraus. Beides ist behoben, und die folgenden Kontrollfälle gehören zu denen, gegen die das Tool bei jeder Änderung getestet wird: