Eine UUID besteht aus 128 Bit, geschrieben als 32 Hex-Ziffern in der vertrauten Form 8-4-4-4-12. Das Versprechen: Du kannst auf jeder Maschine, jederzeit, ohne jemanden zu fragen, eine prägen und trotzdem nie mit einer anderswo geprägten kollidieren. Dieses Tool erzeugt Version 4 — die zufällige.
Version 4 sind 122 Zufallsbits, nicht 128
Sechs der 128 Bit sind vergeben. Vier kodieren die Version, weshalb jede v4-UUID am Anfang der dritten Gruppe eine wörtliche "4" trägt. Zwei weitere kodieren die Variante, weshalb die vierte Gruppe immer mit 8, 9, a oder b beginnt. Alles andere — 122 Bit — ist zufällig.
Das lässt Raum für rund 5,3 × 10³⁶ Werte. Interessant ist eigentlich die Kollisionswahrscheinlichkeit, und die Geburtstagsschranke setzt eine 50-Prozent-Chance auf irgendein Duplikat bei etwa 2,7 × 10¹⁸ UUIDs an. Um dorthin zu kommen, müsstest du rund fünfundachtzig Jahre lang eine Milliarde pro Sekunde erzeugen. Kollidierst du in der Praxis, ist deine Zufallsquelle kaputt — nicht deine Chancen.
Woher der Zufall kommt, zählt mehr als die Version
Dieser Generator nutzt crypto.getRandomValues(), die kryptografisch sichere Zufallsquelle des Browsers. Diese Wahl ist nicht kosmetisch. Die naheliegende Alternative, Math.random(), ist kein CSPRNG: V8 implementiert sie mit xorshift128+, einem Algorithmus für Geschwindigkeit und statistische Qualität, nicht für Unvorhersehbarkeit. Beobachte genug ihrer Ausgaben, und du kannst ihren inneren Zustand rekonstruieren und jeden künftigen Wert vorhersagen.
Für eine UUID, die nur eindeutig sein muss, spielt das keine Rolle. Es spielt eine enorme Rolle, sobald von einer UUID auch Unerratbarkeit erwartet wird — ein Passwort-Reset-Link, eine Einladungs-URL, die "geheime" Freigabe eines Dokuments. Genau dort werden v4-UUIDs als Tokens eingesetzt, und ein auf Math.random gestützter Generator macht sie zu einer Schwachstelle, die kein Test je entdeckt. Wenn du eine Sache von dieser Seite mitnimmst: Prüfe, was deine UUID-Bibliothek verwendet, bevor du ihre Ausgabe als Geheimnis behandelst.
Die Frage nach dem Primärschlüssel
Zufällige UUIDs sind hervorragende Bezeichner und mittelmäßige geclusterte Primärschlüssel — gut zu wissen, bevor man ein Schema festzurrt. Datenbanken halten B-Tree-Indizes sortiert. Autoinkrementierende Ganzzahlen hängen immer an der rechten Seite an, was billig ist. Zufällige v4-UUIDs landen überall, Einfügungen streuen also über den gesamten Index, erzwingen Page-Splits und verschmutzen Seiten im ganzen Buffer Pool.
Am härtesten trifft es MySQL mit InnoDB, wo der Primärschlüssel der geclusterte Index ist: Die Tabelle selbst ist physisch danach geordnet, und jeder Sekundärindex trägt eine Kopie des Primärschlüssels mit. Ein zufälliger 16-Byte-Schlüssel kostet dort doppelt. Genau dieses Problem wurde mit UUID Version 7 standardisiert gelöst: Sie legt einen Millisekunden-Zeitstempel in die hohen Bits, sodass Werte grob nach Erzeugungszeit sortieren und Einfügungen nahe am rechten Rand bleiben — bei genug verbleibendem Zufall, um unerratbar zu bleiben. Willst du UUIDs als Primärschlüssel im großen Stil, sind v7 oder ULID die moderne Antwort. Dieses Tool erzeugt v4, die richtige Wahl für Bezeichner, die nicht zugleich die physische Ordnung deiner Tabelle sind.
Die Formate sind größtenteils kosmetisch
Mit Bindestrichen, ohne, Großschreibung, geschweifte Klammern — alle vier stellen dieselben 128 Bit dar, und jeder vernünftige Parser akzeptiert alle. Der Klammerstil stammt aus Microsofts GUID-Konventionen und begegnet dir in der Windows-Registry und in COM-Schnittstellen. Die bindestrichlose 32-Zeichen-Form ist praktisch, wo Länge zählt, etwa in einem URL-Segment.
Eine Warnung: RFC 9562 schreibt Kleinschreibung für die Ausgabe vor, während Parser beide Schreibweisen bei der Eingabe akzeptieren müssen. Speicherst du UUIDs als Zeichenketten statt als nativen 16-Byte-Typ, können uneinheitliche Groß-/Kleinschreibungen zwei Zeilen erzeugen, die dieselbe UUID sind und beim Vergleich doch nicht gleich. Ein selbstverschuldeter Fehler — Normalisieren auf Kleinschreibung beim Eintragen verhindert ihn.
Häufige Fragen
Werden die UUIDs auf einem Server erzeugt?
Nein. Dieses Tool ist als "client" gekennzeichnet: Jeder Wert entsteht in deinem Browser-Tab aus dessen eigener Zufallsquelle, nichts wird übertragen. Das ist zugleich die ehrliche Antwort darauf, ob sie nur dir gehören — hier hat niemand eine Aufzeichnung davon, wir eingeschlossen.
Können zwei v4-UUIDs jemals gleich sein?
Mathematisch ja, praktisch nein — mit einem großen Sternchen. Die Chancen sind nur dann vernachlässigbar, wenn der zugrundeliegende Zufall solide ist. Reale Vorfälle mit doppelten UUIDs lassen sich fast immer auf eine kaputte Quelle zurückführen: ein PRNG mit festem Seed, eine samt Entropiepool geklonte virtuelle Maschine, oder ein eingebettetes Gerät, das Schlüssel erzeugt, bevor es Entropie gesammelt hat. Das Risiko ist nicht die Mathematik, sondern die Zufallsquelle.
Ist eine v4-UUID als geheimes Token sicher?
Stammt sie aus einer kryptografisch sicheren Quelle, sind 122 Zufallsbits reichlich — bequem mehr als ein typisches 128-Bit-Sitzungstoken. Die Bedingung ist allerdings die ganze Antwort. Prüfe, ob dein Generator crypto.getRandomValues oder das Plattform-Äquivalent statt Math.random nutzt, und nimm nie an, eine Bibliothek habe das richtig gemacht, nur weil ihre Ausgabe zufällig aussieht.
Soll ich eine UUID oder eine autoinkrementierende Ganzzahl nehmen?
Ganzzahlen sind kleiner, schneller zu indizieren und sortieren natürlich. UUIDs erlauben es, Bezeichner ohne Rundreise zur Datenbank zu erzeugen, Datensätze aus verschiedenen Systemen ohne Neunummerierung zusammenzuführen und nicht zu verraten, wie viele Datensätze du hast — eine fortlaufende ID in einer URL erzählt jedem deine Bestellzahl. Viele Schemata haben am Ende beides: einen internen Ganzzahlschlüssel für die Datenbank und eine UUID für die Außenwelt.
Warum beginnt die dritte Gruppe immer mit 4?
Dieses Nibble ist das Versionsfeld, und 4 bedeutet "aus Zufallszahlen erzeugt". Es ist selbst nicht zufällig — es ist eine Kennzeichnung. Daran erkennt ein Parser, dass er den Rest als v4 zu deuten hat und nicht als v1-Zeitstempel oder v5-Hash. Erzeugst du hier 2000 davon, haben alle 2000 sie.