UUID Generator
Jede Version, in Mengen, mit Prüfer

Was dieser UUID Generator bietet

Dieser UUID Generator erzeugt eindeutige IDs für Datenbanken, APIs, Dateien und Tests. Zuerst wählen Sie Version und Anzahl, dann erscheint die Liste sofort. Danach können Sie sie kopieren oder als Textdatei speichern.

Es deckt jede heute genutzte Version ab. Version 4 ist reiner Zufall, Version 7 sortiert nach Zeit, und die Versionen 3 und 5 machen aus einem Namen immer dieselbe ID. Außerdem gibt es die älteren Versionen 1 und 6 sowie die Sonderwerte nil und max.

Die Seite arbeitet auch umgekehrt. Fügen Sie eine UUID ein, dann nennt der Prüfer Version und Variante und bei zeitbasierten sogar den genauen Zeitpunkt.

Was ist eine UUID?

Eine UUID, also ein universell eindeutiger Bezeichner, ist eine 128-Bit-Zahl. Man schreibt sie meist als 32 Hex-Ziffern in fünf Gruppen, etwa 017f22e2-79b0-7cc3-98c4-dc0c0c07398f. Weil es so viele mögliche Werte gibt, kann jeder eine erzeugen, ohne einen zentralen Server zu fragen, und sie kollidiert mit keiner anderen.

Zwei kleine Teile verraten die Art der UUID. Die erste Ziffer der dritten Gruppe ist die Version, und die erste Ziffer der vierten Gruppe enthält die Variante. Alles andere ist dann Zeit, Zufall oder ein Hash, je nach Version.

Welche UUID-Version sollten Sie nutzen?

Für die meisten Aufgaben nutzen Sie Version 4, denn sie ist zufällig, einfach und überall unterstützt. Werden die IDs jedoch Schlüssel einer Datenbanktabelle, wählen Sie stattdessen Version 7. Sie beginnt mit der Zeit, daher landen neue Zeilen geordnet, und Einfügungen bleiben schnell.

Wenn etwas immer dieselbe ID bekommen soll, nutzen Sie Version 5. So lässt sich zum Beispiel eine URL oder E-Mail-Adresse in eine feste UUID verwandeln, die jedes System neu erzeugen kann. Die Versionen 1, 3 und 6 dienen dagegen vor allem älteren Systemen.

Warum UUID v7 besser für Datenbanken ist

Zufällige IDs der Version 4 verteilen sich über den ganzen Index, sodass jede Einfügung eine andere Seite trifft. Mit der Zeit bremst das Schreibvorgänge und kostet Speicher. UUID v7 beginnt dagegen mit einem Zeitstempel in Millisekunden, daher landet jede neue ID am Ende des Index, ähnlich wie eine fortlaufende Nummer.

Außerdem hält dieser Generator einen Stapel in Ordnung. Teilen sich viele IDs eine Millisekunde, sortiert ein Zähler in den nächsten 12 Bit sie, genau wie es RFC 9562, der UUID-Standard, empfiehlt.

Namensbasierte UUIDs: Versionen 3 und 5

Namensbasierte UUIDs entstehen aus zwei Eingaben: einem Namensraum, der selbst eine UUID ist, und einem Namen. Das Paar wird gehasht, daher ergeben gleiche Eingaben immer dasselbe Ergebnis. Es gibt Standard-Namensräume für Domains, URLs, OIDs und X.500-Namen, und außerdem können Sie einen eigenen nutzen.

Version 5 nutzt SHA-1 und Version 3 MD5. Hier schützt keiner der beiden Hashes etwas. Beide verteilen nur die Bits gleichmäßig. Trotzdem sollten Sie für Neues Version 5 wählen, denn der Standard bevorzugt sie.

Jede UUID mit dem Prüfer lesen

Fügen Sie eine UUID in den Prüfer ein, dann zerfällt sie sofort in ihre Teile. So sehen Sie Standardform, Variante und Version. Außerdem tragen die Versionen 1, 6 und 7 einen Zeitstempel. Der Prüfer zeigt diesen Moment in UTC und in Ihrer Zeitzone.

