Générateur UUID
Générer et valider les UUIDs. Rapide, sécurisé et fonctionne hors ligne.
Générateur UUID/ULID
🔍 Need help choosing? Click for specific use cases
Validateur UUID/ULID
UUID/ULID Information
📚 Documentation officielle:
- • RFC 4122 - Spécification UUID originale (v1-v5)
- • RFC 9562 - Spécification UUID mise à jour (v6-v8, 2024)
- • ULID Specification - Spécification ULID canonique
- • Wikipedia: UUID - Aperçu complet
⏰ UUID v1 - Basé sur le temps (legacy)
Use case: Clés primaires de base de données, systèmes legacy, systèmes distribués nécessitant un ordre temporel
Pros: Excellent pour l'indexation de base de données, tri chronologique naturel, unique dans l'espace et temps
Cons: Contient adresse MAC et horodatage - considérer implications confidentialité pour applications publiques
⚠️ UUID v2 - Sécurité DCE (Réservé)
Réservé pour UUIDs de sécurité DCE (Distributed Computing Environment). Rarement utilisé à cause de sa complexité. Voir https://fr.wikipedia.org/wiki/Distributed_Computing_Environment
⚠️🔐 UUID v3 - Hash MD5 (déprécié)
Use case: Quand vous avez besoin du même UUID pour la même entrée à chaque fois
Example: Utilisateur "john@example.com" obtient toujours UUID "550e8400-e29b-41d4-a716-446655440000". Parfait pour migration ou sync données.
Good for: Migration utilisateurs, synchronisation données, UUIDs reproductibles entre systèmes
Note: Déprécié: MD5 a des failles de sécurité. Utilisez v5 pour nouveaux projets nécessitant UUIDs déterministes
🎲 UUID v4 - Aléatoire (Plus populaire)
Use case: Usage général, APIs, IDs de session, identifiants de fichiers
Example: IDs utilisateur, IDs commande - tout nécessitant unicité sans ordre temporel
Why popular: Simple, sécurisé, aucune dépendance sur MAC/temps
Database caveat: Nature aléatoire peut causer fragmentation index et mauvaises performances insertion
🔐 UUID v5 - Hash SHA-1
Use case: Identique à v3 - UUIDs déterministes à partir de noms
Example: Même concept que v3 mais cryptographiquement sécurisé
Good for: Alternative préférée à v3 pour tous nouveaux projets
⏰ UUID v6 - Ordonné temporellement (RFC 9562)
Design: Identique à v1 mais avec bits horodatage réordonnés du plus au moins significatif
Use case: Performance base de données avec tri lexicographique par temps création
Advantage: Permet tri UUIDs par temps création simplement en triant lexicographiquement, contrairement v1
⏰ UUID v7 - Horodatage Unix (RFC 9562)
Design: Horodatage Unix 48-bit + 80-bit aléatoire (concept similaire ULID)
Use case: Applications modernes nécessitant IDs triables avec horodatages Unix
Benefits: Triable lexicographiquement, format UUID standard, excellente performance base données
⏰ ULID - Triable lexicographiquement
Design: Horodatage 48-bit + 80-bit aléatoire, encodé Base32 (26 caractères)
Use case: APIs et bases de données où vous voulez IDs lisibles et triables
Features: URL-safe, insensible à la casse, triable lexicographiquement, précision milliseconde
ULID vs UUID v7 - Contexte historique 📚
Timeline: ULID a été créé en premier pour résoudre problèmes triabilité UUID
UUID v7 inspiration: UUID v7 (RFC 9562, 2024) s'est inspiré du design ULID
Key difference: ULID utilise encodage Base32 (26 chars), UUID v7 utilise format UUID standard (36 chars)
Current trend: UUID v7 devient préféré pour nouveaux projets grâce standardisation officielle
💡 Cas d'usage courants:
- General purpose: Apps web et APIs: v4 (largement supporté, mais éviter comme clés primaires DB)
- Database keys: Clés primaires BDD: v6, v7, ou ULID (meilleures performances insertion)
- Time-ordered data: Tri chronologique: v1, v6, v7, ou ULID
- Deterministic UUIDs: Même entrée = même UUID: v5 (ou v3 pour legacy)
- Legacy systems: Systèmes existants: Garder version actuelle
- Public APIs: APIs externes: v4 ou ULID