UUID-Generator

Version 4 ist eine UUID aus Zufallsbits — 122 davon, wobei sechs weitere festgelegt sind, um Version und Variante anzuzeigen. Sie trägt keine Information darüber, wann oder wo sie entstanden ist, und genau deshalb ist sie die Vorgabe: Es leckt nichts, und zwei unabhängig irgendwo auf der Welt erzeugte kollidieren nicht.

Die anderen beantworten andere Fragen. Version 1 und 6 enthalten einen Zeitstempel und eine Knotenkennung, sortieren sich also nach Entstehungszeit und verraten etwas über die Maschine. Version 3 und 5 sind deterministisch — ein Hash eines Namens innerhalb eines Namensraums, derselbe Name ergibt also stets dieselbe UUID. Version 7 ist die neuere zeitgeordnete, entworfen für Datenbankschlüssel, wo zufälliges Einfügen einem Index schadet.

Eine UUID aus `Math.random` hat dieselbe Form, dieselben Bindestriche und dieselbe Versionsziffer wie eine aus einer kryptografischen Quelle. Nichts an ihr sieht schwach aus. Aber `Math.random` ist ein schneller Pseudozufallsgenerator mit kleinem internen Zustand, und eine Handvoll Ausgaben kann genügen, um den Rest vorherzusagen — aus einer „zufälligen“ Kennung wird damit eine erratbare.

Diese Seite benutzt `crypto.randomUUID`, das aus der Entropie des Betriebssystems schöpft und Versions- sowie Variantenbits korrekt setzt. Wo es fehlt, bricht die Seite ab und sagt das, statt auszuweichen — ein stiller Rückfall ist genau der Weg, auf dem vorhersagbare Kennungen in die Produktion gelangen, weil es kein Symptom gibt, das jemandem auffiele.

Sie ist unerratbar, und das ist nicht dasselbe wie geheim. UUIDs landen in URLs, in Logs, in Referrer-Headern, in Analytics, in Support-Tickets und auf Bildschirmfotos. Alles, was durch Kenntnis einer UUID erreichbar ist, ist für jeden erreichbar, der diese URL je gesehen hat.

Damit taugen sie gut als unerratbarer Griff für etwas nicht sonderlich Heikles — ein Freigabelink für ein Dokument, ein einmaliger Upload — und schlecht als das Einzige zwischen dem Internet und den Daten einer Person. Wer Zugriff allein an die Kenntnis der Kennung knüpft, hat eine Authentifizierung aus einem Wert gebaut, der bauartbedingt ausläuft.

Es gibt 2^122 mögliche UUIDs der Version 4. Um eine Wahrscheinlichkeit von eins zu einer Milliarde für auch nur eine Kollision zu erreichen, müsste man etwa 10^15 davon erzeugen — eine Milliarde pro Sekunde, einen Monat lang. Für jedes reale System lautet die Antwort: Es passiert nicht.

Der Vorbehalt ist, dass das nur gilt, wenn der Zufall echt ist. Jede berichtete UUID-Kollision in freier Wildbahn geht auf einen schwachen oder schlecht initialisierten Generator zurück: Container, die aus demselben Abbild starten und sich aus der Uhr initialisieren, ein eingebettetes Gerät ohne Entropie beim Start, eine Bibliothek, die auf `Math.random` ausgewichen ist. Nicht die Mathematik ist das Risiko, sondern die Quelle.

Ein zufälliger Primärschlüssel verteilt Einfügungen gleichmäßig über den Index, und das ist das Gegenteil dessen, was ein B-Baum will: Jede Einfügung berührt eine andere Seite, der Cache hilft nicht mehr, der Index fragmentiert. Bei einer großen Tabelle ist das eine messbare und gut dokumentierte Bremse.

Die üblichen Antworten sind eine zeitgeordnete UUID wie Version 7 oder ein eigener fortlaufender Schlüssel, während die UUID als äußere Kennung erhalten bleibt. Das lohnt sich bewusst zu entscheiden statt es später zu entdecken, denn den Typ eines Primärschlüssels nachträglich zu ändern gehört zu den teuersten Migrationen überhaupt.

