UUID-Generator

v4 UUIDs sind 122 Bit kryptografisch starker Zufälligkeit — der allgegenwärtige Standard für Idempotenz-Schlüssel, Sitzungs-IDs und überall dort, wo Sie einen opaken, ungeordneten Bezeichner möchten. v7 UUIDs betten einen 48-Bit-Unix-Millisecond-Zeitstempel in die führenden Bytes ein, sodass zeitlich nah erzeugte Werte lexikografisch nah sortiert werden. Das macht v7 besser geeignet für Datenbank-Primärschlüssel, wo Einfügungen sonst einen B-tree-Index fragmentieren können.

Beispiel

Drei v4 UUIDs (zufällig, ohne Reihenfolge):

f47ac10b-58cc-4372-a567-0e02b2c3d479
6ba7b810-9dad-11d1-80b4-00c04fd430c8
d1b2c3e4-5678-4abc-9def-0123456789ab

Drei v7 UUIDs, erzeugt innerhalb derselben Millisekunde (beachten Sie den gemeinsamen Präfix):

018f8e50-fcaa-7c3c-8d2a-6f5b72e1fd90
018f8e50-fcaa-7c3d-a41f-8c9b07e2c0d1
018f8e50-fcab-7c01-b3e7-1d9a4f5c6e82

Häufige Fehler und Fallstricke

Dies sind die echten Fallstricke, auf die Entwickler stoßen, wenn sie UUIDs in eine Anwendung einbauen:

• v4 dort verwenden, wo die Einfügereihenfolge wichtig ist. Das Indizieren von 10 Mio. zufälligen v4 verursacht schwere Page-Splits in einem B-tree. Wenn Sie v4 behalten, leben Sie entweder mit der Schreibverstärkung oder wechseln Sie den Primärschlüssel zu v7.
• Bindestriche entfernen und das Versions-Nibble verlieren. f47ac10b58cc4372a5670e02b2c3d479 ist immer noch eine gültige 32-Zeichen-Hex-UUID, aber das 13. Zeichen (4) ist der Versionsmarker — kein zufälliges Nibble. Gehen Sie nicht davon aus, dass alle 32 Zeichen zufällig sind.
• Sich auf Math.random() verlassen. Ältere Bibliotheken, die auf Math.random() aufbauen, sind nicht kryptografisch stark und können vorhersagbar sein. Verwenden Sie crypto.randomUUID() (Browser und Node 19+) oder eine v7-Bibliothek, die aus crypto liest.
• v7 als Zeitstempel behandeln. Die führenden 48 Bit tragen Zeit, aber der Rest ist zufällig, daher sind zwei v7 mit derselben Millisekunde nicht deterministisch geordnet. Verlassen Sie sich nicht auf Tie-Breaking.
• Als VARCHAR(36) speichern. Es funktioniert, verdoppelt aber den Speicher gegenüber einer nativen 16-Byte-UUID / BINARY(16)-Spalte und verlangsamt Joins. Verwenden Sie den nativen Typ der Datenbank (uuid in Postgres, UNIQUEIDENTIFIER in SQL Server).
• Regex, der eine bestimmte Version verlangt. /[0-9a-f]{8}-[0-9a-f]{4}-4[0-9a-f]{3}-.../i passt nur zu v4. Wenn Sie später v7 emittieren, weist dieser Regex gültige IDs stillschweigend ab.

Was ist der Unterschied zwischen UUID v4 und v7?

v4 ist 122 Bit Zufälligkeit plus Versions- und Variantenmarker, ohne Zeitkomponente. v7 stellt einen 48-Bit-Unix-Millisecond-Zeitstempel voran und füllt den Rest mit zufälligen Bits, sodass zeitlich nah erzeugte v7-Werte lexikografisch sortieren. Verwenden Sie v7 als Datenbank-Primärschlüssel, um B-tree-Einfügungen lokal zu halten; verwenden Sie v4, wenn Sie überhaupt kein Ordnungssignal möchten.

Werde ich jemals eine doppelte UUID erhalten?

Praktisch nein. Eine v4 UUID hat 122 zufällige Bit, sodass die Wahrscheinlichkeit, dass zwei in einer Charge von einer Milliarde kollidieren, ungefähr 10^-18 beträgt. Sie müssten in der Größenordnung von 2,7 Trillionen v4 UUIDs erzeugen, bevor Sie eine 50 %-Chance auf eine einzige Kollision erreichen. Behandeln Sie eindeutige Erzeugung als gegeben und fügen Sie keine Eindeutigkeitsprüfung hinzu.

Ist v4 kryptografisch zufällig?

Dieses Tool verwendet crypto.randomUUID(), das laut Spezifikation aus einem kryptografisch starken PRNG ziehen muss. Das reicht für Sitzungs-IDs, Idempotenz-Schlüssel und die meisten Sicherheitstoken. Es ist kein Ersatz für einen signierten Token oder ein langes API-Geheimnis, und Sie sollten keine Verschlüsselungsschlüssel aus einer UUID ableiten.

Ist UUID v7 standardisiert?

Ja. UUID v7 ist in RFC 9562 (Mai 2024) definiert, das RFC 4122 ablöste und v6, v7 und v8 neben den ursprünglichen Versionen formalisierte. Die meisten modernen Sprachen haben v7-Implementierungen — Postgres, MySQL und SQL Server akzeptieren alle v7-Werte als UUID-Spalte ohne Änderung.

Wie sieht die Binärform aus und ist Endianness wichtig?

Eine UUID ist 16 Bytes. Die kanonische Textform gruppiert sie als 8-4-4-4-12 Hex-Zeichen. Bytes werden gemäß RFC 9562 in Netzwerk- (big-endian) Reihenfolge geschrieben, daher beginnt 018f8e50-fcaa-7c3c-8d2a-6f5b72e1fd90 mit dem Byte 0x01. Microsoft-GUIDs speichern die ersten drei Gruppen historisch little-endian im Speicher — passen Sie beim Interop mit .NET-Binärdumps auf.

Speichern Sie die UUIDs, die dieses Tool erzeugt?

Nein. Wir speichern die UUIDs, die Sie hier erzeugen, nicht. Jeder Wert wird im Ausgabebereich angezeigt und ist in dem Moment verschwunden, in dem Sie aktualisieren oder den Tab schließen — nichts wird gespeichert, keine Telemetrie zu den Werten wird erfasst. Sie sind herzlich eingeladen, es in den Entwicklertools Ihres Browsers zu überprüfen.