Entwicklertools · UUID Generator
RFC 4122 vs. RFC 9562: Was sich im 2024 UUID Standard geändert hat
· Hintergrund
UUID Kryptographie Browser-APIs
Für UUIDs werden zwei RFCs zitiert, die nicht ganz dasselbe sagen. In diesem Beitrag wird erläutert, was RFC 9562 im Vergleich zu RFC 4122 hinzugefügt, klargestellt und veraltet ist.
Welchen RFC zitiere ich? – die Verwirrung, wenn Dokumentation und Bibliotheken auf unterschiedliche Standards verweisen
Zwei RFCs werden regelmäßig in der UUID-Dokumentation zitiert, und sie sagen nicht dasselbe aus. RFC 4122, veröffentlicht in 2005, definierte UUIDs und ihre fünf Versionen (v1 bis v5). RFC 9562, veröffentlicht in 2024, veraltet RFC 4122 vollständig, klärt Unklarheiten, an denen Praktiker gearbeitet haben, fügt drei neue Versionen hinzu (v6, v7, v8) und aktualisiert die Anleitung zur Implementierung von Zufälligkeit. Wenn eine Bibliothek RFC 4122 zitiert, ist das nicht falsch – diese Bibliothek wurde möglicherweise vor der Veröffentlichung von RFC 9562 veröffentlicht oder die Betreuer verfügen möglicherweise nicht über die aktualisierte Dokumentation. Durch die Überprüfung von RFC-Zitaten erfahren Sie, wann eine Bibliothek das letzte Mal wesentlich aktualisiert wurde. Beim Schreiben neuer Spezifikationen oder der Bewertung von Implementierungen ist RFC 9562 die normative Referenz.
Veraltet, ersetzt das Format nicht – alles, was unter RFC 4122 gültig ist, bleibt gültig; Das Layout und die Variantenbits bleiben unverändert
RFC 9562 ersetzt offiziell RFC 4122 als aktuelles Referenzdokument, behält jedoch die bekannte 128-Bit-Darstellung, hexadezimale Gruppen, Versionsposition und Hauptvariantenlayout bei. Vorhandene gespeicherte UUID-Zeichenfolgen müssen nicht erneut ausgegeben werden, nur weil ein neuerer RFC vorhanden ist. Die praktische Migration betrifft Dokumentation, Generatoren und Validierungsrichtlinien: Zitieren Sie den aktuellen Standard, verstehen Sie die hinzugefügten Versionen und prüfen Sie, ob alter Code auf einer Unklarheit beruhte, die durch die Revision geklärt wurde. Die Kompatibilität sollte dennoch an Systemgrenzen getestet werden, insbesondere wenn eine Bibliothek Microsoft GUID-Strukturen serialisiert oder einen engeren Satz von Versionen erzwingt, als im Standard beschrieben.
Drei neue Versionen – v6 (neu geordnete Zeit), v7 (Unix-Epoche zeitgeordnet) und v8 (implementierungsdefiniert)
RFC 9562 fügt dem Standard drei neue Versionen hinzu. Version 6 ordnet die v1-Zeitstempelbits neu an, um lexikographisch sortierbare Bezeichner für eine bessere Datenbankleistung zu erzeugen. Version 7 verwendet einen 48-Bit-Unix-Millisekunden-Zeitstempel, gefolgt von Zufallsbits, und ermöglicht so eine zeitlich geordnete Generierung ohne Datenschutzbedenken von v1. Version 8 ist eine Notluke für durch die Implementierung definierte Layouts. Keine dieser Versionen verändert die Funktionsweise von v1–v5 oder ihre Bedeutung. Ein v1 UUID von 2005 und ein v7 UUID von 2024 können in derselben Datenbank koexistieren, wobei jeweils ihre Versionsbits ihre Generierungsmethode identifizieren. Die drei neuen Versionen gehen auf gängige Muster ein, die sich in der Praxis herauskristallisiert haben.
Max UUID schließt sich Null an – dem All-F-Wert, der neben dem All-Null-Wert definiert ist
RFC 4122 dokumentierte den Nil UUID (alle Nullbits) als speziellen Referenzwert in Beispielen und Dokumentation. RFC 9562 enthält die gleiche Null-Definition, definiert aber formal den Maximalwert UUID (alle Bits auf eins gesetzt) für Bereichsgrenzen. Weder Nil noch Max sind eine zufällige Version 4 UUID, da sie keine korrekten Versions- und Variantenbits haben. Der Wert „Max UUID“ eignet sich als obere Bereichsgrenze in Datenbankabfragen: WHERE uuid_column <= MAX_UUID entspricht allen möglichen UUIDs. Nil eignet sich als Wächter für nicht zugewiesene UUID-Spalten in NULL-Werten. RFC 9562 dokumentiert beides, ohne ihre Verwendung in Anwendungsdaten vorzuschreiben.
Klargestellte Anleitung – explizite Empfehlung zur Verwendung eines CSPRNG für Zufallsfelder, für monotone Zähler innerhalb einer Millisekunde und zur Bevorzugung zeitlich geordneter Versionen für die Datenbanklokalität Die Best-Practice-Anleitungen von
RFC 9562 unterscheiden zwischen Kollisionsresistenz und Unvorhersehbarkeit. Zufällige Felder sollten eine Quelle verwenden, die dem Bedrohungsmodell der Anwendung entspricht, und sicherheitsrelevante Opazitätsaufrufe für ein CSPRNG. Zeitbasierte Generatoren haben ein separates Monotonieproblem, wenn mehrere Bezeichner einen Zeitstempel-Tick teilen; Der Standard beschreibt Zähler und zusätzliche Zeitstempelgenauigkeit als mögliche Methoden, jeweils mit Status- und Rollover-Regeln. Namensbasierte Versionen bleiben deterministische Identifikatoren und keine Echtheitsnachweise. Diese Klarstellungen sind wichtig, da ein UUID-Parser alle Layouts akzeptieren kann, auch wenn sich ihre Generierungsanforderungen und Informationsoffenlegungseigenschaften unterscheiden.
Wo die Ideen von ULID auftauchen – wie das Community-Format das Design von v7 beeinflusst hat
RFC 9562 sagt, dass seine Autoren bei der Entwicklung der neuen Layouts mehrere bestehende sortierbare Identifikatorschemata analysiert haben, darunter ULID, Snowflake und KSUID. Dies stützt eine bescheidene Schlussfolgerung: Die betriebliche Nachfrage nach zeitlich geordneten, verteilten Identifikatoren hat die Überarbeitung beeinflusst. Es beweist nicht, dass ein Community-Format der Version 7 ein exaktes Feldlayout spendiert hat. Die praktische Ähnlichkeit reicht für Architekturarbeiten aus: Diese Familien platzieren Zeitinformationen weit vorne, sodass die normale Reihenfolge eine breite Erstellungsreihenfolge beibehalten kann, und unterscheiden sich dann in der Kodierung, Koordination und im Verhalten innerhalb der Ticks. Wählen Sie zwischen ihnen aufgrund der Ökosystemkompatibilität und dokumentierten Garantien und nicht aufgrund der Behauptung einer direkten Abstammung.
Was dies nicht abdeckt – ein zeilenweiser Unterschied; Dieser Beitrag befasst sich mit den praktischen Konsequenzen für Implementierer
Dieser umfassende Beitrag befasst sich mit den praktischen Konsequenzen und der Implementierung von RFC 9562 für Implementierer und Benutzer, nicht mit zeilenweisen Unterschieden zu RFC 4122. Die vollständigen Spezifikationen sind bei Normungsgremien erhältlich und für die Implementierung der UUID-Handhabung in Sprachen oder Plattformen lesenswert – der Text bietet maßgebliche Details, die über das hinausgehen, was eine Übersicht abdecken kann. Dieser Beitrag beschreibt nicht die Mechanik auf Bitebene, wie v6 v1-Bytes neu anordnet oder wie v7 Unix-Millisekunden codiert. Sowohl die Standards als auch die Implementierungshandbücher bleiben die wichtigste maßgebliche Referenz für alle Implementierungsfragen in Bezug auf Bit-Layout, Kodierung oder Konformitätsüberprüfung.
Takeaway: Aktualisieren Sie Ihre Zitate und Ihre Standardeinstellungen – der ToolAcre-Generator folgt der CSPRNG-Anleitung, die beide RFCs teilen
Aktualisieren Sie für jede neue Arbeit die Dokumentation und Spezifikationen, um RFC 9562 zu zitieren. Jeder UUID aus RFC 4122 bleibt unter RFC 9562 gültig – die Migration ist rein zukunftsorientierter und administrativer Natur. Die klareren Leitlinien zur kryptografischen Zufälligkeit bekräftigen, dass Identifikatoren aus kryptografisch sicheren Quellen in Produktionssystemen stammen müssen. ToolAcre folgt den kryptografischen Zufälligkeitsrichtlinien beider RFCs und verwendet ausschließlich die Web Crypto API des Browsers. Wenn Sie in Protokollen, Datenbankexporten oder API-Antworten auf UUID stoßen, meldet die wohlgeformte Prüfung von ToolAcre ihre Version und Variante anhand von RFC 9562. RFC 9562 ist eine Klarstellung und Modernisierung eines bereits stabilen Standards.