AWS-Cron-Generator
Cron-Generator
Textzähler
JSON in CSV umwandeln
CSV in JSON umwandeln
Unix-Zeitstempel umrechnen
UUID-v4- und v7-Generator
JSON in TypeScript umwandeln
Markdown in PDF
Base64
Bilder
JSON
QR-Code
Passwörter
Einheiten
Hash
Farben
PDF-Tools
PDF-Editor
URL-Encoder
Groß-/Kleinschreibung-Konverter
Lorem Ipsum
Regex-Tester
JWT-Decoder
Textdiff
SVG-Optimierer
EXIF-Viewer
Farbextraktor
Favicon-Generator
Universeller Konverter
Stundenkonverter
PDF-Splitter
Bilder in PDF
PDF zu Bild
Hintergrund Entferner
Zurück zum BlogUTILX / Notizen & Anleitungen

UUID v4 und v7: erzeugen, prüfen und das Format wählen

UUID-v4- und v7-Kennungen im Vergleich

UUIDs ermöglichen unabhängigen Systemen, 128-Bit-Kennungen ohne zentralen Zähler zu erzeugen. Das hilft offline, zwischen Diensten oder vor einem Datenbankeintrag. Eine Kennung wird dadurch weder geheim noch weltweit nachweislich einmalig und bestätigt auch nicht den zugehörigen Datensatz.

Diese Anleitung nutzt den UUID-Generator und -Prüfer mit festen RFC-Beispielen und kleinen Batches. Sie trennt zufälliges v4 von zeitgeordnetem v7, erklärt NIL und MAX und vermeidet erfundene Garantien.

Ein Format für das System wählen

UUIDv4 belegt die nicht für Version und Variante reservierten Bits mit zufälligen oder pseudozufälligen Daten. Das Format ist breit unterstützt und enthält kein definiertes Erstellungsdatum. UUIDv7 legt Unix-Epochenmillisekunden in die höchsten 48 Bits und nutzt die übrigen verfügbaren Bits für Zufall und optionale monotone Verfahren. Seine Bytefolge folgt der Erstellungszeit natürlicher.

Entscheide anhand von Kompatibilität, Sortierbedarf und verfügbaren Bibliotheken. Behaupte nicht, v7 mache jede Datenbank schneller: Speicherform, Index, Last, Generator und Datenbank beeinflussen das Ergebnis. v4 ist wegen seiner Undurchsichtigkeit auch kein Geheimnis. Beide Werte können öffentlich sein.

Feste Werte zur Prüfung

Verwende unverändert:

550e8400-e29b-41d4-a716-446655440000
017f22e2-79b0-7cc3-98c4-dc0c0c07398f
00000000-0000-0000-0000-000000000000
ffffffff-ffff-ffff-ffff-ffffffffffff

Der erste Wert ist gültiges v4, der zweite v7. Der dritte ist die besondere NIL-UUID, der vierte MAX. Beide Sonderformen sind gültig, melden aber keine normale Version. Ersetze das letzte Zeichen des v4-Beispiels durch z; die Prüfung muss scheitern, weil die Textdarstellung nur Hexadezimalzeichen erlaubt.

Erzeugte Werte sind absichtlich nicht fest. Generiere drei v7-Werte: Alle müssen als Version 7 gelten, ihr Text ist nicht vorhersagbar. Wiederhole mit v4 und vergleiche die Version, nicht einen Snapshot.

Einen kleinen Batch erzeugen und prüfen

Wähle v4, Anzahl drei und „Erzeugen“. Bestätige drei Zeilen, kopiere den Batch und prüfe jede einzeln. Wiederhole mit v7. Bewahre die Erzeugungsreihenfolge auf, wenn du das Sortierverhalten deines Speichers testest, und vergleiche stets dieselbe binäre oder kanonische Textdarstellung.

Füge jeden festen Wert in den unabhängigen Prüfer ein. Notiere Gültigkeit, Version und Sonderstatus. Teste danach 550e8400-e29b-41d4-a716-44665544000z. Ein Formatfehler sagt nichts darüber, ob ein gültiger Wert in einer Datenbank existiert.

