Générateur d'UUID

Générez des identifiants UUID v4 (aléatoires) en masse, directement dans votre navigateur. Plusieurs formats d'affichage disponibles : standard, majuscules, sans tirets, avec accolades et URN.

Aperçu des versions d'UUID

Version Basé sur Description
UUID v1 Horodatage + adresse MAC Généré à partir du moment de création et de l'adresse MAC de la carte réseau. Peut révéler l'appareil d'origine, ce qui pose des problèmes de confidentialité — rarement choisi aujourd'hui pour de nouveaux systèmes.
UUID v3 Espace de noms + hachage MD5 Généré en hachant un espace de noms et une chaîne de nom avec MD5. Déterministe : la même entrée produit toujours le même UUID. En raison des faiblesses de collision connues de MD5, v5 est désormais préféré pour les nouveaux usages.
UUID v4 Entièrement aléatoire Généré à partir d'une source aléatoire cryptographiquement sûre. Ne révèle aucune information sur son origine et est simple à mettre en œuvre, ce qui en fait la variante la plus utilisée. C'est le format généré par cet outil.
UUID v5 Espace de noms + hachage SHA-1 Même approche par espace de noms que v3, mais utilisant SHA-1. Recommandé lorsqu'une génération déterministe est nécessaire, c'est-à-dire reproduire le même ID à partir des mêmes données.
UUID v6 Horodatage réordonné + aléatoire Normalisé dans la RFC 9562 (2024). Réordonne les champs d'horodatage de v1 pour que l'ordre lexicographique des octets corresponde à l'ordre chronologique, améliorant l'efficacité des index de base de données.
UUID v7 Horodatage Unix + aléatoire Normalisé dans la RFC 9562 (2024). Commence par un horodatage Unix à la milliseconde, ce qui permet de trier les ID par ordre de création. De plus en plus adopté comme remplacement de v4 dans les nouveaux projets.

Astuces

  • Chaque UUID est généré entièrement dans votre navigateur via l'API Web Crypto — rien n'est jamais envoyé aux serveurs de toolbase.cc.
  • UUID v4 est le choix naturel dès que vous avez besoin d'unicité sans ID séquentiels ou devinables : clés primaires de base de données, ID de requêtes API, etc.
  • Comme 122 des 128 bits d'UUID v4 sont aléatoires, le risque de collision est astronomiquement faible — il faudrait générer environ 2,7×10¹⁸ UUID avant que cette probabilité atteigne seulement 50 %.
  • Le format « sans tirets » est pratique pour les segments de chemin d'URL ou les noms de fichiers. Le format « avec accolades » correspond à la notation GUID utilisée dans COM/le registre Windows.
  • Augmentez le nombre et utilisez « Tout copier » pour générer rapidement des données de test ou des jeux de données de départ en masse.

Questions fréquentes

Ce n'est pas impossible en théorie, mais avec 122 bits d'aléa, le risque de collision d'UUID v4 est négligeable pour tout usage pratique. Même en générant un milliard d'UUID par seconde pendant cent ans, la probabilité d'une seule collision n'atteindrait qu'environ 50 %.

Oui, il s'agit essentiellement du même concept. GUID (Globally Unique Identifier) est le nom donné par Microsoft à sa propre implémentation, compatible avec le format UUID 128 bits. La notation avec accolades {xxxxxxxx-xxxx-...} est le style GUID courant utilisé dans COM et le registre Windows.

Comme UUID v4 est aléatoire, il tend à produire des index plus volumineux et des insertions plus lentes que des entiers séquentiels (AUTO_INCREMENT). Si vos insertions doivent rester triées par date de création, envisagez UUID v7 (qui intègre un horodatage) ou ULID comme alternative.

Si seule l'unicité compte, UUID v4 est le choix le plus simple et le plus sûr. Utilisez v5 lorsque vous devez reproduire le même ID à partir de la même entrée à chaque fois. Pour les nouveaux projets soucieux de l'ordre de tri ou de l'efficacité d'insertion en base de données, v7 est une excellente option. v1 et v3 sont aujourd'hui rarement adoptés dans les nouveaux projets.
ツールくん

Anecdote — Pourquoi 128 bits ?

L'UUID a été conçu dans les années 1980 par Apollo Computer pour les systèmes distribués, puis normalisé par l'OSF (Open Software Foundation) dans le cadre de DCE (Distributed Computing Environment). La spécification actuelle figure dans la RFC 4122 de l'IETF (2005), avec une version étendue, la RFC 9562, publiée en 2024.

128 bits peut sembler excessif, mais c'est justement cette longueur qui permet à plusieurs serveurs ou appareils de générer des ID de manière totalement indépendante, sans aucune coordination, tout en évitant les collisions en pratique. Un serveur central attribuant des numéros séquentiels évite ce hasard, mais devient un point de défaillance unique et exige un aller-retour réseau pour chaque ID. Les UUID suppriment entièrement ce coût de coordination, au prix d'une aléatoirité suffisante pour rendre la probabilité de collision négligeable.

Ce même hasard est aussi le talon d'Achille d'UUID v4 : insérer des valeurs aléatoires dans un index de base de données de type B-tree disperse les points d'insertion, provoquant de fréquentes divisions de page et nuisant aux performances. UUID v7 a été conçu précisément pour corriger cela — en commençant par un horodatage Unix, il reste triable par date de création tout en conservant assez d'aléa pour éviter la prévisibilité, ce qui donne aux insertions une bien meilleure localité.