So erzeugst du UUID v4
Wähle eine Anzahl bis zum festen Limit, Groß- oder Kleinschreibung und optional die Darstellung ohne Bindestriche. Die Zufallsbits bleiben gleich; nur die Textdarstellung ändert sich.
- Gib eine Ganzzahl zwischen 1 und 1000 ein.
- Wähle Klein- oder Großschreibung und ob Bindestriche angezeigt werden.
- Erzeuge die Liste und prüfe das Format der Zielanwendung.
- Kopiere nur die benötigten Werte und behandle UUIDs nicht als Geheimnis.
Beispiele und erwartetes Verhalten
| Eingabe | Ausgabe | Hinweise |
|---|---|---|
1, Kleinbuchstaben, Bindestriche |
550e8400-e29b-41d4-a716-446655440000 |
Das Muster zeigt Version 4 und RFC-Variantbits. |
1, Großbuchstaben |
550E8400-E29B-41D4-A716-446655440000 |
Nur die hexadezimale Schreibweise ändert sich. |
1, ohne Bindestriche |
550e8400e29b41d4a716446655440000 |
32 Hexzeichen; intern dieselben 16 Bytes. |
3 |
Drei unabhängige UUIDs |
Jeder Eintrag nutzt neue kryptografische Zufallsbytes. |
0 oder 1001 |
Validierungsfehler |
Das Mengenlimit schützt die Oberfläche vor Missbrauch. |
crypto.randomUUID nicht vorhanden |
Sicherer getRandomValues-Fallback |
Versions- und Variantbits werden manuell gesetzt; Math.random kommt nicht zum Einsatz. |
Aufbau einer UUID v4
Eine UUID besteht aus 128 Bits und wird gewöhnlich als 8-4-4-4-12 Hexzeichen dargestellt. Bei Version 4 stammen die meisten Bits aus einer kryptografischen Zufallsquelle; vier Bits markieren die Version und zwei bis drei Bits die RFC-Variante.
Die feste Struktur macht Werte interoperabel, garantiert aber keine zentrale Registrierung. Großschreibung und Bindestriche sind Darstellung. Systeme sollten UUIDs semantisch als 16-Byte-Kennung oder standardisierte Zeichenfolge behandeln, nicht als frei formatierten Text.
- Version-Nibble ist 4.
- Variant-Nibble beginnt mit 8, 9, a oder b.
- Mit Bindestrichen sind es 36 Zeichen.
Zufallsquelle und Fallback
Die Implementierung verwendet zuerst crypto.randomUUID. Fehlt es, werden 16 Bytes mit crypto.getRandomValues erzeugt und die vorgeschriebenen Bits gesetzt. Math.random ist für sicherheitsrelevante Kennungen ungeeignet und wird nicht verwendet.
Kryptografischer Zufall macht Kollisionen bei normalen Mengen extrem unwahrscheinlich, aber nicht mathematisch unmöglich. Ein Datenbankschema braucht weiterhin eindeutige Constraints und muss Konflikte korrekt behandeln.
- CSPRNG statt pseudozufälliger UI-Funktion.
- Keine Netzwerkabhängigkeit.
- Unique-Constraint bleibt erforderlich.
Stapelgröße und Darstellung
Bis zu 1000 UUIDs können pro Vorgang erzeugt werden. Das Limit verhindert versehentliche riesige DOM- und Zwischenablageinhalte. Für größere Migrationen sollte die Anwendung server- oder skriptseitig streamen.
Groß-/Kleinschreibung und Entfernen der Bindestriche ändern nur die Ausgabe. Nicht jedes Ziel akzeptiert die kompakte Form; prüfe API-, Datenbank- oder Bibliotheksvertrag.
- Anzahl muss ganzzahlig sein.
- Kompaktform hat 32 Hexzeichen.
- Standardform ist für Austausch am sichersten.
Verwendung und Nicht-Geheimnis
UUID v4 eignet sich für Datensatzschlüssel, Request-IDs, idempotente Client-Entwürfe, Testdaten und verteilte Objekte, wenn keine zentrale Sequenz gewünscht ist. Sie verrät keine Erstellungszeit wie zeitbasierte Varianten.
Eine UUID ist normalerweise öffentlich und kein Zugriffstoken. Ihre Länge macht sie schwer zu erraten, ersetzt aber weder Authentifizierung noch Autorisierung. Verwende echte zufällige Tokens mit passender Entropie und Ablaufregeln für Geheimnisse.
- Gut für Identität, nicht für Berechtigung.
- Keine sortierbare Zeitordnung.
- Keine Inhaltsintegrität.
Kollisionen und Datenbankdesign
Der Zufallsraum ist sehr groß, dennoch sollten Anwendungen nicht „unmöglich“ annehmen. Eindeutige Indizes erkennen Konflikte; ein kontrollierter Retry kann bei Erstellung reagieren.
Zufällige Primärschlüssel können bei manchen B-Tree-Layouts Schreiblokalität verschlechtern. Bewerte Datenbank, Volumen und Zugriffsmuster. Zeit-sortierbare Kennungen sind ein anderes Design mit eigenen Datenschutz- und Standardfragen.
- Unique-Index erzwingen.
- Indexlokalität bei hohem Volumen messen.
- Nicht aus UUID-Reihenfolge auf Zeit schließen.
- Einen seltenen Konflikt kontrolliert behandeln und erneut erzeugen.
Fehler und Grenzen
Fehlende Web-Crypto-Unterstützung, ungültige Mengen und Werte über dem Limit werden gemeldet. Der Generator prüft die lokale Zufalls-API, aber keine spätere Speicherung oder systemweite Eindeutigkeit.
Die Seite erzeugt ausschließlich UUID v4, keine v1, v3, v5, v6, v7, ULID oder NanoID. Sie importiert, analysiert oder signiert vorhandene UUIDs nicht.
- Kein Math.random-Fallback.
- Keine Persistenz oder Historie.
- Keine Garantie außerhalb des erzeugten Formats.
Abgrenzung zu Hash und Zeitstempel
Ein Hash wird aus Inhalt abgeleitet und ändert sich mit den Daten. UUID v4 ist unabhängig vom Inhalt. Ein Unix-Zeitstempel bezeichnet einen Zeitpunkt und kann sich wiederholen; er ist allein keine eindeutige Kennung.
Nutze HMAC oder digitale Signaturen für Authentizität, Hashes für Prüfsummen und UUID v4 für zufällige Identität.