Entwicklertools · UUID-Generator
Wie crypto.getRandomValues 16 zufällige Bytes in eine v4-UUID umwandelt
· Wie es funktioniert
UUID Kryptographie Browser-APIs
Eine UUID der Version 4 ist 16 bytes von einem kryptografisch sicheren Generator mit sechs überschriebenen Bits. In diesem Beitrag werden die Bytes vom Web Crypto-Aufruf in die bekannte 36-stellige Zeichenfolge umgewandelt.
Die ID, die Sie benötigen, bevor der Server antwortet – warum die clientseitige Generierung in Offline-First-Formularen, optimistischer Benutzeroberfläche und Batch-Importen erfolgt
Ein Offline-Formular benötigt möglicherweise eine Kennung, bevor ein Server antwortet, und eine optimistische Benutzeroberfläche erstellt möglicherweise mehrere Objekte gleichzeitig. Eine UUIDv4 ist so konzipiert, dass sie unabhängig und ohne zentralen Zähler generiert werden kann. Es handelt sich nicht um einen Nachweis der Benutzeridentität oder um ein Geheimnis, das Sie sicher anstelle der Authentifizierung einsetzen können. Wenn Ihre Datenbank Werte benötigt, die nach Erstellungszeit sortiert werden, werden zufällige v4-IDs nicht geordnet; Das ist eher eine separate Schemaentscheidung als ein Grund, ihre Zufälligkeit abzuschwächen.
Was crypto.getRandomValues tatsächlich tut – ein typisiertes Array aus der Entropiequelle des Betriebssystems füllen, nicht aus einer JavaScript-Formel
crypto.getRandomValues füllt ein Uint8Array mit 16 bytes aus dem kryptografisch sicheren Zufallsgenerator der Browserplattform. Die Werte werden nicht von Date.now() oder Math.random() abgeleitet. Das Betriebssystem und der Browser implementieren die zugrunde liegende Entropiequelle, sodass JavaScript-Code Bytes empfängt, anstatt selbst eine Zufallszahlenformel zu implementieren. ToolAcre weigert sich, eine Kennung zu generieren, wenn ihre sichere Quelle fehlt.
Überschreiben von Byte 6 und Byte 8 – wie das Versionsnibble zu 4 und die Variantenbits zu 10xx werden und warum nur sechs Bits verloren gehen
RFC 9562 beschreibt ein Versionsnibble und ein Variantenfeld. Beginnen Sie mit sechzehn Zufallsbytes und setzen Sie die oberen vier Bits von Byte 6 auf binär 0100 (Version 4) und die oberen beiden Bits von Byte 8 auf 10 (die Standardvariante). Die Implementierung verwendet (byte6 & 0x0f) | 0x40 und (byte8 & 0x3f) | 0x80. Sechs Bits werden überschrieben, so dass 122 Zufallsbits im UUIDv4-Schema übrig bleiben. Diese konstanten Bits machen die verbleibenden Bytes nicht weniger zufällig.
Von Bytes bis 8-4-4-4-12 – Hex-Kodierung, Ausgabe in Kleinbuchstaben und Platzierung von Bindestrichen, wie sie im Standard definiert sind
Codieren Sie jedes Byte bei Bedarf als genau zwei Hexadezimalzeichen mit einer führenden Null. Fügen Sie nach 4, 6, 8 und 10 bytes Bindestriche ein, wodurch die bekannten 8-4-4-4-12 Hexadezimalzeichengruppen entstehen. Eine gültige v4-Zeichenfolge hat eine 4 am Anfang ihrer dritten Gruppe und eine von 8, 9, a oder b am Anfang ihrer vierten. Durch die Formatierung wird keine Entropie hinzugefügt. Dadurch wird der zugrunde liegende 128-Bit-Wert nur mit Tools interoperabel, die die UUID-Textform erwarten.
Ausgearbeitetes Beispiel – ein 16-Byte-Puffer, der durch Maskierung und Formatierung bis zu seiner endgültigen UUID-Zeichenfolge verfolgt wird
Verfolgen Sie die beispielhaften Bytes 00 11 22 33 44 55 F6 77 38 99 AA BB CC DD EE FF. Das Maskieren von F6 bei Byte 6 erzeugt 46; Das Maskieren von 38 am Byte 8 erzeugt B8. Nach kleingeschriebener hexadezimaler Formatierung und Bindestrichen lautet das Ergebnis 00112233-4455-4677-b899-aabbccddeeff. Hierbei handelt es sich um ein bewusst festgelegtes Lehrbeispiel und nicht um eine Kennung zur Wiederverwendung in der Produktion. Generieren Sie für jedes reale Objekt ein neues und vergleichen Sie die Versions- und Variantenpositionen selbst.
crypto.randomUUID() als Ein-Aufruf-Verknüpfung – was die neuere Methode für Sie tut und wo sie nicht verfügbar ist
Auf einem sicheren Ursprung führt crypto.randomUUID() die v4-Generierung und -Formatierung in einem Aufruf durch. ToolAcre verwendet es, sofern verfügbar, und greift ansonsten mit den oben genannten expliziten Bitoperationen auf getRandomValues zurück. Die Browserverfügbarkeit unterscheidet sich je nach Kontext: randomUUID ist auf sichere Kontexte beschränkt, während getRandomValues möglicherweise weiterhin auf einer HTTP-LAN-Seite vorhanden ist. Keiner der Zweige greift auf Math.random zurück, nur um eine Schaltfläche scheinbar funktionsfähig zu halten.
Was dies nicht abdeckt – zeitbasierte (v1, v7) und namensbasierte (v3, v5) Versionen, die andere Eingaben als zufällige Bytes benötigen
Dieser Mechanismus beschreibt keine zeitbasierten v1- oder v7-Bezeichner, namensbasierte v3/v5-Bezeichner oder experimentelle v8-Layouts. Zufällige UUIDs haben eine sehr geringe Kollisionswahrscheinlichkeit mit solider Zufälligkeit und keine absolute mathematische Unmöglichkeit einer Kollision. Eine v4-UUID allein sollte nicht als Zugriffskontrollprüfung oder Passwort-Reset-Token verwendet werden, ohne Geheimhaltung, Lebensdauer und Autorisierung unabhängig voneinander zu berücksichtigen.
Fazit: Sichere Zufälligkeit ist die ganze Aufgabe – der UUID-Generator von ToolAcre greift auf dasselbe Browser-CSPRNG zurück, Sie kopieren also das, was Ihr Code erzeugen würde
Sichere Zufälligkeit ist die Aufgabe. Der ToolAcre UUID-Generator nutzt das CSPRNG des Browsers, erzwingt Versions- und Variantenbits und bietet eine Wohlgeformtheitsprüfung für kopierte Werte. Vergleichen Sie ein generiertes Ergebnis mit dem Byte-Layout-Beispiel und verwenden Sie dann die neue, eindeutige Ausgabe nur für die Rolle, die Ihre Anwendung ihr tatsächlich zugewiesen hat.