GUID ist Microsofts Name für dieselbe 128-Bit-Kennung, und beide Begriffe sind austauschbar. Der einzige Unterschied, der einem begegnet, ist die Schreibweise: Windows-Werkzeuge — die Registry, COM, `New-Guid` in PowerShell — schreiben sie in geschweiften Klammern.

Die Prüfseite auf dieser Website nimmt diese Form an, ebenso die URN-Form mit `urn:uuid:` davor. Beides sind ganz normale Arten, einer UUID zu begegnen, und ein Werkzeug, das eine davon an einer Formalität scheitern lässt, weist genau das zurück, wofür es da ist.

Fast alle Werkzeuge in diesem Bereich rechnen beim Tippen. Dieses nicht: Ein Generator, der bei jedem Tastendruck einen neuen Wert erzeugt, ist unbenutzbar, weil man ihn nie kopieren kann — er ändert sich, während man zur Schaltfläche greift.

Deshalb steht hier ein Knopf, und deshalb steht im Ergebnisfeld vorher „Drück den Knopf“ statt eines leeren Kastens. Es ist eine kleine Entscheidung mit einer klaren Regel dahinter: Was rein rechnerisch aus der Eingabe folgt, aktualisiert sich laufend; was neu gewürfelt wird, tut es nur auf Anforderung.

Die Obergrenze ist keine technische. Der Browser könnte in derselben Zeit hunderttausend erzeugen, und es kostet uns nichts, weil kein Server beteiligt ist. Die Grenze ist die Lesbarkeit: Hundert Zeilen sind noch etwas, das man überblickt, markiert und irgendwo einfügt.

Wer mehr braucht, braucht sie fast immer programmgesteuert — in einer Migration, einem Testdatengenerator, einem Skript. Dort ist der richtige Weg `crypto.randomUUID` in der eigenen Sprache und nicht eine Textdatei aus einem Browserfeld, die niemand mehr prüfen kann.

Die erzeugten UUIDs existieren in dieser einen Seite und sonst nirgends. Sie werden nicht gespeichert, nicht gesendet und nicht protokolliert — es gibt buchstäblich keine zweite Kopie außer der, die du in die Zwischenablage nimmst.

Das ist die technisch unvermeidliche Folge davon, dass die Erzeugung lokal passiert, und keine Zusicherung, die jemand einhalten müsste. Ein Generator, der auf einem Server läuft, hat jede erzeugte Kennung gesehen — was harmlos klingt und es nicht ist, sobald eine davon als Freigabelink oder Einladungscode dient.

Die kanonische Form hat fünf Gruppen zu acht, vier, vier, vier und zwölf Hexziffern. Die Bindestriche tragen keine Information — sie sind reine Lesehilfe —, und trotzdem sollte man sie behalten: Zweiunddreißig Hexziffern ohne Trennung sind mehrdeutig, denn sie könnten ebenso ein MD5 oder die Hälfte eines SHA-256 sein.

Manche Datenbanken speichern UUIDs binär, also als sechzehn Bytes ohne jede Schreibweise, und formatieren erst beim Lesen. Das ist der effizienteste Weg und der Grund, aus dem eine Spalte je nach Zugriffsweg unterschiedlich aussieht — dieselbe Kennung, zwei Darstellungen.

Sie lohnen sich, wo mehrere Systeme unabhängig voneinander Kennungen vergeben müssen, ohne sich abzustimmen: verteilte Dienste, ein Mobilgerät im Offline-Betrieb, ein Importlauf, der Datensätze anlegt, bevor die Datenbank sie sieht. Genau dafür wurden sie entworfen.

Sie lohnen sich nicht als Ersatz für einen fortlaufenden Zähler in einer einzelnen Datenbank, die ohnehin die einzige Quelle ist. Dort kosten sie Speicherplatz, Indexleistung und Lesbarkeit und kaufen nichts — außer man will nach außen keine Rückschlüsse auf die Anzahl der Datensätze zulassen, was ein eigener und legitimer Grund ist.