Bei den Versionen 1 und 6 zeigt er außerdem Taktfolge und Knoten. Der Knoten war früher die Adresse der Netzwerkkarte, daher sagt der Prüfer, ob er echt oder zufällig wirkt. Klicken Sie zudem auf eine UUID in der Liste, um sie sofort zu prüfen.

Eine ganze Liste mit dem UUID-Validator prüfen

Eine UUID nach der anderen geht gut, bis Sie vierhundert davon haben. Fügen Sie stattdessen die ganze Liste in den UUID-Validator ein, und jede Zeile erhält ihr eigenes Urteil. Die Seite trennt an Leerzeichen, Kommas, Semikolons, senkrechten Strichen und Zeilenumbrüchen. So kommen eine Tabellenspalte, ein JSON-Array und ein SQL-Ergebnis genau so an, wie sie sind. Außerdem liest sie bis zu 5.000 IDs auf einmal. Alles darüber erscheint als übersprungen, statt still zu verschwinden.

Vor allem gibt es hier drei Urteile, nicht zwei. Eine Zeile gilt als gültig, wenn der Standard sie beschreibt. Sie gilt als ungültig, wenn sie überhaupt keine UUID ist. Dazwischen steht der Hinweis, für eine Zeile mit korrekter Form, die dennoch einen Blick verdient. Zum Beispiel ist eine alte Microsoft- oder NCS-Variante eine echte UUID, die echte Systeme weiterhin ausgeben. Diese beiden Varianten stammen aus RFC 4122, dem älteren UUID-Standard. Dann gibt es noch die RFC-Variante mit einer Versionsnummer, die noch niemand vergeben hat, und die erhält ebenfalls einen Hinweis. Eine davon ungültig zu nennen wäre eine Lüge, denn laufende Systeme geben sie jeden Tag aus.

Außerdem sagt jede abgelehnte Zeile, warum. Eine Zeile in einer Liste kann nur auf drei Weisen unlesbar sein. Sie enthält ein Zeichen außerhalb von 0-9, a-f und dem Bindestrich. Sie hat die falsche Zahl an Hex-Stellen. Oder sie hat alle 32 Stellen mit den Bindestrichen an den falschen Plätzen. Die ersten zwei bedeuten meist eine Kopie, die ein verirrtes Zeichen mitgenommen hat, oder eine, die beim Einfügen eine Stelle abschnitt. Die dritte ist eine UUID, deren Bindestriche irgendwo anders sitzen als nach der 8., 12., 16. und 20. Stelle. Die Zeile sagt genau das. Leere Zeilen sind dagegen überhaupt keine Fehler, denn die Liste überspringt sie, bevor die Zählung beginnt.

Die Verpackung kommt vor der Prüfung ab, denn echte Listen kommen verpackt an. Die Seite entfernt Anführungszeichen, Backticks, eckige Klammern, spitze Klammern, runde Klammern und einen Doppelpunkt oder Punkt am Ende. Sie entfernt außerdem das Präfix urn:uuid:. Geschweifte Klammern erhalten mehr Sorgfalt. Eine Microsoft-GUID in geschweiften Klammern liest sie ganz, während eine verirrte Klammer aus einem JSON-Objekt einfach wegfällt. Zudem liest sie auch eine reine Folge von 32 Hex-Stellen ohne Bindestriche. Das gilt ebenso für jede Mischung aus Groß- und Kleinbuchstaben. Ein Wort, das nie eine ID war, etwa ein JSON-Schlüssel, erhält ebenfalls seine eigene Zeile, statt zu verschwinden. So bleibt die Zählung ehrlich über alles, was im Einfügen stand.

Als Nächstes sucht der Validator Duplikate über die ganze Liste. Der Vergleich läuft auf der kanonischen Form. So zählen {X}, urn:uuid:X und dieselbe ID in Großbuchstaben alle als eine. Danach verweist die wiederholte Zeile zurück auf die Zeile, in der sie zuerst stand. Zwei gleiche Mülleinträge dagegen zählen nie als Duplikate. Eine Zeile, die keine UUID ist, hat keine kanonische Form zum Vergleichen. Dann zählt die Zusammenfassung die Liste für Sie. Sie sehen, wie viele Zeilen durchliefen und wie viele der Standard beschreibt. Drei weitere Zählungen decken die Zeilen ab, die einen Blick wert sind, die Zeilen, die überhaupt keine UUIDs sind, und die Wiederholungen.

