Entwicklertools · UUID Generator
Was macht einen UUID-String wohlgeformt und was ein Prüfer nicht wissen kann
· Wie es funktioniert
UUID Kryptographie Browser-APIs
Großbuchstaben, geschweifte Klammern, Urne: Präfixe und fehlende Bindestriche tauchen alle in der echten Eingabe auf. Dieser Beitrag definiert die kanonische Form, zeigt, was ein nachsichtiger Prüfer akzeptieren sollte, und trennt Wohlgeformtheit von Existenz.
Der 400, der ein 404 hätte sein sollen – wie schlampige UUID-Validierung zu verwirrenden API-Fehlern führt
Ein API-Endpunkt empfängt eine Kennung von einem Client: {12345678-90AB-CDEF-1234-567890ABCDEF}. Der Validierungscode prüft, ob er mit /[0-9a-f]{32}/ übereinstimmt und lehnt ihn als ungültig ab. Der Client erhält eine 400 Bad Request, wobei 404 Not Found gemeint war. Der Bezeichner ist wohlgeformt – es ist ein gültiger UUID im geschweiften Format –, aber der Validator ist zu streng. Umgekehrt akzeptiert ein Endpunkt, der eine beliebige Hex-Zeichenfolge mit 32-Zeichen (ohne Bindestriche) akzeptiert, 123456789012345678901234567890123456, analysiert sie als gültig und übersieht den Tippfehler. RFC 9562 definiert die kanonische Textdarstellung, aber reale Eingaben kommen in fünf verschiedenen Formaten an, und ein Validator, der nur die kanonische Form akzeptiert, lehnt 1 bis 5 Prozent der gut gemeinten Eingaben ab.
Die kanonische Textform – 32 Hexadezimalziffern in Kleinbuchstaben in 8-4-4-4-12, genau 36 Zeichen, wie der Standard für die Ausgabe vorgibt
Die kanonische Textform besteht aus 32 hexadezimalen Kleinbuchstaben in fünf durch Bindestriche getrennten Gruppen: 8-4-4-4-12. Dargestellt als 550e8400-e29b-41d4-a716-446655440000. Der Standard schreibt für die Ausgabe Kleinbuchstaben vor; Bei der Eingabe wird eine Übereinstimmung ohne Berücksichtigung der Groß- und Kleinschreibung empfohlen. Dieses Formular ist eindeutig, wird auf jeder Plattform auf die gleiche Weise in Bytes analysiert und ist das, was jede UUID-Bibliothek standardmäßig ausgibt. Wenn Sie ein neues UUID aus einem CSPRNG generieren, ist die kanonische Form das, was Sie produzieren sollten und was ToolAcre produziert. Die realen Eingaben weichen in vorhersehbarer Weise ab. Bezeichner in Großbuchstaben (550E8400-E29B-41D4-A716-446655440000) kommen häufig bei Systemen vor, die standardmäßig Großbuchstaben verwenden. Sie stellen dieselben Bytes dar und sollten nach der Normalisierung in Kleinbuchstaben akzeptiert werden.
Varianten aus der Praxis — hexadezimale Großbuchstaben, {braces}, das Präfix urn:uuid: und 32-stellige Formen ohne Bindestriche sowie die Frage, welche der Standard akzeptiert.
Das geschweifte Formular ({550e8400-e29b-41d4-a716-446655440000}) ist die Standardausgabe des UUID-Moduls von Python und der Systeme von Microsoft. Das Entfernen der Klammern ergibt eine gültige kanonische Form. Das URN-Präfix (urn:uuid:550e8400-e29b-41d4-a716-446655440000) wird durch RFC 8141 für einheitliche Ressourcennamen definiert; Durch das Entfernen des Schemas und des Stripping-Identifier-Präfixes bleibt die kanonische Form erhalten. Die Form ohne Bindestrich (550e8400e29b41d4a716446655440000) besteht aus 32 Hexadezimalziffern ohne Struktur; Es sind gültige Bytes, aber die Gruppierung 8-4-4-4-12, die Versionen und Varianten lesbar macht, geht verloren. Diese Varianten werden alle auf denselben 128-Bit-Wert abgebildet. Im Abschnitt 3 des RFC 9562 heißt es, dass bei der Eingabe Varianten in Großbuchstaben akzeptiert werden SOLLTEN. Andere Varianten sind nicht verboten; Es heißt, dass bei der Ausgabe die kanonische Kleinschreibung verwendet werden MUSS.
Versions- und Variantenvernunft – ob ein UUID abgelehnt werden soll, dessen dritte Gruppe mit 0 beginnt oder dessen vierte Gruppe mit f beginnt
Ein wohlgeformter Validator sollte: die kanonische Form 8-4-4-4-12 in Klein- oder Großbuchstaben akzeptieren; Akzeptieren Sie die Varianten „braced“ und „urn:“, indem Sie sie entfernen und die Kernform validieren. Akzeptieren Sie 32-stellige Hex-Zeichenfolgen ohne Bindestrich und formatieren Sie sie zum Vergleich als kanonisch. Lehnen Sie Zeichenfolgen mit der falschen Anzahl an Hexadezimalziffern oder nicht hexadezimalen Zeichen ab. Der häufigste Fehler besteht darin, Eingaben in Großbuchstaben oder in geschweiften Klammern abzulehnen, weil der Validator handschriftlich geschrieben wurde und nur der kanonischen Form entspricht. Eine Plausibilitätsprüfung der Version und Variante kann Tippfehler aufdecken. Wenn die dritte Gruppe mit 0 oder 9 beginnt, ist UUID ungültig oder reserviert; Wenn die vierte Gruppe mit e oder f beginnt, ist die Variante nicht RFC 9562.
Ausgearbeitetes Beispiel – sechs Kandidatenzeichenfolgen durchlaufen eine strenge und eine milde Prüfung, mit den Gründen, warum jede Zeichenfolge erfolgreich ist oder nicht
Ein nachsichtiger Validator akzeptiert diese Werte; Ein strenger Validator kann sie ablehnen. Die wohlgeformte Prüfung von ToolAcre führt eine strenge Validierung durch: Sie bestätigt die kanonische 36-Zeichenform mit Bindestrichen an den richtigen Stellen, überprüft Hexadezimalziffern an jeder Position und prüft, ob die Versions- und Variantenbits im Bereich liegen. Es wird nicht überprüft, ob UUID in Ihrer Datenbank vorhanden ist oder ob es aus einer kryptografisch sicheren Quelle generiert wurde. Dabei handelt es sich um separate Prüfungen, die von Ihrer Anwendungslogik durchgeführt werden. Wohlgeformt ist nicht dasselbe wie echt. Eine UUID-Zeichenfolge, die entsprechend ihrer Form korrekt analysiert wird, identifiziert möglicherweise keine Zeile in Ihrer Datenbank.
Gut geformt ist nicht real – warum ein syntaktisch perfektes UUID möglicherweise nicht in Ihren Daten vorhanden ist und warum der Prüfer niemals Ihre Autorisierungsebene sein sollte
Ein perfekt geformter UUID wurde möglicherweise falsch erraten oder kopiert. Die Formatvalidierung ist das erste Tor; Existenzprüfungen und Berechtigungsprüfungen sind die zweite und dritte. Für jede formatungültige Eingabe eine Suche in der Datenbank durchzuführen, ist verschwenderisch; Das Zurückweisen formatungültiger Eingaben vor Datenbankabfragen spart Zeit. Der ToolAcre-Generator gibt Standard-UUIDs mit 36 Zeichen aus; Wenn Sie Ihren eigenen Validator erstellen, akzeptieren Sie die Varianten braced und urn:, um realen Eingaben zu entsprechen, und lehnen Sie Zeichenfolgen ab, die die grundlegenden Formregeln nicht erfüllen, bevor Sie Ihre Datenbank befragen. Die Implementierung eines strengen Validators erfordert reguläre Ausdrücke und die Behandlung von Randfällen. Die kanonische Form ist einfach: /^[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}$/i (Groß- und Kleinschreibung wird nicht beachtet). Die geschweifte Form fügt geschweifte Klammern hinzu: /^\{[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}\}$/i. Die Variante urn: fügt ein Schema hinzu: /^urn:uuid:[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}$/i.
Was dies nicht abdeckt – die Normalisierung von IDs für die Speicherung und die Auswahl eines Spaltentyps, bei denen es sich um separate Entscheidungen handelt
Ein einzelner regulärer Ausdruck, der alle Varianten verarbeitet, ist weniger lesbar, aber möglich. Die meisten Validatoren normalisieren zuerst: Klammern und Präfix urn: entfernen, in Kleinbuchstaben umwandeln und dann das kanonische Muster abgleichen. Die Versions- und Variantenbits können nach dem Musterabgleich überprüft werden, indem die Positionen 14 und 19 untersucht werden, wie im Artikel 403 beschrieben. Der ordnungsgemäße Umgang mit ungültigen Eingaben ist Teil des Validierungsdesigns. Wenn ein Client ein fehlerhaftes UUID übermittelt, dürfen das Regex-Muster oder die internen Validierungsregeln in der Fehlermeldung nicht offengelegt werden. Geben Sie einen eindeutigen Fehler zurück: „Ungültiges UUID-Format. Erwartetes 8-4-4-4-12-Format, z. B 550e8400-e29b-41d4-a716-446655440000 „Versuchen Sie nicht, die Eingabe zu korrigieren; Bitten Sie den Kunden um eine erneute Einreichung.
Fazit: Validieren Sie die Form frühzeitig, suchen Sie separat nach der Existenz – die ToolAcre-Prüfung bestätigt die Form im Browser, bevor Sie eine Datenbank berühren
Einige Systeme protokollieren ungültige Eingaben zur Sicherheitsüberprüfung (Erkennung versuchter Einschleusung oder Formatverwirrungsangriffe). Der ToolAcre-Validator lehnt nicht-kanonische Formulare mit einer eindeutigen Fehlermeldung ab und versucht nicht, sie automatisch zu korrigieren. Warum die kanonische Form für die Interoperabilität wichtig ist: Wenn ein System UUIDs als bindestrichloses Hex und ein anderes als kanonische 8-4-4-4-12 speichert, erfordert der Vergleich auf Gleichheit eine Normalisierung. Groß- und Kleinschreibung erfordern einen Vergleich ohne Berücksichtigung der Groß- und Kleinschreibung. Versteift vs. nackt erfordert Abisolieren. Diese Variationen erschweren Massenvorgänge (Importe, Migrationen, Vergleiche). Standardwerkzeuge, die eine kanonische Form ausgeben, verringern die Reibung. Der ToolAcre-Generator gibt immer die kanonische Kleinbuchstabenform mit 36 Zeichen aus; Wenn Sie UUIDs aus anderen Systemen importieren, normalisieren Sie sie in Ihrem ETL-Prozess auf diese Form, um Konsistenz sicherzustellen.