Décodeur d'UUID

Que contient un UUID ?

Un UUID fait 128 bits, écrits d'ordinaire en 32 chiffres hexadécimaux répartis en cinq groupes séparés par des tirets. La plupart de ces bits varient selon la version, mais six ne varient jamais : quatre énoncent la version et deux marquent la variante. C'est pourquoi tout UUID de version 4 commence son troisième groupe par un 4 littéral, et pourquoi le quatrième groupe commence presque toujours par 8, 9, a ou b.

Ce sont ces six bits que lit cette page. La version dit comment l'UUID a été fabriqué — à partir de hasard, d'un nom haché ou d'une horloge — et donc ce que l'on peut encore en apprendre. La variante dit quelle disposition il suit, ce qui compte car deux des quatre variantes sont antérieures à la norme que tout le monde emploie.

La spécification en vigueur est le RFC 9562, publié en mai 2024, qui a purement et simplement remplacé le RFC 4122. Il a ajouté les versions 6, 7 et 8 ainsi que l'UUID maximal : un décodeur écrit avant cette date ne reconnaît même pas un UUID de version 7 — or la version 7 est justement celle que l'on emploie de plus en plus pour les nouvelles clés de base de données.

Comment l'utiliser

1. Collez l'UUID. Avec tirets, en hexadécimal brut, entre accolades ou préfixé urn:uuid: — les quatre formes sont acceptées, et la casse est indifférente.
2. Lisez la version et la variante. Chacune est expliquée et pas seulement nommée, y compris ce qu'elle implique sur l'origine des bits. Les versions nouvelles du RFC 9562 sont signalées.
3. Vérifiez s'il y a une heure dedans. Les versions 1, 6 et 7 encodent un instant, que l'outil décode exactement. Les autres n'en portent aucun, et l'outil le dit au lieu de vous montrer un nombre.

L'horloge qui démarre en 1582

Les UUID de version 1 portent un horodatage de 60 bits, que la spécification définit comme un décompte d'intervalles de 100 nanosecondes depuis 00:00:00,00 le 15 octobre 1582 — jour de l'entrée en vigueur du calendrier grégorien. Un UUID engendré ce matin compte depuis le seizième siècle, en dix-millionièmes de seconde.

Ce n'est pas une bizarrerie repérée après coup : le RFC lui-même la critique. En expliquant pourquoi la version 7 existe, il qualifie cette époque de peu courante et difficile à représenter avec précision dans un format numérique standard, et le reproche est fondé : 60 bits de tops de cent nanosecondes n'entrent pas dans le nombre à virgule flottante que la plupart des langages fournissent par défaut. Cette page conserve le décompte en entier exact et ne convertit qu'une fois, à la fin.

La version 6 est la même horloge, champs réordonnés pour que la partie de poids fort vienne en premier, ce qui fait que les UUID se trient chronologiquement comme de simples chaînes. La version 7 abandonne complètement l'époque grégorienne et range de banales millisecondes Unix dans les 48 premiers bits. Les trois UUID d'exemple de la spécification encodent le même instant, et les décoder ici donne trois fois la même réponse.

La version 7 annonce à tous quand elle a été créée

La version 7 est aujourd'hui la recommandation courante pour les clés primaires de base de données, et la raison est réelle : l'horodatage venant en tête, les identifiants se trient par instant de création et s'insèrent donc en fin d'index au lieu de s'éparpiller. Cela règle un vrai problème de performance que causent les clés aléatoires de version 4.

Ce que l'on dit bien moins, c'est l'autre conséquence. L'heure de création n'est pas rangée à côté de l'identifiant : elle est les 48 premiers bits de l'identifiant, et aucun réglage ne la désactive. Quiconque voit un UUID de version 7 connaît la milliseconde de sa génération. Si ces identifiants apparaissent dans des URL, dans des réponses d'API, dans des tickets de support ou dans quoi que ce soit qu'un client puisse voir, vous avez publié vos horodatages de création — et, avec deux d'entre eux, l'intervalle entre deux événements.

C'est souvent sans conséquence et parfois non : des clés d'allure séquentielle permettent à un tiers d'estimer combien d'enregistrements vous créez par heure, et une heure de création qui fuit peut suffire à rapprocher un enregistrement anonyme d'un événement connu. C'est une raison de réfléchir au trajet de l'identifiant, non d'écarter la version 7 — mais cela devrait être une décision, pas une surprise.

La version 4, à l'inverse, ne contient rien. 122 de ses 128 bits sont aléatoires et les six autres sont les marqueurs fixes de version et de variante : un UUID de version 4 ne révèle donc que le fait d'être un UUID de version 4. Si un décodeur vous en affiche une date, il l'a inventée.

Ce que cela ne vous dit pas

Cela ne dit pas si l'UUID est réel. N'importe quels 32 chiffres hexadécimaux ayant les six bons bits aux bons endroits se décodent parfaitement, que quelque chose les ait engendrés ou non. La vérification est structurelle, pas existentielle.

Pour la version 1, l'outil décode l'heure mais ne dit rien du champ de nœud, qui dans la conception d'origine était l'adresse de la carte réseau de la machine. C'est précisément pour cela que la version 1 est tombée en désuétude pour tout usage public, et restituer cette donnée n'est pas un service qui mérite d'être rendu.

Les versions 3 et 5 sont des condensats d'un nom dans un espace de noms, et un condensat ne se remonte pas : l'UUID dérive de l'entrée, mais l'entrée ne se retrouve pas depuis l'UUID. Quant à la version 8, elle est délibérément non spécifiée — la norme ne définit que ses bits de version et de variante et se tait sur le reste, il n'y a donc rien à décoder au-delà de ce que cette page montre déjà.

Pourquoi est-ce gratuit ?

Ce sont des décalages de bits sur 128 bits, exécutés dans votre navigateur. Aucune consultation, aucun serveur, aucun compte.

Rien de ce que vous collez n'est envoyé, conservé ni journalisé — et cela compte ici, car un UUID issu de votre propre système identifie l'un de vos enregistrements. Il ne quitte jamais l'onglet.