UUID-Generator
Erzeuge UUIDs in v4 oder zeitlich sortiertem v7 und untersuche vorhandene.
Zufällige UUIDs
Eine UUID untersuchen
Fügen Sie eine ein, um zu sehen, welche Version es ist und was — falls überhaupt etwas — darin steckt.
Die Versionen, und welche zwei zählen
Es gibt acht, und für neue Arbeit läuft die Wahl faktisch auf zwei hinaus. Die übrigen sollte man erkennen, wenn man ihnen in einem alten System begegnet.
| Version | Gebildet aus | Nehmen, wenn |
|---|---|---|
| v4 | 122 Zufallsbits | Sie Unerratbarkeit brauchen. Die Voreinstellung für Token und Kennungen. |
| v7 | Zeitstempel + Zufall | Sie einen Datenbankschlüssel brauchen. Sortiert nach Erstellungszeit. |
| v1 | Zeitstempel + MAC-Adresse | Altlast. Verrät Maschine und Zeitpunkt. |
| v3 / v5 | Hash aus Namensraum und Name | Dieselbe Eingabe stets dieselbe Kennung ergeben soll. |
| v6 | v1, umsortiert | Sie v1-Daten migrieren und wollen, dass sie sortieren. |
| v8 | Was immer Sie festlegen | Fast nie. |
Das Indexproblem — der eigentliche Grund, warum es v7 gibt
Das ist das praktische Argument, und es lohnt sich, es zu verstehen statt zu glauben.
Ein Primärschlüssel liegt in einem B-Baum, geordnet. Fügt man fortlaufende Ganzzahlen ein, landet jede neue Zeile am rechten Rand: Eine Seite bleibt im Speicher warm, der Baum wächst ordentlich, und Schreibvorgänge sind billig.
Fügt man v4-UUIDs ein, landet jede Zeile irgendwo zufällig. Seiten im ganzen Baum werden berührt, jede muss gelesen werden, bevor sie geschrieben werden kann, und volle Seiten teilen sich. Bei einer Tabelle nennenswerter Größe sinkt der Schreibdurchsatz merklich und der Index fragmentiert — der Effekt ist gut dokumentiert und hat UUID-Schlüsseln ihren Ruf eingebracht.
v7 behebt das, indem es den Zeitstempel voranstellt. Erzeugen Sie oben mit ausgewähltem v7 eine Handvoll und sehen Sie sich den gemeinsamen Präfix an: Kurz nacheinander erzeugte Werte liegen benachbart, Einfügungen hängen sich also wie bei einer Ganzzahl ans Ende des Index an und bleiben trotzdem global eindeutig. Sie behalten die Eigenschaft, die UUIDs attraktiv machte — irgendwo eine Kennung erzeugen, ganz ohne Abstimmung —, ohne bei jedem Schreibvorgang dafür zu zahlen.
Genauer: Die Ordnung ist zwischen Millisekunden garantiert, nicht innerhalb einer. Zwei in derselben Millisekunde erzeugte v7-UUIDs ordnen sich nach ihren Zufallsenden, was RFC 9562 erlaubt und Implementierungen optional per Zähler verschärfen dürfen. Für das Argument der Index-Lokalität macht das keinen Unterschied, denn es hängt allein am führenden Zeitstempel.
Die Kosten, die für beide bleiben: 16 Byte statt 4 oder 8, vervielfacht in jeden Index, der auf den Schlüssel verweist. Bei einer großen Tabelle mit mehreren Fremdschlüsseln ist das echter Plattenplatz.
Was v7 preisgibt
Den Zeitstempel kann jeder lesen, der die Kennung hat. Fügen Sie eine v7-UUID oben in den Inspektor ein, und er nennt Ihnen die Millisekunde ihrer Erzeugung.
Meist harmlos. Gelegentlich nicht: Eine v7-Kennung in einer öffentlichen URL verrät, wann ein Datensatz angelegt wurde, und das kann genügen, um Anmeldezahlen, Bestellvolumen oder eine rückdatierte Datei abzuleiten. Wenn das zählt, ist die naheliegende Trennung: v4 für alles Sichtbare, v7 für interne Schlüssel.
Wo der Zufall echt sein muss
Die Kollisionsrechnung, die alle zitieren — 2,7 Trillionen bis zur Fifty-fifty-Chance auf eine einzige Kollision — setzt 122 wirklich zufällige Bits voraus. Das ist eine Aussage über das Format, nicht über Ihre Implementierung.
Eine auf Math.random() gebaute UUID hat weder die Entropie noch die Unvorhersehbarkeit, die diese Zahl nahelegt, und Kollisionen in freier Wildbahn gingen praktisch immer darauf zurück und nicht auf Pech. Zwei in derselben Sekunde mit demselben Startwert gestartete Prozesse erzeugen dieselbe Folge.
Diese Seite nutzt crypto.randomUUID(), wo es existiert, sonst crypto.getRandomValues. Prüfen Sie, was Ihr eigener Code verwendet, gerade wenn UUIDs als Token einspringen — eine vorhersehbare Kennung für das Zurücksetzen eines Passworts ist eine vollständige Kontoübernahme.
Sie sparsam speichern
Die 36-stellige Textform ist bequem und verschwenderisch. Die Alternativen, alle dieselben 128 Bit:
- Nativer UUID-Typ — Postgres hat einen, er speichert 16 Byte. Nehmen Sie ihn.
- `BINARY(16)` — das Gegenstück in MySQL, rund halb so viel Speicher wie
CHAR(36). - Base64 — 22 Zeichen, wenn es Text sein muss und die Länge zählt.
- Base32 — 26 Zeichen, ohne Groß-/Kleinschreibung, und genau das, was Sie wollen, falls jemand so etwas je vorlesen muss.
Verwandt
Für Geheimnisse, die ein Mensch tippen statt eine Maschine speichern muss, nutzt der Passwortgenerator dieselbe Zufallsquelle. Um den Zeitstempel einer v7-UUID in einem anderen Format zu lesen, übernimmt der Zeitstempel-Konverter.
Fragen zu UUIDs
Können zwei UUIDs kollidieren?
Im Prinzip ja, in der Praxis nein — sofern der Zufall echt ist. Eine v4-UUID hat 122 Zufallsbits; Sie müssten rund 2,7 Trillionen davon erzeugen, um eine Kollisionswahrscheinlichkeit von 50 % zu erreichen — etwa eine Milliarde pro Sekunde über 85 Jahre. Der realistische Fehlerfall ist nie die Mathematik, sondern eine schwache Zufallsquelle. Eine UUID auf Basis von Math.random() oder eines schlecht initialisierten Generators kann kollidieren und tut es auch — deshalb nutzt diese Seite die kryptografische Quelle des Browsers.
Sollte ich eine UUID als Primärschlüssel verwenden?
Das hängt von der Version ab, und der Unterschied ist groß. Eine v4-UUID ist zufällig, aufeinanderfolgende Einfügungen landen also an beliebigen Stellen im B-Baum: Seiten teilen sich, der Index fragmentiert, und bei großen Tabellen sinkt der Schreibdurchsatz messbar. Eine v7-UUID beginnt mit einem Millisekunden-Zeitstempel, Einfügungen hängen sich also wie bei einem Auto-Increment hinten an und bleiben trotzdem global eindeutig. Wenn Sie UUID-Schlüssel wollen, nehmen Sie v7. Der andere Preis gilt für beide: 16 Byte statt 4 oder 8 für eine Ganzzahl, und das in jedem Index, der darauf verweist.
Was ist UUID v7, und kann man sie schon einsetzen?
Sie ist zeitlich geordnet: 48 Bit Unix-Millisekunden, gefolgt von 74 Zufallsbits, im Mai 2024 in RFC 9562 standardisiert. Es ist ein veröffentlichter Standard mit Unterstützung im aktuellen Postgres, in den meisten Sprachökosystemen und in einer ganzen Reihe von Bibliotheken. Für neue Projekte ist sie eine vernünftige Voreinstellung. Zu bedenken ist die eine Eigenschaft, dass sie einen Erstellungszeitpunkt einbettet: Eine v7-Kennung in einer URL verrät ungefähr, wann der Datensatz angelegt wurde.
Ist eine UUID sicher genug als Token?
Eine v4-UUID aus einer kryptografischen Quelle hat 122 Bit Entropie, mehr als genug für einen Link zum Zurücksetzen des Passworts oder eine Sitzungskennung. Zwei Einschränkungen. Erstens muss die Quelle tatsächlich kryptografisch sein — crypto.randomUUID ist es, die meisten Bibliotheksimplementierungen auch, alles auf Math.random() nicht. Zweitens taugen andere Versionen nicht: v1 enthält einen Zeitstempel und historisch eine MAC-Adresse, v3 und v5 sind deterministische Hashes ihrer Eingaben, und v7 verrät seinen Erstellungszeitpunkt. Muss es unerratbar sein, nehmen Sie v4.
Warum hat eine UUID 36 Zeichen, wenn sie nur 16 Byte groß ist?
Weil sie hexadezimal geschrieben wird — zwei Zeichen je Byte, also 32 — plus vier Bindestriche. Manche Systeme speichern stattdessen die 16 rohen Bytes; dafür gibt es BINARY(16) in MySQL, und der Speicherbedarf halbiert sich ungefähr. Andere nutzen eine kürzere Textkodierung: Base64 ergibt 22 Zeichen, Base32 ergibt 26 und unterscheidet nicht zwischen Groß- und Kleinschreibung. Alles davon sind dieselben 128 Bit in anderen Kleidern.
Zuletzt geprüft . Etwas veraltet gefunden? Sagen Sie uns Bescheid.