Décodeur UUID

Décode et inspecte la structure, la version et les données intégrées des UUID

Essayer un exemple

Entrée UUID

Collez un UUID ci-dessus pour l'inspecter

Structure UUID

Un UUID (Universally Unique Identifier) est une valeur de 128 bits représentée sous forme de 32 chiffres hexadécimaux divisés en cinq groupes par des tirets :

Format
xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx
xxxxxxxx (8)8 chiffres hexadécimaux — 32 bits
xxxx (4)4 chiffres hexadécimaux — 16 bits
Mxxx (4)4 chiffres hexadécimaux — 16 bits. Le premier chiffre M encode la version UUID (1-8).
Nxxx (4)4 chiffres hexadécimaux — 16 bits. Le premier chiffre N encode la variante UUID (RFC 4122, NCS, Microsoft ou réservé).
xxxxxxxxxxxx (12)12 chiffres hexadécimaux — 48 bits

La version et la variante sont les deux seuls champs garantis d'être présents dans chaque UUID. Tous les autres champs dépendent de la version.

Le champ de version

Le nibble de version est le premier chiffre hexadécimal du troisième groupe (position 14 dans la chaîne complète). Il identifie la version UUID utilisée pour générer l'identifiant.

JavaScript
const hex = uuid.replace(/-/g, '')
const version = parseInt(hex[12], 16)  // single hex digit → 1, 2, 3, 4, 5, 6, 7, or 8

La version 7 (UUID v7) est la version la plus récente largement utilisée, introduite dans RFC 9562 (2024). Elle encode un horodatage Unix en millisecondes dans les bits de poids fort pour la triabilité.

Le champ de variante

La variante est encodée dans les bits de poids fort du premier octet du quatrième groupe. Elle identifie les conventions de disposition et d'ordre des octets utilisées par l'UUID.

Bits de poids fortPlage du premier chiffre hexadécimalVarianteDescription
0xxx xxxx0x00–0x7FCompatibilité ascendante NCSUUID NCS (Network Computing System) legacy. Réservé pour la compatibilité ascendante.
10xx xxxx0x80–0xBFRFC 4122 / RFC 9562La variante UUID standard RFC 4122 / RFC 9562. Utilisée par toutes les versions UUID modernes (v1-v8).
110x xxxx0xC0–0xDFCompatibilité ascendante MicrosoftGUID Microsoft COM/DCOM legacy avec un ordre d'octets différent. Encore rencontré dans les composants COM Windows.
111x xxxx0xE0–0xFFRéservéRéservé pour une définition future. Non utilisé par aucune version UUID actuelle.

En pratique, la quasi-totalité des UUID que vous rencontrez utilisent la variante RFC 4122 / RFC 9562 (modèle de bits 10xx xxxx, premier octet du quatrième groupe dans la plage 0x80–0xBF). Les variantes NCS, Microsoft COM et Reserved sont des formats hérités rarement rencontrés dans les systèmes modernes.

Référence des versions UUID

RFC 4122 a défini les versions 1-5. RFC 9562 (2024) a ajouté les versions 6, 7 et 8 :

VersionNomStandardDescription
v1Basé sur le tempsRFC 4122Horodatage (epoch grégorien, précision 100ns) + adresse MAC. Séquentiel par hôte mais divulgue l'identité de l'hôte.
v2Sécurité DCERFC 4122Basé sur UUID v1 avec le champ time_low remplacé par un UID/GID POSIX. Rarement utilisé en dehors des systèmes DCE/RPC legacy.
v3Basé sur un nom MD5RFC 4122Déterministe : hachage MD5 d'un UUID d'espace de noms + chaîne de nom. Les mêmes entrées produisent toujours le même UUID. Préférez v5.
v4AléatoireRFC 4122122 bits de caractère aléatoire cryptographiquement sécurisé. La version UUID la plus commune à usage général.
v5Basé sur un nom SHA-1RFC 4122Comme v3 mais utilise SHA-1. Plus résistant aux collisions que MD5. Préféré à v3 pour les nouveaux UUID basés sur un nom.
v6Temps réordonnéRFC 9562Réordonne les champs d'horodatage UUID v1 pour que l'UUID soit triable chronologiquement. Défini dans RFC 9562.
v7Temps UnixRFC 9562Horodatage Unix de 48 bits en millisecondes dans les bits de poids fort + données aléatoires. Triable et adapté aux index B-tree. Préféré pour les nouveaux identifiants ordonnés dans le temps.
v8PersonnaliséRFC 9562Forme libre : tous les bits sauf la version et la variante sont définis par l'application. Aucun algorithme de génération n'est spécifié.

