UUID prüfen

Eine UUID ist 128 Bit, üblicherweise als 32 Hexziffern in fünf durch Bindestriche getrennten Gruppen geschrieben. Prüfbar ist an einer solchen Zeichenkette dreierlei: ob die Form stimmt, welche Version das dreizehnte Zeichen behauptet und welche Variante die ersten Bits der vierten Gruppe angeben.

Nicht prüfbar ist, ob die Kennung jemals vergeben wurde. Es gibt kein Verzeichnis und keine Prüfziffer — eine UUID trägt keine Information darüber, ob sie echt ist. Wer wissen muss, ob ein Datensatz existiert, muss die Datenbank fragen; diese Seite beantwortet die Frage davor, nämlich ob es sich überhaupt lohnt zu fragen.

Die Versionsnummer ist das erste Zeichen der dritten Gruppe, also das dreizehnte Hexzeichen der Kennung. Eine `4` dort bedeutet Zufallszahl, eine `1` zeitbasiert, eine `7` zeitsortierbar nach dem neuen RFC 9562, und `3` sowie `5` stehen für die namensbasierten Varianten über MD5 beziehungsweise SHA-1.

Das lässt sich mit bloßem Auge ablesen, sobald man weiß, wohin man schaut — und es ist der schnellste Weg, eine Vermutung zu prüfen. Wer eine Kennung sieht, die an dieser Stelle keine bekannte Ziffer trägt, hat entweder eine UUID aus einer Zeit vor der Versionierung vor sich oder etwas, das nur so aussieht.

Das erste Zeichen der vierten Gruppe muss `8`, `9`, `a` oder `b` sein. Diese vier Ziffern haben gemeinsam, dass ihre obersten Bits `10` lauten — das ist die Variante, die RFC 4122 für sich beansprucht, und alles andere gehört zu älteren oder reservierten Schemata.

Praktisch heißt das: Eine Kennung mit einer korrekten Version, aber einer `c` oder `f` an dieser Stelle, wurde nicht von einer regelkonformen Bibliothek erzeugt. Der häufigste Grund sind selbstgebaute Generatoren, die 32 zufällige Hexziffern aneinanderreihen und die beiden festen Stellen übersehen — ein Fehler, der jahrelang unbemerkt bleibt.

Bei einer Version-4-UUID sind vier Bits durch die Versionsnummer und zwei durch die Variante belegt. Von 128 Bit bleiben also 122 zufällige — genug, dass die Kollisionswahrscheinlichkeit auch bei Milliarden erzeugter Kennungen jenseits jeder praktischen Relevanz liegt.

Das ist der Grund, warum man UUIDs verteilt erzeugen kann, ohne sich abzustimmen. Es setzt allerdings voraus, dass die Bits wirklich zufällig sind: Ein Generator, der einen schwachen Zufallsgenerator verwendet, erzeugt Kennungen, die die Prüfung hier bestehen und trotzdem vorhersagbar sind. Die Form sagt nichts über die Qualität der Quelle.

Die Spezifikation schreibt beim Erzeugen Kleinbuchstaben vor und verlangt beim Lesen, dass Großbuchstaben akzeptiert werden. In der Praxis begegnen einem beide: .NET und viele Windows-Werkzeuge schreiben traditionell in Großbuchstaben, die meisten anderen in Kleinbuchstaben.

Dazu kommen zwei verbreitete Verpackungen — geschweifte Klammern, die aus der Registry-Schreibweise stammen, und ein vorangestelltes `urn:uuid:`, das aus dem URN-Namensraum kommt. Beide werden hier erkannt und ignoriert. Wer selbst vergleicht, sollte vorher in Kleinbuchstaben normalisieren, sonst scheitert ein Vergleich zweier identischer Kennungen an der Schreibweise.

Eine Version-1-UUID enthält den Erzeugungszeitpunkt auf 100 Nanosekunden genau und in der letzten Gruppe traditionell die MAC-Adresse der Netzwerkkarte. Beides ist rekonstruierbar, wer die Kennung hat. Aus einem Datenbankschlüssel, der öffentlich sichtbar ist, wird damit ein Hinweis auf Gerät und Zeitpunkt.