Diese Zählungen bleiben absichtlich getrennt, und der Grund zählt. Eine Zeile mit Hinweis hat eine korrekte Form statt einer kaputten. Sie in eine einzige Zahl aus bestanden oder nicht bestanden zu falten würde das Einzige verbergen, was an ihr auffällt. Wenn Sie jedoch nur die Probleme wollen, lässt der Filter die Zeilen im Blick, die keine UUIDs sind. Zeilen mit Hinweis behalten ihren Platz und ihren Grund. Schließlich kopiert der Bericht heraus, was der Schirm zeigt, sodass die Liste direkt in ein Ticket wandern kann.

UUID oder GUID?

Sie sind dasselbe. GUID, kurz für global eindeutiger Bezeichner, ist nur Microsofts Name dafür. Deshalb dient diese Seite auch als GUID-Generator: Schalten Sie Großbuchstaben und geschweifte Klammern ein, dann erhalten Sie den Stil {XXXXXXXX-XXXX-...}, den Windows und .NET zeigen.

Sehr alte GUIDs aus COM nutzten eine andere Variante. Der Prüfer erkennt und kennzeichnet sie, sodass Sie wissen, wann eine ID aus diesem alten Schema stammt.

Wie einmalig ist eine UUID wirklich?

In Version 4 sind 122 Bits zufällig. Folglich bräuchten Sie etwa 2,7 Trillionen IDs, bis die Chance auf eine einzige Wiederholung 50% erreicht. In der Praxis ist ein Fehler im eigenen Code also viel wahrscheinlicher als eine Wiederholung.

Zeitbasierte Versionen nutzen weniger Zufallsbits, fügen jedoch die Zeit hinzu. Folglich kollidieren zwei IDs nur, wenn sie in derselben Millisekunde entstehen und zudem dieselben Zufallsbits ziehen. Der Wikipedia-Artikel über UUIDs rechnet das genau durch.

UUIDs oder fortlaufende Nummern?

Fortlaufende IDs sind kurz und schnell, haben jedoch Grenzen. Zuerst kann nur die Datenbank sie vergeben, daher muss eine App auf das Einfügen warten, bevor sie die ID kennt. Außerdem verraten sie etwas, denn Bestellung 1043 zeigt jedem, dass Sie etwa tausend Bestellungen haben.

UUIDs lösen beide Probleme. Jeder Server, jedes Handy und jeder Browser kann offline eine erzeugen, und IDs aus verschiedenen Systemen lassen sich ohne Kollision zusammenführen. Dafür brauchen sie mehr Platz, deshalb zählen Version 7 und binäre Speicherung bei großen Tabellen.

UUIDs in Ihrem Code

Die Formatschalter decken die üblichen Fälle ab. Entfernen Sie die Bindestriche für kompakte Speicherung, fügen Sie das Präfix urn:uuid: für XML und RDF hinzu, oder setzen Sie jede ID dann in Anführungszeichen mit Kommas, bereit für ein Array oder eine SQL-Liste.

Die meisten Datenbanken haben einen eigenen Typ für UUIDs. PostgreSQL hat uuid, SQL Server uniqueidentifier, und in MySQL wählt man meist BINARY(16). Für Zeitstempel in Ihren Daten wandelt außerdem unser Unix-Zeitstempel-Umrechner sie in Daten und zurück.

Sind diese UUIDs sicher?

Ja. Die Zufallsbits stammen aus der sicheren Quelle Ihres Browsers, der Web-Crypto-Funktion getRandomValues, die für Schlüssel und Tokens gebaut ist. Außerdem geht nichts an unseren Server, daher sieht niemand sonst Ihre IDs.

Denken Sie daran: Eine UUID ist eine ID, kein Geheimnis, denn jeder, der sie sieht, kann sie kopieren. Für Passwörter und API-Schlüssel nutzen Sie stattdessen unseren Passwort-Generator.