Décodage des horodatages UUID v1

UUID v1 intègre un horodatage grégorien de 60 bits (intervalles de 100 nanosecondes depuis le 15 octobre 1582) réparti sur trois champs : time_low (bits 0-31), time_mid (bits 32-47) et time_hi (bits 48-59). Cet outil les réassemble et les convertit en date UTC standard.

JavaScript
// UUID v1: 6ba7b810-9dad-11d1-80b4-00c04fd430c8
//           ^^^^^^^^ ^^^^ ^^^^ ^^^^^ ^^^^^^^^^^^^
//           time-low  mid  hi  clk   node (MAC)
//                          ^
//                          version nibble (1)

const hex = '6ba7b8109dad11d180b400c04fd430c8'

const tLow = parseInt(hex.slice(0, 8),  16)  // 0x6ba7b810
const tMid = parseInt(hex.slice(8, 12), 16)  // 0x9dad
const tHi  = parseInt(hex.slice(13, 16), 16) // 0x1d1 (skip version nibble at index 12)

// Reconstruct 60-bit timestamp (100-ns intervals since Oct 15, 1582)
const t = (BigInt(tHi) << 48n) | (BigInt(tMid) << 32n) | BigInt(tLow)

// Subtract Gregorian offset (Oct 15, 1582 → Jan 1, 1970 in 100-ns units)
const GREGORIAN_OFFSET = 122192928000000000n
const unixMs = (t - GREGORIAN_OFFSET) / 10000n

console.log(new Date(Number(unixMs)).toISOString())
// → 1998-02-04T22:13:53.578Z
Note:Le champ de séquence d'horloge (14 bits) empêche les doublons quand l'horloge recule. Le champ node (48 bits) est généralement l'adresse MAC de l'hôte générateur.

UUID v1 doit être traité comme sensible : l'adresse MAC intégrée et l'horodatage précis peuvent identifier à la fois la machine génératrice et le temps de génération.

Décodage des horodatages UUID v7

UUID v7 intègre un horodatage Unix de 48 bits en millisecondes dans les 48 premiers bits (premier groupe + 4 premiers chiffres du deuxième groupe). Cet outil lit ces bits et les convertit en date UTC avec une précision milliseconde.

JavaScript
// UUID v7: 018e4bc8-1000-7000-8000-000000000001
//           ^^^^^^^^^^^^
//           48-bit Unix ms timestamp

const hex = '018e4bc8100070008000000000000001'

// First 48 bits (12 hex chars) = Unix timestamp in milliseconds
const ms = parseInt(hex.slice(0, 12), 16)  // 0x018e4bc81000

console.log(new Date(ms).toISOString())
// → 2024-03-11T…Z

// Everything after byte 6 is random (except version/variant bits)

Contrairement à UUID v1, l'horodatage UUID v7 utilise l'epoch Unix familier (1er janvier 1970) et n'intègre aucune information sur l'hôte. Les 74 bits restants sont aléatoires.

Comment cet outil détecte la version et la variante UUID

Le décodeur lit la position 14 (nibble de version) et la position 19 (nibble de variante) de la chaîne UUID canonique. Aucun état externe ni contexte n'est nécessaire — toute l'information est contenue dans la chaîne UUID.

JavaScript
// Detect UUID version from the 13th hex character (index 12)
function uuidVersion(uuid) {
  const clean = uuid.replace(/-/g, '')
  return parseInt(clean[12], 16)
}