Für einen größeren Batch sind 1 bis 1.000 erlaubt. Lade .txt herunter und zähle nichtleere Zeilen. Die Grenze verhindert versehentlich schwere Browserausgaben; sie empfiehlt keine Reservierung von Tausenderblöcken. Erzeuge Produktionswerte am architektonisch richtigen Ort mit derselben vertrauenswürdigen Bibliothek.

Bits lesen, ohne zu viel abzuleiten

RFC 9562 definiert die kanonische 8-4-4-4-12-Gruppierung, Variante und vier Versionbits. Bei v4 ist das Versionsnibble 4; bei v7 ist es 7, und die ersten 48 Bits enthalten Unix-Millisekunden. Die verbleibenden 74 Bits außerhalb von Version und Variante bestehen aus Zufall oder einer festgelegten Kombination zur besseren Monotonie innerhalb einer Millisekunde.

Der Generator verwendet eine gepflegte UUID-Bibliothek und kryptografische Zufallsquelle der Umgebung, nicht Math.random. Fehlt sichere Kryptografie, schlägt er fehl. Die Prüfung kontrolliert Syntax, Variante, Version und Sonderwerte; ein zentrales Verzeichnis fragt sie nicht ab.

NIL besteht vollständig aus Nullbits, MAX aus Einsbits. Sie können definierte Sentinels sein. Lege im Schema fest, ob sie verboten, reserviert oder bedeutungstragend sind, statt lokale Bedeutungen still einzuführen.

Was eine gültige UUID nicht beweist

Ungültige Eingaben haben oft falsche Länge, versetzte Bindestriche, Nicht-Hex-Zeichen, unbekannte Variante oder Version. Verwende kanonischen Text ohne Klammern oder Präfixe, sofern der Vertrag nichts anderes vorsieht. Äußere Leerzeichen entfernen ist nicht dasselbe wie den Wert ändern.

„Gültig“ beweist weder Existenz, Eigentum, Alter, Datenbank-Eindeutigkeit noch Berechtigung. Prüfe Existenz im richtigen Speicher und erzwinge einen eindeutigen Index, wenn Kollisionen schaden. Behandle Einfügekonflikte auch bei extrem kleiner Wahrscheinlichkeit. Am Bitmuster ist außerdem nicht erkennbar, ob v4 wirklich sicher erzeugt wurde.

Fehlt sichere Kryptografie, nutze einen unterstützten Browser statt selbst gebauter Zufallszeichen. Korrigiere nichtganzzahlige Anzahlen oder Werte außerhalb 1 bis 1.000; schneide einen zu großen Batch nicht still ab.

Die Kennungsrichtlinie gestalten

Speichere UUIDs einheitlich als kanonischen Text oder 16 Bytes passend zu Datenbank und Treiber. Unterschiedliche Byteordnungen verändern Vergleich und Sortierung. Protokolle dürfen Groß- und Kleinschreibung akzeptieren, aber Logs und APIs sollten eine kanonische Form ausgeben.

Nutze UUIDs nie als Passwort, API-Schlüssel, Bearer-Token oder Zugriffsbeweis. v7 verrät ungefähr die Erstellungszeit; die Undurchsichtigkeit von v4 ist keine Authentifizierung. Geheimnisse benötigen eigene Entropie und Berechtigungsprüfung.

Bei öffentlichen URLs bleiben Zugriffskontrolle, Rate Limits und vorsichtige Antworten erforderlich. Prüfe, ob zeitliche Ordnung Informationen offenlegt. Eine UUID statt eines Geheimnisses macht ein Log nicht automatisch unbedenklich. Definiere außerdem begrenzte Konfliktwiederholungen, statt bei einem Fehler endlos neu zu erzeugen.

Grenzen von Generator und Prüfer

Unterstützt werden v4- und v7-Batches von 1 bis 1.000 sowie Textprüfung einschließlich NIL und MAX. Das Werkzeug erzeugt nicht alle Versionen, reserviert nichts, prüft keine Datenbank und verspricht keine globale Einmaligkeit. Konsistenzregeln bleiben Aufgabe der Anwendung.

