UUIDs erzeugen

Für einen Primärschlüssel in der Datenbank v7. Wenn sie unmöglich zu erraten sein muss – ein Link zum Zurücksetzen des Passworts, ein Einladungscode, eine Session-Kennung – v4. Das ist die ganze Entscheidung, und die meisten erfahren nie, dass es eine gab, weil fast jeder Generator nur v4 anbietet.

Weil sie völlig zufällig ist und ein Datenbankindex sortiert ist. Neue zufällige Schlüssel landen an zufälligen Stellen im Index, sodass jedes Einfügen eine andere Seite berührt, der Cache nicht mehr hilft und der Index fragmentiert und wächst. Bei einer großen, stark genutzten Tabelle ist das eine messbare Verlangsamung, die mit der Zeit schlimmer wird. Das ist keine theoretische Sorge – genau deshalb behandeln inzwischen sowohl die Postgres- als auch die MySQL-Dokumentation das Thema.

Eine UUID, deren erste 48 Bit ein Zeitstempel in Millisekunden sind, gefolgt von Zufall. Sie ist weiterhin global eindeutig und weiterhin 128 Bit lang, aber weil die Zeit vorne steht, sortieren sich v7-UUIDs in der Reihenfolge ihrer Erstellung. Neue Schlüssel werden am Ende des Index angehängt, statt sich darüber zu verteilen – genau wie bei einer automatisch hochzählenden Ganzzahl, nur mit der Eindeutigkeit einer UUID. Sie wurde 2024 in RFC 9562 standardisiert und ist die aktuelle Empfehlung für neue Tabellen.

Ja, auch innerhalb derselben Millisekunde – und genau das machen die meisten Implementierungen falsch. Ein Zeitstempel hat nur Millisekunden-Auflösung, daher ist eine Schleife, die tausend IDs erzeugt, innerhalb einer einzigen fertig – und mit rein zufälligen niederwertigen Bits sortieren sich diese tausend NICHT in der Reihenfolge ihrer Erzeugung. Dieser Generator verwendet den in RFC 9562 beschriebenen monotonen Zähler, sodass ein Stapel jedes Mal streng aufsteigend ist. Erzeugen Sie tausend und sortieren Sie sie; sie kommen in der Reihenfolge ihrer Erstellung zurück.

Mit einer Einschränkung: Sie verrät konstruktionsbedingt, wann sie erzeugt wurde, auf die Millisekunde. Für einen Datenbankschlüssel ist das meist harmlos oder sogar nützlich. Ist der Erstellungszeitpunkt selbst aber sensibel oder muss die Kennung nicht erratbar sein, verwenden Sie v4 – v7 hat zwar immer noch 74 Zufallsbits, was sehr viel ist, aber ihr Zeitstempel ist für jeden, der die ID hat, klar lesbar.

Ja. Der Zufall stammt aus `crypto.getRandomValues`, dem kryptografisch sicheren Generator des Browsers, nie aus `Math.random`. Dieser Unterschied hat schon echte Sicherheitslücken verursacht: `Math.random` ist schnell, aber vorhersagbar, und darauf aufgebaute Session-Tokens wurden in der Praxis erraten. Eine v4-UUID hat 122 Zufallsbits – genug, dass Kollisionen praktisch keine Rolle spielen.

Ja, vollständig – und bei Kennungen zählt das. Eine UUID, die vom Server eines anderen abgerufen wird, ist eine UUID, die jemand anderes gesehen hat – was den Zweck verfehlt, wenn Sie ein Geheimnis erzeugen. Diese hier verlassen nie Ihren Browser. Schalten Sie nach dem Laden der Seite Ihr WLAN aus, und alles funktioniert genauso. Das ist der einfachste Weg, die Datenschutzaussage selbst zu überprüfen, statt uns einfach beim Wort zu nehmen.

Nur Nullen: 00000000-0000-0000-0000-000000000000. Sie ist eine gültige, reservierte UUID und bedeutet „keine“ oder „nicht gesetzt“, wo null nicht möglich ist. Ihr Gegenstück, die Max-UUID aus lauter f, dient manchmal als Sortier-Endmarke. Beide werden hier angeboten, weil man sie gelegentlich braucht und sie sich nur umständlich fehlerfrei tippen lassen.