UUID-Generator — Tipps & Tricks

Zurück zur Übersicht: UUID-Generator · Tool live öffnen: www.jpkc.com/tools/uuid/

Eine UUID ist schnell erzeugt — die richtige Version zu wählen, ist die eigentliche Entscheidung. Diese Seite sammelt, worauf es in der Praxis ankommt. Die technischen Grundlagen dazu stehen im Manual.

v4 oder v7? Die wichtigste Wahl

Für die meisten Fälle reicht v4 — rein zufällig, ohne Nebenwirkungen; der Tab nennt es „the usual choice when the ID does not need to sort". Sobald die UUID aber als Datenbank-Primärschlüssel dient, lohnt ein zweiter Blick:

v4 (zufällig) streut neue Schlüssel über den gesamten Wertebereich. Bei B-Tree-Indizes (z. B. in MySQL/InnoDB) führt das zu zufälligen Einfügepunkten und schlechterer Cache-Lokalität.
v7 (zeitsortiert) trägt vorne einen Zeitstempel; neue Werte hängen sich ans Index-Ende an. Das ist freundlicher zu Indizes. Weil das Tool v7 monoton erzeugt, bleibt sogar ein Stapel aus derselben Millisekunde in Erzeugungsreihenfolge — wichtig, wenn du einen ganzen Block für einen Import erzeugst und die Reihenfolge später über eine Sortierung nach der UUID wiederfinden willst.

Faustregel: v7 für neue Datenbank-Schlüssel, v4 für alles andere (Tokens, Korrelations-IDs, Dateinamen, API-Schlüssel-Bestandteile).

v1 ist meist nicht mehr nötig

v1 ist die klassische zeitbasierte Variante. Dieses Tool erzeugt den Node-Teil zufällig und gibt damit keine MAC-Adresse preis (siehe Manual) — ein häufiger Privacy-Vorbehalt gegen v1 entfällt hier also. Sein Nachteil bleibt: v1 legt die niederwertigen Zeitbits nach vorne und sortiert deshalb nicht nach Zeit. Brauchst du den Gregorianischen Zeitstempel samt Clock-Sequence und Node, nimm v6 — gleiche Felder, aber sortierbar; im Tab v6 / v1 Time-based ist v6 bereits voreingestellt. Ohne solche Vorgaben ist v7 die modernere und einfachere Wahl. Greife zu v1 nur, wenn ein bestehendes System oder eine Spezifikation es ausdrücklich verlangt.

v5 ist deterministisch — Fluch und Segen

v5 erzeugt keine zufällige, sondern eine reproduzierbare UUID: gleicher Namespace plus gleicher Name ergibt immer denselben Wert. Das ist mächtig — und hat Konsequenzen:

Vorteil: Du kannst stabile Schlüssel aus vorhandenen Namen ableiten (Domains, URLs, fachliche Schlüssel), ohne sie zu speichern. Zweimal dieselbe Eingabe, zweimal dieselbe UUID.
Stolperfalle 1: v5 ist kein Geheimnis. Wer Namespace und Name kennt, kann die UUID nachrechnen. Nutze v5 nie als unrätbares Token — dafür ist v4 da.
Stolperfalle 2: Der Namespace ändert das Ergebnis vollständig. Lege pro Anwendungsfall einen festen Namespace fest und halte ihn stabil, sonst kollidieren deine Ableitungen nicht — sie werden schlicht inkompatibel.
Stolperfalle 3: Der Name zählt byte-genau. Ein Leerzeichen am Rand, ein Tab aus einer kopierten Tabellenzelle oder eine andere Groß-/Kleinschreibung ergibt eine andere UUID. Das Tool schneidet bewusst nichts ab — so stimmen die Ergebnisse mit anderen Implementierungen überein — und warnt dich stattdessen mit einem gelben Hinweis samt Zeilennummer. Normalisiere deine Namen also vorher selbst (etwa Domains immer kleingeschrieben).
v5 oder v3? Beide sind deterministisch; v5 hasht mit SHA-1, v3 mit MD5. Nimm für Neues immer v5 und schalte nur dann auf v3 (MD5) um, wenn ein bestehendes System v3-Werte erwartet — die beiden Versionen liefern für dieselbe Eingabe verschiedene UUIDs.

Kollisionssicherheit — wie eindeutig ist „unique"?

UUIDs garantieren keine mathematische Einmaligkeit, sondern eine praktisch verschwindende Kollisionswahrscheinlichkeit. Bei v4 sind 122 Bit zufällig — du müsstest viele Milliarden UUIDs erzeugen, bevor eine Kollision auch nur statistisch ins Gewicht fiele. Entscheidend dafür ist ein guter Zufall: Dieses Tool nutzt den kryptografisch sicheren Generator des Browsers (crypto.getRandomValues bzw. crypto.randomUUID), nicht Math.random — die Werte sind also weder vorhersagbar noch verzerrt. v5 ist dagegen nur so eindeutig wie die Kombination aus Namespace und Name eindeutig ist; doppelte Eingaben liefern bewusst dieselbe UUID.

Massen-Erzeugung clever nutzen

Brauchst du viele Schlüssel auf einmal, stell Number of UUIDs hoch (bis 10.000) und übernimm den ganzen Block — eine UUID pro Zeile. Ab einigen Hundert Zeilen ist Download as .txt praktischer als die Zwischenablage: Die Datei uuids.txt liest du direkt in Seed-Skripte, Fixture-Dateien oder INSERT-Listen ein.