Zeitordnung von v7 ist keine vollständige Ereignisordnung über Rechner hinweg. Uhren können springen, mehrere Werte teilen eine Millisekunde und Implementierungen nutzen unterschiedliche Monotonieverfahren. Eine UUID ist auch keine Zeitstempel-API; extrahiere Zeit nur, wenn dein Protokoll dieses Feld ausdrücklich verwendet. Indexleistung muss mit realer Datenbank, Last und Speicherform gemessen werden.

Abschließende UUID-Prüfung

Wähle v4 oder v7 aus einer ausdrücklichen Kompatibilitäts- und Sortieranforderung. Nutze gepflegte Bibliothek und sichere Kryptografie. Speichere eine Darstellung, erzwinge notwendige Eindeutigkeit und trenne Identifikation von Authentifizierung.

Prüfe die festen v4- und v7-Werte, erkenne NIL und MAX und lehne den Wert mit z ab. Bei Batches zählen Anzahl und Version, nicht erwarteter Text. Teste Einfügen, Konflikt, Serialisierung und Sortierung mit dem tatsächlichen Treiber. Kontrolliere, dass Kopie und Download genau eine UUID je Zeile ohne unsichtbare Zusätze enthalten.

Dokumentiere Bibliotheksversion, Laufzeit und Speicherform. Bei einer Migration von v4 auf v7 müssen historische Kennungen unverändert gültig bleiben. Prüfe gemischte Datensätze, Fremdschlüssel, Exporte und Backups, bevor du den Standard umstellst. Die Version wird aus dem Wert erkannt, nicht aus dem Erstellungsdatum.

Teste die Eindeutigkeitsbedingung der Datenbank mit einer absichtlich wiederholten gültigen UUID. Der zweite Eintrag muss gemäß Konfliktregel scheitern, obwohl der Prüfer beide Texte als gültig meldet. Das macht den Unterschied zwischen Formatvalidierung und fachlicher Eindeutigkeit konkret.

Für Sortiertests erzeuge v7-Werte zu mehreren Zeitpunkten und bewahre die Reihenfolge. Vergleiche kanonischen Text und die binäre Darstellung des Treibers. Ziehe keine Leistungsfolgerung aus wenigen Werten: nutze repräsentative Last, Indexstruktur und Messmethode. Das Zeitfeld unterstützt Ordnung, garantiert aber keine globale Ereignisfolge.

Lege bei öffentlichen APIs bewusst fest, ob Fehlermeldungen ungültiges Format und nicht vorhandenen Datensatz unterscheiden. Zu genaue Antworten können Enumeration erleichtern; zu ungenaue erschweren interne Diagnose. Externes Verhalten und internes Logging benötigen getrennte Regeln, und keine UUID darf als Berechtigungsnachweis dienen.

Prüfe Exporte und Importe auf unveränderte Bindestriche, Groß-/Kleinschreibung und Byteordnung. Ein Tabellenprogramm darf eine UUID nicht numerisch interpretieren oder wissenschaftlich formatieren. Verwende in CSV eine Textspalte und beim Datenbankimport den nativen UUID-Typ oder eine geprüfte 16-Byte-Abbildung. Vergleiche nach einem Roundtrip den kanonischen Wert Zeichen für Zeichen.

Für NIL und MAX braucht das Schema eine ausdrückliche Regel. Wenn NIL „nicht gesetzt“ bedeutet, entscheide, ob null fachlich klarer wäre. Wenn MAX eine obere Grenze darstellt, verhindere, dass gewöhnliche Erzeugung diesen Sonderwert erwartet. Der Prüfer erkennt beide, weist ihnen aber keine anwendungsspezifische Bedeutung zu.

Bei gleichzeitiger Erzeugung vieler v7-Werte innerhalb derselben Millisekunde hängt die feinere Ordnung von der Bibliotheksstrategie ab. Verlasse dich nicht auf eine selbst erfundene Interpretation der Zufallsbits. Wenn ein vollständiger Ereignisrang nötig ist, ergänze Sequenz, Transaktionsordnung oder serverseitige Zeit und dokumentiere die Konfliktregel.

Quellen: RFC 9562: UUIDs, Dokumentation des uuid-Pakets und Web Cryptography API.