Entwicklertools · UUID Generator
UUID Versionen 1 bis 8 erklärt: Welche sollten Sie generieren?
· Hintergrund
UUID Kryptographie Browser-APIs
Acht Versionen haben dasselbe Format, lösen aber unterschiedliche Probleme: Zeitreihenfolge, Reproduzierbarkeit, Zufälligkeit oder benutzerdefinierte Layouts. In diesem Beitrag werden die einzelnen Schritte erläutert und ein Entscheidungsweg aufgezeigt.
Ein Format, acht Rezepte – warum das Versionsnibble wichtig ist, wenn Sie eine Bibliotheksfunktion auswählen
Der UUID-Standard definiert ein 128-Bit-Format als sechsunddreißig hexadezimale Zeichen mit Bindestrichen. RFC 9562 definiert acht verschiedene Rezepte – Versionen eins bis acht – zum Füllen dieser Bits mit unterschiedlichen Mustern und Bedeutungen. Das Versionsnibble (erstes Zeichen der dritten Gruppe) gibt an, welche Methode den Wert erzeugt hat, und dient als Bezeichnung. Die Wahl der falschen Version führt dazu, dass unnötige zeitliche Informationen gespeichert werden, dass Ordnungsgarantien für die Datenbankleistung fehlen oder die Sicherheitsrollen der Bezeichner falsch verstanden werden. In diesem Beitrag geht es um jede Version, welches konkrete Problem sie löst, wann Entwickler in der Praxis darauf stoßen und bietet einen Entscheidungsrahmen für die Auswahl der richtigen Version für Ihre spezifischen Systemanforderungen.
v1 und v6: Zeit plus Knoten – das ursprüngliche zeitbasierte Layout und die neu geordnete Version, die korrekt sortiert
Version 1 kombiniert einen 60-Bit-Zeitstempel mit einer Knotenkennung (ursprünglich eine MAC-Adresse, obwohl moderne Implementierungen Zufallswerte verwenden, um den Verlust von Hardwareinformationen zu vermeiden). Der Zeitstempel zeichnet 100-Nanosekundenintervalle seit Oktober 15, 1582 auf. Das Knotenfeld kann Aufschluss darüber geben, wann der Identifikator generiert wurde und wo er geografisch seinen Ursprung hat, weshalb moderne Implementierungen MAC-Adressen vermeiden. Version 6 ordnet die gleichen Zeitstempel- und Knoteninformationen neu an, um die Sortierbarkeit zu verbessern, indem höherwertige Zeitbits nach vorne verschoben werden, sodass v6-UUIDs in der lexikografischen Reihenfolge korrekt sortiert werden. Wenn Ihre Anwendung UUIDs benötigt, die auf natürliche Weise nach Erstellungszeit sortiert werden und über eine bessere Indexlokalität verfügen, ist Version 6 die moderne Wahl.
v2: DCE Security – die selten verwendete Variante, die POSIX-Identifikatoren einbettet
Version 2 wird in neuen Systemen selten verwendet. Es bettet POSIX-Benutzer- oder Gruppenkennungen in das UUID-Layout ein, sodass es nur in älteren Umgebungen nützlich ist, in denen diese Kennungen eine organisatorische Bedeutung haben. Das v2-Design geht von einem spezifischen Rechenmodell (DCE-Sicherheit) aus, das in modernen verteilten Systemen ungewöhnlich ist. Die meisten Organisationen verknüpfen UUIDs mit Benutzern oder Gruppen in ihrer Anwendungsschicht durch Datenbankverknüpfungen oder Nachschlagetabellen, nicht durch Kodierung der Benutzer-ID in die Kennung selbst. Diese Trennung der Belange erleichtert die Änderung von Autorisierungsmodellen, die Migration von Benutzerdaten und die Pflege von Prüfprotokollen. Die direkte Codierung von Anmeldeinformationen in UUIDs führt zu einer engen Kopplung und erschwert die Weiterentwicklung von Systemen.
v3 und v5: namensbasiert – deterministische IDs, gehasht aus einem Namespace und einem Namen mit MD5 oder SHA-1
Versionen 3 und 5 UUIDs sind deterministisch: Der gleiche Namespace und Name erzeugen immer den gleichen Bezeichner, ideal für die Darstellung stabiler Zuordnungen aus externen Daten. Version 3 verwendet MD5 und Version 5 verwendet SHA-1 als Hash-Algorithmen, was ihr jeweiliges Alter und ihre Akzeptanz widerspiegelt. Wenn ein Kundendatensatz zum Import eintrifft, ist ein von einem festen Namespace abgeleiteter v5-UUID über mehrere Importläufe hinweg identisch, wodurch doppelte Datensätze vermieden werden. Dieser Determinismus bedeutet, dass UUID für jeden reproduzierbar und vorhersehbar ist, der den Namespace und die Eingabe kennt. Der praktische Wert zeigt sich in Datenintegrationsszenarien: Abgleich von Kundendatensätzen aus mehreren Systemen, Vermeidung von Duplikaten bei wiederkehrenden Importen und Zuweisung stabiler IDs zu Artikeln.
v4: zufällig – 122 Bits aus einem CSPRNG und die Standardauswahl bei der Bestellung spielt keine Rolle
Version 4 ist die Standardauswahl, wenn keine Bestellung erforderlich ist und Sie eine unabhängige Generierung ohne zentrale Koordination wünschen. Ein v4 UUID besteht aus 122 Bits aus einer kryptografisch sicheren Zufallsquelle, wobei sechs Bits auf feste Werte gesetzt sind (Versionsnibble 4 und RFC 9562 Variantenbits 10). Der springende Punkt ist die Zufälligkeit: Jeder Aufruf erzeugt einen anderen Wert, Kollisionen bleiben verschwindend unwahrscheinlich und es ist kein externer Zustand oder keine Koordination erforderlich. Es handelt sich um die Version, die ToolAcre mit crypto.randomUUID() oder crypto.getRandomValues() generiert. Diese Version eignet sich für Objektreferenzen, unstrukturierte Daten und die meisten Rollen außerhalb von Primärschlüsseln oder Sortierkontexten.
v7 und v8: Unix-Zeit und benutzerdefiniert – die moderne zeitgeordnete Version für Datenbankschlüssel und die Notluke für maßgeschneiderte Layouts
Version 7, standardisiert in RFC 9562, bringt moderne zeitgeordnete Eigenschaften in das UUID-Format. Es verwendet einen 48-Bit Unix-Millisekunden-Zeitstempel, 12 Bits mit einer Genauigkeit im Submillisekundenbereich und 62 Zufallsbits zusammen. Der Unix-Millisekunden-Zeitstempel ist bis zum Jahr 10889 gültig und daher für Systeme geeignet. Das Ergebnis wird korrekt in lexikografischer Reihenfolge sortiert und passt in eine Standardspalte mit 128-Bit UUID ohne besondere Behandlung oder Kodierungskonvertierung. Wenn Ihre Anwendung Bezeichner benötigt, die nach Erstellungszeit im Standardformat UUID sortiert werden, ist Version 7 die aktuelle Best Practice. Version 8 ist ein standardisierter Sammelbegriff für durch die Implementierung definierte Formate, der nur nützlich ist, wenn Sie bestimmte Bit-Layouts benötigen, die nicht von v1–v7 abgedeckt werden.
Ausgearbeitetes Beispiel – ein Entscheidungspfad, der auf drei Szenarien angewendet wird: eine öffentliche API-Referenz, ein Primärschlüssel und eine stabile ID für importierte Datensätze
Drei reale Szenarien veranschaulichen die Versionsauswahl: Erstens muss eine öffentliche API-Referenz über alle API-Instanzen hinweg stabil sein, darf keine Erstellungszeit verlieren und muss bei Serverneustarts gleich sein, damit verschiedene Instanzen dieselbe Referenz für dasselbe Dokument generieren. Verwenden Sie v5 mit einem stabilen Namespace und Dokumentnamen. Zweitens muss ein Primärschlüssel für eine kontinuierlich wachsende Tabelle eindeutig sein, darf keine Indexfragmentierung verursachen und muss von jeder Anwendungsinstanz ohne zentrale Koordination generiert werden können. Verwenden Sie v7 für sortierbare Bezeichner mit standardmäßiger UUID-Ökosystemunterstützung. Drittens benötigen archivierte Datensätze, die eine stabile Suche erfordern, unveränderliche Identifikatoren.
Takeaway: Auswahl nach Eigenschaft, nicht nach Gewohnheit – der ToolAcre-Generator erzeugt zufällige UUIDs aus dem CSPRNG des Browsers für die Fälle, die v4 erfordern
Die Versionsauswahl ergibt sich aus Ihrem Schemadesign und Ihren Systemanforderungen, nicht aus Konventionen oder Vertrautheit. Zufällige UUIDs (v4) sind die Standardeinstellung, da sie keinen Status oder keine Koordination erfordern und unabhängige Bezeichner erzeugen, die für die meisten Rollen geeignet sind. Zeitlich geordnete Versionen (v6, v7) lösen Indexlokalitätsprobleme auf Kosten zeitlicher Informationslecks oder Anforderungen an die Uhrensynchronisation. Deterministische Versionen (v3, v5) verhindern doppelte Importe und ermöglichen stabile externe Zuordnungen auf Kosten der Vorhersagbarkeit – jeder, der Ihren Namespace kennt, kann sie neu berechnen. ToolAcre generiert zufällige v4-UUIDs aus dem kryptografisch sicheren Generator des Browsers. Wenn Sie eine andere Version benötigen, bestätigt die wohlgeformte Prüfung, dass die analysierten Bezeichner gültig sind.