UUID-Generator

Was ist eine UUID (oder GUID)?

Eine UUID (Universally Unique Identifier) ist ein 128-Bit-Wert, den jedes System selbst erzeugen kann, ohne bei einem zentralen Server nach der nächsten Nummer zu fragen. Trotzdem kann das System sicher sein, dass niemand sonst denselben Wert erzeugt. Geschrieben wird sie als 32 Hexadezimalziffern in fünf Gruppen, 8-4-4-4-12, also 36 Zeichen insgesamt:

017f22e2-79b0-7cc3-98c4-dc0c0c07398f

Die erste Ziffer der dritten Gruppe ist die Version (hier 7), die erste Ziffer der vierten Gruppe enthält die Variante, bei Standard-UUIDs also 8, 9, a oder b. Deshalb passt jede v4-UUID auf das Muster xxxxxxxx-xxxx-4xxx-yxxx-xxxxxxxxxxxx.

Der aktuelle Standard ist RFC 9562 vom Mai 2024. Er ersetzt RFC 4122, lässt die Versionen 1 bis 5 unverändert und ergänzt die Versionen 6, 7 und 8 sowie die Max-UUID, bei der alle Bits auf eins stehen.

UUID oder GUID: GUID ist der Name, den Microsoft für dasselbe verwendet. Windows-Tools wie die Registry zeigen GUIDs meist in Großbuchstaben mit geschweiften Klammern, etwa {3F2504E0-4F89-41D3-9A0C-0305E82C3301}, der Wert dahinter ist aber eine normale UUID. (Guid.ToString() in .NET gibt standardmäßig Kleinbuchstaben ohne Klammern aus.) Der einzige praktische Unterschied zeigt sich im Binärformat: Windows speichert die ersten drei Gruppen als Little-Endian, deshalb wirken rohe 16-Byte-GUIDs in anderen Systemen manchmal durcheinandergewürfelt.

UUID-Versionen im Vergleich

Die Version verrät, wie die 128 Bits zustande kommen. Diese sechs Versionen decken fast jeden echten Einsatz ab:

Welche Version du nehmen solltest: v7 für neue Datenbankschlüssel, v4 für zufällige IDs, die nichts preisgeben. Zufällige v4-Schlüssel landen an beliebigen Stellen eines B-Baum-Index, was bei wachsenden Tabellen zu Page Splits und schlechter Cache-Nutzung führt. Ein v7-Schlüssel beginnt mit der Zeit, neue Zeilen werden also nahe am Ende des Index angehängt und liegen dicht bei ihren Nachbarn. Der Preis: Wer eine v7-UUID sieht, kann ablesen, wann sie erstellt wurde.

Version 2 (DCE Security) wird praktisch nie verwendet, und Version 8 ist ein frei belegbares Layout für herstellerspezifische Verfahren. Ein Hinweis zu Datenbanken: SQL Server sortiert uniqueidentifier-Werte ab der letzten Gruppe, dort bringt v7 ohne Zusatzaufwand also keinen Vorteil für den Index.

Wie wahrscheinlich ist eine UUID-Kollision?

Sechs der 128 Bits einer v4-UUID sind durch Version und Variante festgelegt. Bleiben 122 Zufallsbits, also rund 5,3 × 10^36 mögliche Werte. Das Geburtstagsparadoxon macht die Größenordnung greifbar:

• Du brauchst etwa 2,71 Trillionen (2,71 × 10^18) v4-UUIDs für eine 50-prozentige Chance, dass zwei davon gleich sind.
• Bei einer Milliarde UUIDs pro Sekunde würde das etwa 86 Jahre dauern.
• Nach 103 Billionen UUIDs liegt die Chance auf ein einziges Duplikat immer noch bei etwa eins zu einer Milliarde.

Die Rechnung stimmt nur, wenn die Bits wirklich zufällig sind. Duplikate entstehen in der Praxis durch schwache Generatoren wie Code-Schnipsel auf Basis von Math.random, durch Bugs, die einen Wert wiederverwenden, und durch Testdaten, die zwischen Umgebungen kopiert werden. Diese Seite nutzt crypto.randomUUID() und crypto.getRandomValues(), die kryptografisch sichere Zufallsquelle des Browsers. Für v7 folgt sie dem Zählerverfahren aus RFC 9562, sodass auch UUIDs aus derselben Millisekunde eindeutig und in der richtigen Reihenfolge bleiben.

UUIDs im Code erzeugen

Die meisten Sprachen und Datenbanken bringen eine UUID-Funktion mit, für v4 brauchst du also selten eine Bibliothek. Eingebaute v7-Unterstützung ist neuer, prüf also deine Version.

crypto.randomUUID();                      // v4, nur in sicheren Kontexten (HTTPS)
import { randomUUID } from "node:crypto";  // Node.js

import uuid
uuid.uuid4()   # v4
uuid.uuid7()   # v7, ab Python 3.14

SELECT gen_random_uuid();  -- PostgreSQL 13+, v4
SELECT uuidv7();           -- PostgreSQL 18+, v7
SELECT UUID();             -- MySQL, liefert eine UUID der Version 1

Guid.NewGuid();          // C#, v4
Guid.CreateVersion7();   // C#, v7, ab .NET 9
UUID.randomUUID();       // Java, v4

uuidgen                          # zufällige v4; macOS gibt Großbuchstaben aus
uuidgen | tr '[:upper:]' '[:lower:]'

In MySQL speichert UUID_TO_BIN(UUID(), 1) den Wert in 16 Bytes und tauscht die Zeitfelder, damit indizierte v1-Werte besser beieinanderliegen. Für v7 in JavaScript exportiert das Paket uuid auf npm eine Funktion v7().

UUIDs als Testdaten in der QA

UUIDs lösen erstaunlich viele Testprobleme, weil sie eindeutig sind, ohne dass sich Testläufe untereinander abstimmen müssen:

• Eindeutige Fixtures: Häng eine UUID an Benutzernamen, E-Mail-Adressen oder Bestellnummern (zum Beispiel qa+<uuid>@example.com), damit parallele CI-Jobs nie am selben Unique-Constraint scheitern.
• Idempotenzschlüssel: Schick bei einem wiederholten POST dieselbe UUID im Header Idempotency-Key und prüf, dass die Zahlung oder Bestellung nur einmal angelegt wird.
• Korrelations-IDs: Setz eine UUID in einen Request-Header wie X-Request-ID und durchsuch dann die Logs aller Services danach. Kopier die ID in den Bugreport, damit das Entwicklungsteam genau diesen Request findet.
• Testdaten anlegen und aufräumen: Erzeuge 100 IDs als JSON-Array für Fixture-Dateien oder als SQL-Liste IN (…), um genau die Zeilen abzufragen oder zu löschen, die ein Test angelegt hat.
• Grenzfälle für Validatoren: Gib deiner API die Nil-UUID, die Max-UUID, Großbuchstaben, Klammern, fehlende Bindestriche und eine v1, wo eine v4 erwartet wird, und prüf, dass sie jeden Fall bewusst annimmt oder ablehnt.

Wenn ein Test an einem bestimmten Datensatz scheitert, füg dessen ID oben in den Validator ein. Eine v7- oder v1-ID verrät, wann der Datensatz entstanden ist, und grenzt damit oft das Deployment oder den Testlauf ein, der ihn erzeugt hat.