uuidVersion('550e8400-e29b-41d4-a716-446655440000') // → 4
uuidVersion('018e4bc8-1000-7000-8000-000000000001') // → 7
uuidVersion('6ba7b810-9dad-11d1-80b4-00c04fd430c8') // → 1

// Detect variant from the 17th hex character (index 16, first char of 4th group)
function uuidVariant(uuid) {
  const clean = uuid.replace(/-/g, '')
  const b = parseInt(clean[16], 16)
  if ((b & 0x8) === 0)      return 'NCS'
  if ((b & 0xC) === 0x8)    return 'RFC 4122'
  if ((b & 0xE) === 0xC)    return 'Microsoft'
  return 'Reserved'
}

UUID spéciaux

UUID nil

L'UUID nil 00000000-0000-0000-0000-000000000000 est entièrement à zéro. Il est défini par RFC 4122 comme valeur sentinelle signifiant 'aucun UUID' — analogue à null. Ce n'est pas un UUID généré valide.

UUID max

L'UUID max ffffffff-ffff-ffff-ffff-ffffffffffff est entièrement à un (0xFF dans chaque octet). Défini dans RFC 9562, c'est le complément de l'UUID nil et sert de valeur sentinelle maximale.

Foire Aux Questions

Comment savoir quelle version est un UUID ?
Regardez la position 14 dans la chaîne UUID canonique (le premier caractère du troisième groupe séparé par des tirets). Ce chiffre hexadécimal unique est le numéro de version : 1, 2, 3, 4, 5, 6, 7 ou 8. Collez l'UUID dans cet outil et il décodera la version pour vous.
Puis-je décoder un UUID pour récupérer les données originales ?
Cela dépend de la version. UUID v1 et v7 intègrent un horodatage qui peut être entièrement récupéré. UUID v1 intègre également l'adresse MAC. UUID v3 et v5 sont des hachages unidirectionnels — vous ne pouvez pas récupérer le nom original de l'UUID. UUID v4 est purement aléatoire — il n'y a rien à récupérer.
Que signifie 'variante' dans un UUID ?
Le champ de variante identifie la disposition des octets et la convention d'interprétation de l'UUID. Presque tous les UUID que vous rencontrerez auront la variante RFC 4122 (bits de poids fort 10), encodée comme chiffres hexadécimaux 8, 9, a ou b à la position 19. Les autres variantes (NCS, Microsoft) sont des formats legacy des années 1990.
Pourquoi certains UUID semblent-ils différents des autres ?
La différence visuelle se trouve dans le nibble de version (position 14) et le nibble de variante (position 19). Par exemple, UUID v4 a toujours un 4 à la position 14, tandis qu'UUID v7 a toujours un 7. Dans ces contraintes, les chiffres restants sont aléatoires ou dérivés d'un horodatage selon la version.
L'UUID nil est-il identique à un UUID vide ?
Conceptuellement oui — l'UUID nil (tous à zéro) est utilisé pour représenter l'absence d'un UUID, similaire à null. Ce n'est pas un UUID généré aléatoirement et ne devrait pas être stocké comme identifiant réel. Certains systèmes l'utilisent comme valeur par défaut ou de remplacement.
Un UUID peut-il être invalide ?
Un UUID peut être syntaxiquement valide (format correct) mais sémantiquement inhabituel — par exemple, ayant un nibble de version de 0 ou une variante de 11x (réservé). L'UUID nil et l'UUID max sont syntaxiquement valides mais sont des valeurs sentinelles. Cet outil affichera quels que soient les nibbles de version et de variante présents et signalera les versions non reconnues.
Quelle est la différence entre un UUID et un GUID ?
GUID (Globally Unique Identifier) est le nom de Microsoft pour le même concept. Les GUID suivent le même format RFC 4122 de 128 bits. La seule différence pratique est que les GUID Microsoft legacy peuvent utiliser la variante Microsoft (bits de poids fort 110) plutôt que la variante RFC 4122 — cela affecte l'ordre des octets dans la représentation binaire. La représentation textuelle est identique.