Générateur de UUID en Ligne

Un UUID est un identifiant de 128 bits, généralement affiché sur 36 caractères : hexadécimal en 8-4-4-4-12 avec des tirets (ex. : 550e8400-e29b-41d4-a716-446655440000). Il n’est pas sensible à la casse et peut aussi apparaître en 32 caractères hex sans tirets.

Par défaut, utilisez UUIDv7 pour des IDs ordonnés dans le temps, adaptés aux index en base. Utilisez UUIDv4 pour des IDs aléatoires simples lorsque l’ordre n’a pas d’importance. Utilisez UUIDv5 lorsque vous avez besoin d’IDs déterministes dérivés d’un nom.

v4 est purement aléatoire (122 bits aléatoires), simple mais non triable naturellement. v7 encode un horodatage dans les bits de poids fort et de l’aléatoire dans le reste, offrant un tri quasi chronologique avec une bonne imprévisibilité—idéal pour les bases à forte écriture et les journaux.

En pratique oui, dans la plupart des contextes. “GUID” est le terme Microsoft ; “UUID” est le nom normalisé IETF. Les deux désignent des identifiants 128 bits.

Oui avec v7 (conçu pour l’ordre temporel). v1/v6 se trient aussi par temps mais posent des soucis de confidentialité/héritage. v4 est aléatoire et non triable par temps.

Avec un RNG correct, les collisions v4/v7 sont astronomiquement improbables pour des volumes réels. Considérez-les comme uniques ; utilisez un générateur de haute qualité.

Utilisez v5 pour dériver un ID stable à partir d’un espace de noms (DNS, URL) et d’un nom (chaîne d’entrée). Mêmes entrées → même UUID. Utile pour les clés d’idempotence, la déduplication et les références inter-services.

Les UUIDs sont des identifiants, pas des secrets. Ne les utilisez pas pour l’authentification ou l’autorisation. Évitez les données sensibles avec v1 (qui peut révéler l’heure/l’hôte). Préférez v4/v7 et de vrais secrets pour la sécurité.

Préférez les types binaires 16 octets lorsque disponibles (ex. PostgreSQL uuid, MySQL BINARY(16)), pas CHAR(36). Cela économise de l’espace et accélère les comparaisons et les index.

Les bits de poids fort ordonnés dans le temps de v7 améliorent la localité en B-tree, réduisent les splits de pages et accélèrent l’ingestion. L’aléa restant limite la prédictibilité tout en permettant des scans par plage efficaces.

L’UUID nil est tout à zéro : 00000000-0000-0000-0000-000000000000. Il représente une valeur “vide” ou non initialisée ; ne l’utilisez pas pour des entités réelles.

Vérifiez soit 32 hex (compact) soit 8-4-4-4-12 hex avec tirets, insensible à la casse, avec version correcte (nibble 1–8) et variante (8|9|a|b). Rejetez le reste.

Non. L’hexadécimal est insensible à la casse. Normalisez vers un style (souvent minuscule) pour la cohérence des journaux et interfaces.

À éviter. Les UUIDs sont conçus pour être opaques. Si vous avez besoin d’IDs lisibles ou strictement monotones, utilisez des schémas distincts de type ULID/KSUID avec leurs compromis.

Oui pour la plupart des nouveaux développements. v7 conserve les avantages d’ordonnancement sans exposer MAC/détails temporels. Pour migrer, faites du double-write ou un backfill en gardant les clés primaires stables afin d’éviter un re-key massif.

Aucune sémantique. Les tirets améliorent la lisibilité ; le compact économise des octets en texte. Stockez en binaire en interne et choisissez un format de présentation unique en externe.

Oui. Avec v7 (ou v4 + stratégie d’ordre), les bases s’en sortent bien. Assurez des index adaptés, du stockage binaire et faites des benchmarks selon votre charge.

Choisissez un UUID d’espace de noms fixe (DNS/URL/propre namespace) et une chaîne d’entrée stable. Le hachage (SHA-1) produit toujours le même UUID. N’utilisez pas v5 comme secret ; traitez-le uniquement comme identifiant stable.