UUID-Generator

Erzeuge UUID-v4-Kennungen (zufällig) in großer Zahl direkt im Browser. Unterstützt mehrere Anzeigeformate: Standard, Großbuchstaben, ohne Bindestriche, mit geschweiften Klammern und URN.

UUID-Versionen im Überblick

Version Basiert auf Beschreibung
UUID v1 Zeitstempel + MAC-Adresse Wird aus dem Erstellungszeitpunkt und der MAC-Adresse der Netzwerkkarte erzeugt. Kann das erzeugende Gerät verraten, was Datenschutzbedenken aufwirft — für neue Systeme daher heute selten gewählt.
UUID v3 Namespace + MD5-Hash Wird durch MD5-Hashing eines Namespace und einer Namenszeichenfolge erzeugt. Deterministisch — dieselbe Eingabe liefert immer dieselbe UUID. Wegen bekannter MD5-Kollisionsschwächen wird für neue Anwendungen v5 empfohlen.
UUID v4 Vollständig zufällig Wird aus einer kryptografisch sicheren Zufallsquelle erzeugt. Verrät keine Informationen über den Ursprung und ist einfach zu implementieren — die am weitesten verbreitete Variante. Dieses Tool erzeugt genau dieses Format.
UUID v5 Namespace + SHA-1-Hash Gleicher namespacebasierter Ansatz wie v3, verwendet aber SHA-1. Empfohlen, wenn eine deterministische Erzeugung benötigt wird — also dieselbe ID immer wieder aus denselben Daten reproduzieren zu können.
UUID v6 Neu geordneter Zeitstempel + Zufall Standardisiert in RFC 9562 (2024). Ordnet die Zeitstempelfelder von v1 so um, dass die lexikografische Byte-Reihenfolge der chronologischen Reihenfolge entspricht, was die Effizienz von Datenbankindizes verbessert.
UUID v7 Unix-Zeitstempel + Zufall Standardisiert in RFC 9562 (2024). Beginnt mit einem Unix-Zeitstempel in Millisekundengenauigkeit, sodass sich IDs nach Erstellungszeitpunkt sortieren lassen. Wird in neuen Projekten zunehmend als Ersatz für v4 eingesetzt.

Tipps

  • Jede UUID wird vollständig im Browser über die Web Crypto API erzeugt — es wird nichts an die Server von toolbase.cc gesendet.
  • UUID v4 ist die naheliegende Wahl, wann immer Eindeutigkeit ohne fortlaufende, erratbare IDs gebraucht wird — Datenbank-Primärschlüssel, API-Request-IDs und mehr.
  • Da 122 der 128 Bits von UUID v4 zufällig sind, ist die Wahrscheinlichkeit einer Kollision astronomisch gering — man müsste rund 2,7×10¹⁸ UUIDs erzeugen, bevor die Kollisionswahrscheinlichkeit überhaupt etwa 50 % erreicht.
  • Das Format "ohne Bindestriche" ist praktisch für URL-Pfadsegmente oder Dateinamen. Das Format "mit geschweiften Klammern" entspricht der GUID-Schreibweise, die in Windows COM/Registry verwendet wird.
  • Erhöhe die Anzahl und nutze "Alle kopieren", um schnell Seed-Daten oder Testdatensätze im großen Umfang zu erzeugen.

Häufig gestellte Fragen

Theoretisch nicht ausgeschlossen, aber mit 122 Bit Zufälligkeit ist das Kollisionsrisiko von UUID v4 für jeden praktischen Zweck vernachlässigbar. Selbst wenn man hundert Jahre lang jede Sekunde eine Milliarde UUIDs erzeugen würde, läge die Wahrscheinlichkeit einer einzigen Kollision erst bei rund 50 %.

Ja, im Wesentlichen dasselbe Konzept. GUID (Globally Unique Identifier) ist Microsofts Bezeichnung für die eigene Implementierung und kompatibel mit dem 128-Bit-UUID-Format. Die Klammernotation {xxxxxxxx-xxxx-...} ist die übliche GUID-Schreibweise in Windows COM und der Registry.

Da UUID v4 zufällig ist, entstehen im Vergleich zu fortlaufenden Ganzzahlen (AUTO_INCREMENT) oft größere Indizes und langsamere Einfügevorgänge. Wenn Einfügungen nach Erstellungszeitpunkt sortiert bleiben sollen, lohnt sich ein Blick auf UUID v7 (mit eingebettetem Zeitstempel) oder alternativ ULID.

Wenn nur Eindeutigkeit gebraucht wird, ist UUID v4 die einfachste und sicherste Wahl. Nutze v5, wenn dieselbe ID immer wieder aus derselben Eingabe reproduzierbar sein muss. Für neue Projekte, denen Sortierreihenfolge oder Effizienz bei Datenbankeinfügungen wichtig ist, ist v7 eine starke Option. v1 und v3 werden heute kaum noch neu eingesetzt.
ツールくん

Übrigens – Warum 128 Bit?

Die UUID wurde in den 1980er-Jahren von Apollo Computer für verteilte Systeme entwickelt und später von der OSF (Open Software Foundation) als Teil von DCE (Distributed Computing Environment) standardisiert. Die aktuelle Spezifikation findet sich in IETF RFC 4122 (2005), mit einer erweiterten Fassung, RFC 9562, die 2024 veröffentlicht wurde.

128 Bit mögen übertrieben wirken, doch genau diese Länge erlaubt es mehreren Servern oder Geräten, IDs völlig unabhängig voneinander, ohne jede Abstimmung, zu vergeben und dabei in der Praxis trotzdem Kollisionen zu vermeiden. Ein zentraler ID-Server, der fortlaufende Nummern vergibt, umgeht diesen Zufall, wird aber selbst zum Single Point of Failure und benötigt für jede ID eine Kommunikationsrunde. UUIDs eliminieren diese Koordinationskosten vollständig — zum Preis von genügend Zufälligkeit, um die Kollisionswahrscheinlichkeit vernachlässigbar zu machen.

Genau diese Zufälligkeit ist auch die Achillesferse von UUID v4: Werden zufällige Werte in einen B-Tree-artigen Datenbankindex eingefügt, verteilen sich die Einfügepunkte, was häufige Seitensplits verursacht und die Performance beeinträchtigt. UUID v7 wurde genau dafür entwickelt — durch einen führenden Unix-Zeitstempel bleibt die Sortierung nach Erstellungszeitpunkt erhalten, während genügend Zufälligkeit vorhanden ist, um Vorhersagbarkeit zu vermeiden, was Einfügungen eine deutlich bessere Lokalität verschafft.

Weitere Tools in dieser Kategorie