UUID-Generator
Erzeugen Sie UUIDs — zufällige v4 oder zeitlich geordnete v7 — einzeln oder im Stapel.
122 Zufallsbits. Verrät nichts über den Entstehungszeitpunkt.
Wird erzeugt…
Was ein UUID ist und warum es ihn gibt
Ein UUID — Universally Unique Identifier, in der Microsoft-Dokumentation GUID genannt — ist ein 128-Bit-Wert, geschrieben als 32 Hexadezimalziffern in der vertrauten Gruppierung 8-4-4-4-12. Sein ganzer Zweck ist es, getrennten Systemen zu erlauben, Bezeichner unabhängig voneinander zu prägen, ganz ohne Absprache, und sich dennoch darauf zu verlassen, dass nichts kollidiert. Genau das unterscheidet ihn von einer Auto-Increment-Spalte: zwei Server, zwei mobile Clients offline im Flugzeug und ein Hintergrundjob können alle im selben Moment Datensätze anlegen, ohne irgendwen um Erlaubnis zu fragen.
Eindeutigkeit ist hier wahrscheinlichkeitsbasiert, nicht garantiert. Version 4 überlässt 122 Bit dem Zufall — ein Raum, der groß genug ist, dass selbst nach Milliarden erzeugter Werte die Wahrscheinlichkeit einer Wiederholung weit unter der liegt, dass eine Festplatte die Daten stillschweigend beschädigt. In der Praxis dürfen Sie ihn als eindeutig behandeln; die Mathematik ist nicht das schwache Glied.
Version 4 gegen Version 7 — die Entscheidung, auf die es ankommt
Version 4 ist von vorn bis hinten zufällig. Sie trägt keinerlei Information: nicht wann sie entstand, nicht von wem, nicht in welcher Reihenfolge. Das ist je nach Einsatzort ihre größte Stärke oder ihr zentraler Mangel.
Version 7, 2024 in RFC 9562 standardisiert, ersetzt die ersten 48 Bit durch einen Unix-Zeitstempel in Millisekunden und füllt den Rest mit Zufall. Weil die Zeit vorne steht und der Wert von links nach rechts gelesen wird, sortiert das Sortieren von v7-Bezeichnern als reiner Text sie zugleich chronologisch.
Das ist kein kosmetischer Unterschied. Datenbanken halten Primärschlüssel in einem sortierten B-Baum-Index. Fügen Sie v7-Schlüssel ein, landet jede neue Zeile am rechten Rand des Baums, direkt neben der vorigen — die beschriebenen Seiten bleiben im Speicher und der Index wächst geordnet. Fügen Sie v4-Schlüssel ein, landet jeder Schreibvorgang an zufälliger Stelle, die Datenbank fasst jedes Mal eine andere Seite an, die Cache-Trefferquote sinkt und der Index fragmentiert. Bei einer großen, stark genutzten Tabelle ist der Unterschied im Einfüge-Durchsatz erheblich — deshalb hat sich v7 für Primärschlüssel so schnell durchgesetzt.
- Wählen Sie v7 für Datenbank-Primärschlüssel, Ereignis- und Log-Bezeichner und alles, was Sie nach Erstellungszeit sortieren oder per Bereichsabfrage suchen wollen.
- Wählen Sie v4, wenn der Bezeichner an unvertrauter Stelle auftaucht und nichts verraten darf — auch nicht, dass ein Datensatz kurz vor einem anderen entstand.
- Beides taugt für eine Correlation-ID, einen Idempotenzschlüssel oder einen Dateinamen, wo die Reihenfolge keine Rolle spielt.
Der Preis ist genau dieses Leck: Ein v7-Bezeichner verrät jedem, der ihn sieht, auf die Millisekunde genau seinen Entstehungszeitpunkt. Bei einer Zeilen-ID ist das meist harmlos und oft nützlich. Bei einem Passwort-Zurücksetzen-Token oder einem öffentlichen Freigabelink ist es eine Information, die Sie nicht veröffentlichen wollten — und solche Dinge sollten überhaupt keine UUIDs sein, sondern Zufallstoken aus einem eigenen Geheimnisgenerator.
Reihenfolge innerhalb derselben Millisekunde
Eine Feinheit, über die viele v7-Implementierungen stolpern: Moderne Hardware erzeugt weit mehr als einen Bezeichner pro Millisekunde. Teilen sich zwei Werte einen Zeitstempel, entscheiden die folgenden Zufallsbits über ihre Reihenfolge — also der Zufall. Erzeugen Sie fünfzig in einer engen Schleife, erhalten Sie fünfzig nur ungefähr geordnete Werte und verlieren genau die Eigenschaft, für die Sie v7 gewählt haben.
RFC 9562 begegnet dem mit einem monotonen Zähler, und dieses Werkzeug setzt ihn um: Die 12 Bit direkt nach dem Zeitstempel zählen innerhalb einer Millisekunde aufwärts, sodass ein Stapel streng statt nur ungefähr aufsteigend ist. Läuft der Zähler voll — mehr als 4096 Werte in derselben Millisekunde —, borgt sich der Generator die nächste Millisekunde, statt überzulaufen und einen Wert auszugeben, der vor seinem Vorgänger sortiert. Eine rückwärts laufende Uhr, wie sie bei NTP-Korrekturen vorkommt, behandelt er genauso.
Ein v7-Wert von links nach rechts gelesen, am Beispiel 0190a1b2-c3d4-7e5f-8a9b-0c1d2e3f4a5b:
- 0190a1b2-c3d4 — der 48-Bit-Unix-Zeitstempel in Millisekunden. Weil er vorne steht, ist Textreihenfolge gleich Zeitreihenfolge.
- 7 — die Versionsziffer, die diesen Wert zu einem v7 statt einem v4 macht.
- e5f — der 12-Bit-Monotoniezähler, der innerhalb einer Millisekunde hochzählt.
- 8 — die Variantenbits, von RFC 9562 für jeden modernen UUID festgelegt (immer 8, 9, a oder b).
- a9b-0c1d2e3f4a5b — die verbleibenden 62 Bit, rein zufällig.
UUIDs speichern und verwenden
Die kanonische Form ist kleingeschrieben mit Bindestrichen, und RFC 9562 verlangt von Generatoren genau das — weshalb dieses Werkzeug keine Formatoptionen anbietet. Andere Schreibweisen begegnen Ihnen trotzdem: groß und in geschweiften Klammern im Microsoft-Umfeld, und ohne Bindestriche dort, wo jemand eine kürzere Spalte wollte. Es sind dieselben 128 Bit, und Vergleiche sollten die Groß- und Kleinschreibung ignorieren.
Wirklich ins Gewicht fällt die Speicherung. Ein UUID ist 16 Byte groß, seine Textform aber 36 Zeichen — als Zeichenkette gespeichert mehr als verdoppelt er also den Platz in der Zeile und, wichtiger noch, in jedem Index, der ihn enthält. Nutzen Sie einen nativen Typ, wo es einen gibt:
uuid -- PostgreSQL: nativer 16-Byte-Typ BINARY(16) -- MySQL: kompakt; CHAR(36) verschwendet 20 Byte/Zeile uniqueidentifier -- SQL Server crypto.randomUUID() // JavaScript: nur v4, braucht sicheren Kontext uuid.uuid4() / uuid7() # Python: v4 in der Standardbibliothek; v7 per Bibliothek
Eine letzte Warnung: Ein UUID identifiziert, er autorisiert nicht. Weil man ihn nicht erraten kann, ist es verlockend, eine nicht verlinkte URL mit einem UUID darin als privat zu betrachten. Aber Bezeichner sickern durch — über Logs, den Browserverlauf, Referrer-Header und Screenshots. Alles, was wirklich Schutz braucht, braucht deshalb weiterhin eine echte Rechteprüfung dahinter.
Häufig gestellte Fragen
- Sollte ich v4 oder v7 verwenden?
- Nehmen Sie v7 für Primärschlüssel und alles, was Sie nach Erstellungszeit sortieren: Der führende Zeitstempel hält Einfügungen am Ende des Index beisammen, statt sie darüber zu verstreuen. Nehmen Sie v4, wenn der Bezeichner überhaupt nichts verraten darf, auch nicht seinen Entstehungszeitpunkt.
- Können zwei UUIDs jemals gleich sein?
- Möglich, aber verschwindend unwahrscheinlich. Version 4 hat 122 Zufallsbits, sodass selbst nach Milliarden erzeugter Werte die Kollisionswahrscheinlichkeit weit unter der liegt, dass der Speicher sie stillschweigend beschädigt.
- Was ist aus den Versionen 1, 3 und 5 geworden?
- Version 1 kodiert einen Zeitstempel und die MAC-Adresse der Maschine, verrät also die Hardware-Identität und lässt sich im Browser ohnehin nicht erzeugen. Die Versionen 3 und 5 leiten einen UUID deterministisch aus einem Namensraum und einem Namen ab, per MD5 oder SHA-1 — nützlich, wenn dieselbe Eingabe immer denselben Bezeichner ergeben muss, aber eine andere Aufgabe als einen neuen zu erzeugen.
- Ist ein UUID sicher genug als geheimes Token?
- Ein v4-UUID ist nicht erratbar, ein v7 verrät jedoch offen seine Entstehungszeit, und keiner von beiden ist als Zugangsnachweis gedacht. Für Passwort-Zurücksetzungen, Sitzungstoken oder Freigabelinks erzeugen Sie ein eigenes Zufallsgeheimnis und prüfen die Rechte serverseitig, statt sich darauf zu verlassen, dass der Bezeichner schwer zu erraten ist.
- Warum ist mein v7-Stapel in anderen Werkzeugen nicht perfekt sortiert?
- Weil viele Implementierungen den monotonen Zähler auslassen. Teilen sich mehrere Werte eine Millisekunde, entscheiden die folgenden Zufallsbits über ihre Reihenfolge. Dieses Werkzeug setzt den Zähler aus RFC 9562 um, ein hier erzeugter Stapel ist also streng aufsteigend.
- Wie sollte ich einen UUID in einer Datenbank speichern?
- In einem nativen 16-Byte-Typ, wo es einen gibt — uuid in PostgreSQL, uniqueidentifier im SQL Server, BINARY(16) in MySQL. Die 36 Zeichen lange Textform stattdessen zu speichern, verdoppelt den Platzbedarf in der Zeile und in jedem Index mit dieser Spalte mehr als.
- Werden sie auf Ihren Servern erzeugt?
- Nein. Sie entstehen in Ihrem Browser mit crypto.getRandomValues, der kryptografischen Zufallsquelle der Plattform — derselben, die crypto.randomUUID nutzt. Kein Wert wird irgendwohin gesendet, und ein Neuladen der Seite erzeugt einen völlig frischen Satz.