UUID-Generator (v4 zufällig, v7 zeitgeordnet)

Klicken, um eine oder mehrere UUIDs zu generieren. v4 für vollständig zufällige IDs und v7 für zeitlich sortierbare IDs verwenden, die natürlich nach Erstellungszeit geordnet sind — nützlich für Datenbankschlüssel.

Anzahl:

Wie es funktioniert

Wann v4 vs. v7 verwenden

UUID v4 ist rein zufällig — 122 zufällige Bits mit zwei Versions-/Variantenbits, was etwa 5,3 × 10³⁶ mögliche Werte ergibt. Zwei kollidieren praktisch garantiert nie. v4 überall verwenden, wo keine Reihenfolge benötigt wird, wie API-Anfrage-IDs oder anonyme Nutzerkennungen.

UUID v7 (RFC 9562, veröffentlicht 2024) beginnt mit einem 48-Bit-Unix-Millisekunden-Timestamp, gefolgt von 74 zufälligen Bits. Sie sortieren lexikografisch in Erstellungsreihenfolge, was für die Datenbankleistung enorm ist — Primärschlüssel, die nach Zeit sortieren, bedeuten, dass Einfügungen immer ans Ende des B-Baums gehen, keine zufälligen Seitenteilungen. v7 für neue Datenbank-Primärschlüssel verwenden.

Wie dieser Generator funktioniert

Sowohl v4 als auch v7 verwenden crypto.getRandomValues — die sichere Zufallsquelle des Browsers, dieselbe Grundlage wie HTTPS und Passwort-Manager. v4 füllt 122 Bits zufällig. v7 teilt 48 Bits Timestamp + 74 Bits Zufall plus Versions-/Variantenmarkierungen gemäß RFC.

Die Generierung erfolgt im Browser. Die UUIDs werden weder gespeichert noch übertragen. Wenn 100 v4-UUIDs generiert werden, ist die Kollisionswahrscheinlichkeit astronomisch gering — weit unter der Wahrscheinlichkeit, dass kosmische Strahlen Bits in der CPU umkippen.

Häufige UUID-Fallstricke

v4-UUIDs als Datenbank-Primärschlüssel beeinträchtigen die Leistung im Vergleich zu auto-inkrementierenden Integern, weil zufällige Werte bei Einfügungen B-Baum-Seitenteilungen verursachen. v7 behebt das — v7 verwenden, wenn UUID-Vorteile ohne Index-Schmerzen gewünscht sind.

UUIDs nicht für Nutzer sichtbar machen, wenn Unratbarkeit wichtig ist. v4-UUIDs haben 122 Bits Entropie und sind nicht zu erraten. v7-UUIDs verraten die Erstellungszeit, was für die meisten Anwendungsfälle in Ordnung, aber schlecht ist, wenn die Erstellungszeit sensibel ist.

UUIDs sind 36 Zeichen inkl. Bindestrichen (32 Hex + 4 Bindestriche). Sie benötigen 16 Bytes binär oder 36 Bytes Text. Für Spalten mit sehr hoher Kardinalität in Erwägung ziehen, sie als binären BLOB / nativen UUID-Typ statt VARCHAR(36) zu speichern.

Häufige Fragen

›Sind diese kryptografisch sicher?

Ja. Sowohl v4 als auch v7 verwenden crypto.getRandomValues, die sichere Zufalls-API. v4 hat 122 Bits Entropie; v7 hat 74.

›Warum ist v7 besser für Datenbankschlüssel?

Weil v7-UUIDs nach Erstellungszeit sortieren, gehen Einfügungen immer ans Ende des B-Baum-Index statt an zufällige Positionen. Das vermeidet Seitenteilungen und verbessert den Schreibdurchsatz erheblich.

›Können zwei UUIDs kollidieren?

Theoretisch ja. Mit v4 müssten ~10¹⁸ generiert werden, bevor das 50%-Kollisionsrisiko eintritt. Mit v7 reduziert die Zeitkomponente das auf etwa 2⁷⁴ innerhalb derselben Millisekunde — immer noch praktisch unmöglich.

›Sind UUIDs dasselbe wie GUIDs?

Ja. GUID ist Microsofts Name für UUID. Gleiche Format, gleiche Eindeutigkeitsgarantien.

›Was ist das Format?

8-4-4-4-12 Hex-Stellen mit Bindestrichen. 32 Hex-Zeichen gesamt + 4 Bindestriche = 36 Zeichen. Kleinbuchstaben per RFC-Konvention.

›Soll ich v1 stattdessen verwenden?

v1 enthält die MAC-Adresse, was ein Datenschutzleck ist. v7 löst v1 für zeitgeordnete IDs ab, ohne Hardware-Kennungen preiszugeben.

›Kann ich v4 in URL-sicherem Base64 generieren?

Nicht direkt hier. Die 16 Bytes der UUID als URL-sicheres Base64 kodieren, um eine 22-Zeichen-ID zu erhalten. Nützlich für kürzere URLs.

›Verlassen die Daten meinen Browser?

Nein. Die Generierung erfolgt vollständig im Browser.