# UUID-Generator — Tipps & Tricks > Strategie und Stolperfallen rund um UUIDs: wann v4 oder v7, Kollisionssicherheit, v5-Determinismus, sicherer Zufall, NIL als Null-Wert und Tool-Kombination. Source: https://www.jpkc.com/db/tools/uuid/tips/ Zurück zur Übersicht: [UUID-Generator](https://www.jpkc.com/db/tools/uuid/) · Tool live öffnen: [www.jpkc.com/tools/uuid/](https://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](https://www.jpkc.com/db/tools/uuid/manual/). ## v4 oder v7? Die wichtigste Wahl Für die meisten Fälle reicht **v4** — rein zufällig, ohne Nebenwirkungen, und im Tab nicht umsonst mit „Best for most use cases" beschrieben. 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 und macht UUIDs grob nach Erzeugungszeit sortierbar. 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](https://www.jpkc.com/db/tools/uuid/manual/#version-1-zeitbasiert-v1-time-based)) — ein häufiger Privacy-Vorbehalt gegen v1 entfällt hier also. Trotzdem bietet **v7** dieselbe Zeit-Sortierbarkeit moderner und einfacher. Greife zu v1 vor allem dann, 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. - Hinweis: Das Tool bietet v5 (SHA-1), aber **kein** v3 (MD5). Für namensbasierte UUIDs ist v5 ohnehin die empfohlene Wahl. ## 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 1000) und kopiere den ganzen Block — eine UUID pro Zeile. Das spart das wiederholte Klicken und passt direkt in SQL-`INSERT`-Listen, Seed-Skripte oder Fixture-Dateien. v5 hat bewusst keine Mengenauswahl, weil dieselbe Eingabe ohnehin immer denselben Wert ergäbe. ## Die NIL-UUID als bewusster Null-Wert 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. Sie liegt im Fuß der Karte zum Direkt-Kopieren bereit. Eine MAX-UUID bietet das Tool nicht; rechne also nicht damit. ## Format prüfen, bevor du es weitergibst Die Ausgabe ist immer das kanonische Format: **Kleinschreibung**, mit Bindestrichen, `8-4-4-4-12`. Manche Systeme erwarten Großschreibung oder geschweifte Klammern (`{…}`, vor allem im Microsoft-/GUID-Umfeld). Das Tool wandelt das nicht um — das Ergebnisfeld ist aber editierbar, und für größere Mengen formatierst du nachträglich (z. B. mit dem Such-und-Ersetzen deines Editors). Erwarte hier keine eingebauten Format-Optionen. ## Alles bleibt im Browser Der UUID-Generator macht **keinen** Server-Aufruf — Namen, Namespaces und erzeugte UUIDs verlassen deinen Browser nicht. Du kannst das Tool also bedenkenlos auch mit fachlichen Namen (z. B. internen Kennungen) für v5 füttern. Voraussetzung ist nur ein **HTTPS**-Kontext, weil die Web-Crypto-API genutzt wird. ## Kombination mit anderen JPKCom-Tools - **[Hash-Generator](https://www.jpkc.com/db/tools/hash/)** — 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-Ableitung hinter v5. - **[Passwort- & Schlüssel-Generator](https://www.jpkc.com/db/tools/generator/)** — für frei wählbare Zufalls-Tokens und Passwörter jenseits des starren UUID-Formats. - **[Cryptor (AES-256)](https://www.jpkc.com/db/tools/cryptor/)** — eine erzeugte UUID als Identifikator nutzen und den zugehörigen Inhalt clientseitig verschlüsseln. --- Die vollständige Funktionsbeschreibung steht im [Manual](https://www.jpkc.com/db/tools/uuid/manual/), konkrete Durchläufe in den [Beispielen](https://www.jpkc.com/db/tools/uuid/examples/). Ausprobieren kannst du alles im [Tool](https://www.jpkc.com/tools/uuid/).