Générateur d’UUID

• Générateur de hash
• Encodeur/décodeur Base64
• Tous les convertisseurs

Les UUID vous donnent des identifiants dont la probabilité de collision entre systèmes est extrêmement faible, ce qui simplifie les clés primaires dans les bases distribuées, les ID de ressources dans les API, les jetons de session et le nommage de fichiers sans allocateur central.

Avantages des UUID

• Unicité : Probabilité de collision très faible lorsqu’ils sont générés correctement, afin que des services indépendants puissent créer des ID en toute sécurité.
• Systèmes distribués : Les clients ou services peuvent créer des ID sans appeler une séquence centrale.
• Clés de base de données : Couramment utilisés comme clés primaires substituts lorsque les clés naturelles sont gênantes ou que les schémas faciles à fusionner comptent.
• Plus difficiles à deviner : Les valeurs v4 aléatoires n’exposent pas de compteurs séquentiels, ce qui limite l’énumération triviale (ce n’est pas un substitut à une authentification correcte).
• Normalisés : La RFC 4122 définit les formats et les bits de version pour que les outils et langages interopèrent.

Cet outil se concentre sur les deux versions les plus utilisées par les développeurs. Choisissez celle qui correspond à vos besoins d’ordre, de confidentialité et de compatibilité.

Versions disponibles ici

• UUID v4 (aléatoire) : Utilise des données aléatoires ou pseudo-aléatoires pour la charge utile ; choix par défaut recommandé pour les nouveaux projets.
• UUID v1 (basé sur l’heure) : Incorpore un horodatage ; utile lorsqu’un comportement monotone ou triable par le temps aide, avec d’autres caractéristiques de fuite que les ID purement aléatoires.

Quelques précisions évitent les surprises lorsque vous stockez, indexez ou comparez des chaînes UUID.

Référence rapide

• Un UUID fait 128 bits et s’affiche souvent comme 32 chiffres hexadécimaux selon le motif 8-4-4-4-12 avec tirets.
• L’UUID v4 expose 122 bits d’aléa dans la charge utile (les bits de version et de variante sont fixés).
• Les chaînes UUID sont plus longues que des clés entières ; la conception des index et du stockage doit en tenir compte.
• Minuscules ou majuscules en hexadécimal relève de la présentation ; les comparaisons sont en général insensibles à la casse.
• La RFC 4122 définit d’autres versions (par ex. v3, v5) ; cette page ne génère que v1 et v4.

Bonnes pratiques

Utilisez la bonne version pour votre modèle de menace et votre couche de stockage, et considérez les UUID comme des identifiants, pas comme des secrets à eux seuls.

• Préférez l’UUID v4 pour des ID uniques d’usage général sauf raison claire d’utiliser v1.
• Stockez les UUID de façon cohérente (chaîne ou binaire) et indexez selon les recommandations de votre base.
• Ne vous fiez pas seul à l’aléa des UUID pour sécuriser des ressources sensibles ; appliquez toujours une autorisation.
• Pour des taux d’insertion très élevés, mesurez l’impact des clés UUID en chaîne sur la fragmentation des arbres B par rapport aux ID séquentiels.
• Lorsque vous exposez des ID dans des URL, combinez imprévisibilité et contrôle d’accès adapté aux données.

Cas d’usage typiques

• Clés primaires de base de données : Clés substituts qui fusionnent proprement entre partitions ou clients hors ligne.
• Ressources d’API : Identifiants stables et opaques dans les réponses JSON et les liens hypermédia.
• ID de session et de corrélation : Suivre des requêtes ou des sessions sans compteur partagé.
• Workers distribués : Les workers génèrent des ID de tâches ou de fichiers sans contacter un coordinateur.
• Noms de fichiers uniques : Évitent les collisions lors du téléversement ou de la mise en cache de contenu utilisateur.