Das ist keine theoretische Sorge — es war der Weg, auf dem der Autor des Melissa-Virus 1999 identifiziert wurde, weil Word die MAC-Adresse in Dokument-IDs schrieb. Wo eine Kennung nach außen sichtbar ist, ist Version 4 die richtige Wahl; moderne Bibliotheken setzen bei Version 1 zudem eine zufällige Knoten-ID statt der echten Adresse.

Version 7 stellt einen Millisekunden-Zeitstempel voran und füllt den Rest mit Zufall. Damit sind die Kennungen in ihrer natürlichen Reihenfolge zeitlich sortiert — und genau das löst das Problem, wegen dessen viele Teams UUIDs als Primärschlüssel gemieden haben.

Der Grund ist der Datenbankindex. Zufällige Schlüssel schreiben an ständig wechselnde Stellen eines B-Baums, was Seiten aufteilt und den Cache entwertet; bei großen Tabellen kostet das messbar Schreibleistung. Ein aufsteigender Schlüssel schreibt immer ans Ende. Version 7 behält die verteilte Erzeugung und nimmt diesen Nachteil weg — allerdings um den Preis, dass der Erzeugungszeitpunkt wieder ablesbar ist.

Eine Kennung aus lauter Nullen ist die Nil-UUID, ausdrücklich in der Spezifikation vorgesehen und formal gültig, obwohl sie weder Version noch Variante trägt. Sie bedeutet „keine“ und taucht überall dort auf, wo ein Feld nicht null sein darf, aber leer sein soll.

Seit RFC 9562 gibt es das Gegenstück, die Max-UUID aus lauter `f`. Beide bestehen die Prüfung hier und werden als das benannt, was sie sind. Wer eine Nil-UUID in Produktionsdaten findet, sollte allerdings misstrauisch werden: Meist ist sie kein bewusster Platzhalter, sondern ein Generator, der stillschweigend gescheitert ist.

Die häufigsten Fehler sind banal: 31 statt 32 Ziffern, weil beim Kopieren ein Zeichen verlorenging, ein Leerzeichen am Ende aus einer Tabellenzelle, oder eine Zeichenkette aus 32 Ziffern ohne Bindestriche. Das letzte ist eine gängige Speicherform und in einer Datenbankspalte völlig normal — nur ist es nicht die Textform.

Diese Seite sagt in solchen Fällen, woran es lag, statt nur „ungültig“ zu melden. Das ist der eigentliche Nutzen: Wer eine Kennung in eine Fehlermeldung eingetippt bekommt, will wissen, ob er ein Zeichen verloren hat oder ob das Gegenüber etwas geschickt hat, das nie eine UUID war.

Eine UUID ist für sich genommen kein personenbezogenes Datum, aber sie ist regelmäßig der Schlüssel zu einem — eine Nutzer-ID, eine Sitzungskennung, ein Vorgangsschlüssel aus einem Support-System. Weil die Prüfung in der Seite passiert, wird nichts davon an uns übermittelt.

Bei Version-1-Kennungen kommt hinzu, dass sie selbst Information tragen: Zeitpunkt und möglicherweise die MAC-Adresse des erzeugenden Geräts. Genau solche Werte durch ein fremdes Formular zu schicken wäre die schlechtere Idee — und der Grund, warum diese Seite die Auswertung dort erledigt, wo die Kennung ohnehin schon ist.

Auf dieser Website gibt es eine zweite UUID-Seite, und die erzeugt welche. Zusammengelegt hätte eine Seite ein Eingabefeld für alle, die etwas prüfen wollen, und einen Knopf für alle, die etwas brauchen — jeweils die Hälfte der Oberfläche als totes Gewicht.

Es sind auch zwei verschiedene Momente. Wer erzeugt, füllt eine Testdatenmenge oder eine Konfiguration und will es schnell hinter sich bringen. Wer prüft, sucht einen Fehler und will lesen, warum etwas nicht stimmt. Die Erklärungen, die dabei helfen, sind in beiden Fällen andere — und deshalb sind es zwei Seiten.