Bei v5/v3 gibt es keine Mengenauswahl, weil dieselbe Eingabe ohnehin immer denselben Wert ergäbe — dafür nimmt das Feld Names — one per line beliebig viele Namen auf. Weil jede Zeile genau eine UUID in derselben Reihenfolge liefert, kannst du eine Spalte aus der Tabellenkalkulation einfügen und das Ergebnis Zeile für Zeile daneben zurückkopieren. Achte dabei auf Leerzeilen: Auch sie ergeben eine UUID (für den leeren Namen). Die Zuordnung bleibt so zwar erhalten, diese Werte solltest du aber nicht als echte IDs übernehmen.

NIL- und Max-UUID als bewusste Sonderwerte

Die NIL-UUID (00000000-0000-0000-0000-000000000000) ist kein „Fehler", sondern ein definierter Null-Wert. Nutze sie als Platzhalter oder Default, wo ein Schema eine UUID verlangt, aber „noch keine" gemeint ist — sauberer als ein leeres Feld oder eine selbst ausgedachte Konstante. Ihr Gegenstück ist die Max-UUID (ffffffff-ffff-ffff-ffff-ffffffffffff), die RFC 9562 als oberen Grenzwert definiert — nützlich etwa als Obergrenze einer Bereichsabfrage. Beide liegen im Fuß der Karte zum Direkt-Kopieren bereit, und zwar im gerade gewählten Ausgabeformat.

Format prüfen, bevor du es weitergibst

Voreingestellt ist das kanonische Format: Kleinschreibung, mit Bindestrichen, 8-4-4-4-12. Manche Systeme erwarten Großschreibung, geschweifte Klammern ({…}, vor allem im Microsoft-/GUID-Umfeld), das URN-Präfix urn:uuid:, 32 Zeichen ohne Bindestriche oder eine kompakte Base64-Form. All das stellst du im Fuß der Karte unter Output format ein — die bereits erzeugten UUIDs schalten sofort um, ohne neu zu entstehen, und Copy sowie Download as .txt übernehmen genau das angezeigte Format.

Zwei Dinge solltest du dabei im Blick behalten:

Das Format bleibt gespeichert. Wer gestern auf Base64 umgestellt hat, bekommt heute wieder Base64 — kontrolliere die Auswahl, bevor du Werte in ein Schema mit fester Länge kopierst.
Base64url (22 Zeichen, ohne Padding) eignet sich für URLs und Dateinamen, wird von anderen Systemen aber nicht automatisch als UUID erkannt. Speichere in Datenbanken besser die kanonische Form oder die 16 Rohbytes und nutze die kurze Form nur nach außen.

Umgekehrt nimmt der Tab Decode jede dieser Schreibweisen wieder entgegen und zeigt die kanonische Form — praktisch, um eine Base64-ID aus einer URL zurückzuverfolgen.

Zeitstempel stecken drin — der Decoder zeigt sie

v7-, v6- und v1-UUIDs tragen ihren Erzeugungszeitpunkt offen in sich. Der Tab Decode liest ihn sofort aus, in UTC und in deiner lokalen Zeit. Das ist nützlich, etwa um bei einem Datensatz ohne created_at-Spalte das Anlagedatum zu rekonstruieren oder die Reihenfolge von Log-Einträgen zu prüfen. Es bedeutet aber auch: Wer eine solche UUID sieht, weiß, wann der Datensatz entstand. Für öffentlich sichtbare IDs, bei denen das niemanden etwas angeht — Einladungslinks, Bestell- oder Kundennummern —, ist v4 die bessere Wahl.

Der Decoder hilft auch beim Aufräumen: Füge eine Liste unbekannter IDs ein (bis zu 200 Zeilen), und du siehst sofort, welche Version und Variante jede hat — und welche Zeile gar keine gültige UUID ist. Taucht bei einer ID eine ungewöhnliche Version oder Variante auf, prüf ihre Länge: Genau 22 Zeichen liest der Decoder als Base64, eine abgeschnittene UUID erscheint dann als scheinbar gültiger, aber falscher Wert.

Alles bleibt im Browser

Der UUID-Generator macht keinen Server-Aufruf — Namen, Namespaces, erzeugte und decodierte UUIDs verlassen deinen Browser nicht. Du kannst das Tool also bedenkenlos auch mit fachlichen Namen (z. B. internen Kennungen) für v5 füttern oder IDs aus Produktionsdaten decodieren. Gespeichert wird nur das gewählte Ausgabeformat im localStorage. Voraussetzung für v5 ist ein HTTPS-Kontext, weil dafür die Web-Crypto-API genutzt wird.

Kombination mit anderen JPKCom-Tools

Hash-Generator — wenn du keinen 128-Bit-Bezeichner, sondern eine vollständige Prüfsumme (SHA-256, SHA-512 …) über einen Inhalt brauchst; verwandt mit der SHA-1- bzw. MD5-Ableitung hinter v5 und v3.
Time Converter — die Zeit, die der Decoder aus v7, v6 oder v1 ausliest, in andere Zeitzonen oder Unix-Timestamps umrechnen.
Passwort- & Schlüssel-Generator — für frei wählbare Zufalls-Tokens und Passwörter jenseits des starren UUID-Formats.
Cryptor (AES-256) — eine erzeugte UUID als Identifikator nutzen und den zugehörigen Inhalt clientseitig verschlüsseln.

Die vollständige Funktionsbeschreibung steht im Manual, konkrete Durchläufe in den Beispielen. Ausprobieren kannst du alles im Tool.