À quoi servent les UUID
Un UUID (Universally Unique Identifier), aussi appelé GUID dans les écosystèmes Microsoft, est une valeur de 128 bits écrite sous une forme textuelle standard, par exemple :
550e8400-e29b-41d4-a716-446655440000
Les systèmes utilisent des UUID lorsqu’ils ont besoin d’identifiants extrêmement peu susceptibles d’entrer en collision sans allocateur central : clés primaires dans des services distribués, IDs de message, poignées d’upload et noms de ressources dans les APIs. L’unicité est probabiliste (ou dérivée de noms), et non prouvée par une consultation de registre global à chaque création d’ID.
Générez un exemple avec Générer un UUID, puis vérifiez le format et les champs de version avec Valider un UUID.
Sous-outils de cette famille
- Générer un UUID — crée des UUID en versions 1, 3, 4 ou 5, avec des entrées namespace et name optionnelles lorsque ces versions les exigent.
- Valider un UUID — vérifie qu’une chaîne respecte la structure UUID et signale les points de validité pour les versions 1 à 5.
Génération et validation sont complémentaires : créez des IDs dans la version attendue par votre schéma, puis validez les chaînes fournies par les utilisateurs ou importées avant de les accepter comme clés étrangères ou de cache.
Versions que vous rencontrerez vraiment
Version 4 (aléatoire). Le choix le plus courant pour les IDs d’applications nouvelles. La plupart des bits sont aléatoires via un CSPRNG ; les bits de version et de variante sont fixés selon RFC 4122. Les collisions sont négligeables aux volumes pratiques si le générateur est sain.
Version 1 (basée sur le temps). Intègre un horodatage et un identifiant de nœud (historiquement une adresse MAC). Utile pour un ordre temporel approximatif, mais peut fuiter l’heure de création et l’identité de la machine — les contextes sensibles à la vie privée préfèrent souvent v4 ou des schémas plus récents.
Version 3 (basée sur un nom avec MD5) et version 5 (basée sur un nom avec SHA-1). Dérivent un UUID d’un namespace UUID plus une chaîne name. Le même namespace+name produit toujours le même UUID — pratique pour des IDs stables à partir d’URLs ou de noms d’utilisateur sans table de correspondance. Pour les nouveaux designs, v5 est préféré à v3 car la dérivation utilise SHA-1 plutôt que MD5.
D’autres versions et propositions suivantes (par exemple UUIDv7 triable par le temps dans des RFCs plus récents) apparaissent dans les stacks modernes ; lorsque votre plateforme documente une version précise, respectez-la plutôt que de mélanger les politiques.
Format texte et bits de variante
Le texte canonique utilise cinq groupes hexadécimaux 8-4-4-4-12. Les analyseurs doivent accepter l’hex en majuscules ou minuscules. Le nibble de version se trouve dans le troisième groupe ; les bits de variante dans le quatrième. Une validation qui ne vérifie que « ressemble à de l’hex avec des tirets » est plus faible qu’une validation qui contrôle aussi la cohérence version/variante du type affirmé.
Certaines APIs acceptent la forme URN (urn:uuid:…) ou des GUID entre accolades {…}. Normalisez avant de comparer. Le stockage binaire fait 16 octets ; la forme texte sert aux humains et au JSON.
Choisir les IDs avec discernement
Quand les UUID aident. Clés primaires favorables aux fusions, création d’IDs hors ligne, masquage des compteurs de lignes séquentiels aux clients.
Quand ils gênent. De très grandes clés primaires aléatoires peuvent fragmenter les index B-tree davantage que des entiers séquentiels — mesurez pour votre base. La journalisation et le support deviennent plus difficiles si chaque ID est opaque ; associez des numéros de dossier lisibles lorsque les opérateurs en ont besoin.
Stabilité. Pour v3/v5 basés sur un nom, documentez le namespace UUID standardisé par votre organisation (DNS, URL, OID ou racine personnalisée). Changer le namespace régénère silencieusement un ID différent pour le même name.
Notes de sécurité
Les valeurs UUIDv4 sont des identifiants, pas des secrets d’authentification. Deviner un ID v4 non listé reste difficile — ne le traitez pas comme une autorisation à lui seul ; appliquez toujours le contrôle d’accès. Évitez v1 si des bits de nœud dérivés de MAC révéleraient l’identité matérielle sur des documents publics. N’incorporez pas de mots de passe ni de PANs dans les chaînes name pour v3/v5.
Erreurs courantes
- Générer du v4 puis ne stocker que la première moitié « pour gagner de la place », détruisant les garanties d’unicité.
- Comparaisons de chaînes sensibles à la casse entre systèmes qui normalisent différemment.
- Utiliser l’UUID nil (
00000000-0000-0000-0000-000000000000) comme vraie clé d’entité. - Supposer que la validation du format implique que l’ID existe dans votre base.
- Mélanger plusieurs générateurs avec des politiques de version différentes pour la même colonne.
Limites et environnement
Ces outils aident à créer et inspecter des UUID de style RFC dans le navigateur pour le développement et l’apprentissage. Ils n’allouent pas d’IDs depuis les séquences de votre base de production et ne garantissent pas l’unicité globale face à des RNGs défaillants.
Résumé
Les UUID fournissent des identifiants de 128 bits sous forme hex standard, avec des versions pour une génération aléatoire, temporelle et basée sur un nom. Ce hub associe un générateur multi-versions et un validateur pour créer des IDs conformes à votre schéma et rejeter tôt les chaînes mal formées. Préférez v4 pour un usage général, v5 pour des IDs stables dérivés d’un nom, et appliquez toujours l’autorisation séparément de l’opacité de l’identifiant.