Jede UUID-Version — v1 bis v8 — mit Strukturdiagrammen, Anwendungsfällen, Kollisionsrisiko und JavaScript-Codebeispielen.
Struktur
timestamp (60-bit) + clock seq (14-bit) + MAC (48-bit)
Kollisionsrisiko
Very low
Vorteile
Nachteile
Am besten geeignet für
Legacy systems. Avoid in new projects due to MAC address exposure.
Struktur
MD5(namespace UUID + name) → UUID
Kollisionsrisiko
MD5 collision risk (low for UUIDs)
Vorteile
Nachteile
Am besten geeignet für
Generating UUIDs from URLs, email addresses, or other stable identifiers. Use v5 instead.
Struktur
122 random bits + 4-bit version + 2-bit variant
Kollisionsrisiko
Negligible (2^122 possibilities)
Vorteile
Nachteile
Am besten geeignet für
Default choice for most applications. IDs for records, sessions, tokens.
Struktur
SHA-1(namespace UUID + name) → UUID (top 128 bits)
Kollisionsrisiko
SHA-1 — extremely low for UUID purposes
Vorteile
Nachteile
Am besten geeignet für
Deterministic IDs from a namespace + name. Example: UUID for 'https://example.com' is always the same.
Struktur
Unix ms timestamp (48-bit) + version (4-bit) + random (74-bit)
Kollisionsrisiko
Very low (74 random bits)
Vorteile
Nachteile
Am besten geeignet für
Database primary keys where sort order matters. Replaces v1 for time-ordered UUIDs.
Struktur
128 bits, content defined by the implementation
Kollisionsrisiko
Depends on implementation
Vorteile
Nachteile
Am besten geeignet für
Experimental or vendor-specific use cases where v1–v7 don't fit.
| Version | Method | Sortable | Privacy-safe | Deterministic |
|---|---|---|---|---|
| v1 | Time + MAC | ✅ | ❌ (MAC leak) | ❌ |
| v3 | MD5 hash | ❌ | ✅ | ✅ |
| v4 | Random | ❌ | ✅ | ❌ |
| v5 | SHA-1 hash | ❌ | ✅ | ✅ |
| v7 | Time + Random | ✅ | ✅ | ❌ |
| v8 | Custom | — | — | — |
// JavaScript / Node.js (built-in, Node 15+)
import { randomUUID } from 'crypto';
const v4 = randomUUID(); // → "550e8400-e29b-41d4-a716-446655440000"
// Browser
const v4 = crypto.randomUUID();
// UUID v7 (npm: uuid package v10+)
import { v7 as uuidv7 } from 'uuid';
const v7 = uuidv7(); // → "018f0b2d-4c9e-7abc-89de-f012345678ab"
// Python
import uuid
v4 = str(uuid.uuid4()) # Random
v5 = str(uuid.uuid5(uuid.NAMESPACE_URL, 'https://example.com'))
# PostgreSQL
SELECT gen_random_uuid(); -- v4 (pg 13+)
SELECT uuid_generate_v4(); -- v4 (uuid-ossp extension)
SELECT gen_random_uuid()::text; -- as textEine UUID (Universally Unique Identifier) ist ein 128-Bit-Bezeichner, der in RFC 4122 standardisiert ist. Sie wird als 8-4-4-4-12 hexadezimale Zeichen formatiert, die durch Bindestriche getrennt sind, z. B.: 550e8400-e29b-41d4-a716-446655440000. UUIDs sind so konzipiert, dass sie ohne zentrale Autorität im Raum und über die Zeit eindeutig sind.
Verwende v4 für die meisten allgemeinen Zwecke — sie wird zufällig generiert und hat eine extrem geringe Kollisionswahrscheinlichkeit. Verwende v7, wenn du zeitlich geordnete UUIDs für Datenbankprimärschlüssel benötigst (bessere Indexleistung als v4). Verwende v5 für deterministische UUIDs aus einem Namespace+Name-Paar. Vermeide v1 in neuen Projekten, da es die MAC-Adresse preisgibt.
UUID v4 ist rein zufällig (122 zufällige Bits). UUID v7 kodiert einen Unix-Zeitstempel in den ersten 48 Bits, gefolgt von zufälligen Bits. Dies macht v7-UUIDs nach Erstellungszeit sortierbar, was die B-Tree-Indexleistung in Datenbanken im Vergleich zu zufälligen v4-UUIDs erheblich verbessert.
Praktisch gesehen ja. UUID v4 hat 122 zufällige Bits und bietet 2^122 ≈ 5,3 × 10^36 mögliche Werte. Um eine 50%ige Kollisionswahrscheinlichkeit zu erreichen, müssten etwa 2,7 × 10^18 UUIDs generiert werden — weit mehr als jede realistische Anwendung.