Structure
timestamp (60-bit) + clock seq (14-bit) + MAC (48-bit)
Risque de collision
Very low
Avantages
Inconvénients
Meilleur usage
Legacy systems. Avoid in new projects due to MAC address exposure.
Structure
MD5(namespace UUID + name) → UUID
Risque de collision
MD5 collision risk (low for UUIDs)
Avantages
Inconvénients
Meilleur usage
Generating UUIDs from URLs, email addresses, or other stable identifiers. Use v5 instead.
Structure
122 random bits + 4-bit version + 2-bit variant
Risque de collision
Negligible (2^122 possibilities)
Avantages
Inconvénients
Meilleur usage
Default choice for most applications. IDs for records, sessions, tokens.
Structure
SHA-1(namespace UUID + name) → UUID (top 128 bits)
Risque de collision
SHA-1 — extremely low for UUID purposes
Avantages
Inconvénients
Meilleur usage
Deterministic IDs from a namespace + name. Example: UUID for 'https://example.com' is always the same.
Structure
Unix ms timestamp (48-bit) + version (4-bit) + random (74-bit)
Risque de collision
Very low (74 random bits)
Avantages
Inconvénients
Meilleur usage
Database primary keys where sort order matters. Replaces v1 for time-ordered UUIDs.
Structure
128 bits, content defined by the implementation
Risque de collision
Depends on implementation
Avantages
Inconvénients
Meilleur usage
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 textLes ULID sont une alternative compacte : horodatage de 48 bits + 80 bits aléatoires, encodés en 26 caractères Crockford Base32. Ils se trient lexicographiquement par date de création.
Les identifiants séquentiels sont plus simples et plus efficaces pour les applications à base de données unique. Utilisez les UUID quand vous avez besoin de :
-- PostgreSQL: native UUID type (16 bytes, efficient)
CREATE TABLE users (
id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
name TEXT NOT NULL
);
-- MySQL: store as BINARY(16) for performance
CREATE TABLE users (
id BINARY(16) PRIMARY KEY,
name VARCHAR(255) NOT NULL
);
UUID v4 utilise 122 bits d'aléatoire provenant d'une source cryptographique, ce qui fournit une bonne entropie. Cependant, pour les jetons de sécurité (clés API, identifiants de session), il est préférable d'utiliser des formats de jetons conçus à cet effet avec des propriétés supplémentaires comme les sommes de contrôle, l'encodage d'expiration ou l'identification par préfixe. Les UUID servent à l'identité, pas à l'authentification.
Un UUID (Universally Unique Identifier) est un identifiant de 128 bits standardisé dans RFC 4122. Il est formaté en 8-4-4-4-12 caractères hexadécimaux séparés par des tirets. Ils sont conçus pour être uniques dans l'espace et le temps sans autorité centrale.
Utilisez v4 pour la plupart des usages généraux — elle est générée aléatoirement et a une probabilité de collision extrêmement faible. Utilisez v7 si vous avez besoin d'UUIDs ordonnés par temps pour les clés primaires de base de données. Utilisez v5 pour des UUIDs déterministes à partir d'une paire namespace+nom.
UUID v4 est purement aléatoire (122 bits aléatoires). UUID v7 encode un timestamp Unix dans les 48 premiers bits suivi de bits aléatoires. Cela rend les UUIDs v7 triables par date de création, améliorant significativement les performances d'index B-tree.
Pratiquement oui. UUID v4 a 122 bits aléatoires, donnant 2^122 ≈ 5,3 × 10^36 valeurs possibles. Pour avoir 50% de chance de collision, il faudrait générer environ 2,7 × 10^18 UUIDs.