Générateur UUID v2

Qu'est-ce qu'UUID v2 ?

UUID v2 est la version UUID de sécurité DCE, standardisée dans le cadre de la spécification Distributed Computing Environment (DCE) et référencée dans RFC 4122. Elle étend UUID v1 en intégrant un identifiant d'utilisateur ou de groupe POSIX (UID/GID) dans le champ d'horodatage.

La structure est similaire à UUID v1, mais le champ time_low de 32 bits est remplacé par un identifiant local de 32 bits (ex. un UID POSIX) et un champ local_domain d'1 octet identifie le type d'identifiant local. L'horodatage est tronqué en conséquence, réduisant sa précision et ses garanties d'unicité.

UUID v2 est extrêmement rare dans les logiciels modernes. La plupart des développeurs n'auront jamais besoin d'en générer un. Cette page documente le format par souci d'exhaustivité et pour aider au décodage des valeurs UUID v2 rencontrées dans les systèmes legacy.

Structure d'UUID v2

Un UUID v2 a le même format de 128 bits avec tirets que les autres versions UUID. Les champs diffèrent d'UUID v1 comme suit :

Exemple : 000003e8-92e0-21ef-8000-325096b39f47 — local_id 0x000003e8 = UID 1000, local_domain 0x00 = Utilisateur POSIX

Valeurs de domaine local

L'octet local_domain spécifie le type d'identifiant local intégré dans l'UUID :

Les valeurs de domaine sont définies par la spécification DCE. Les valeurs 3-255 sont réservées. En pratique, seul le domaine 0 (Personne/UID) est couramment rencontré dans les valeurs UUID v2 réelles.

Pourquoi UUID v2 est rarement utilisé

Trois caractéristiques rendent UUID v2 impraticable pour la plupart des applications modernes :

Résolution d'horodatage grossière

L'horodatage est tronqué à 28 bits (environ 7,2 minutes de granularité). Dans cette fenêtre, les UUID générés avec le même local_id et domaine sur le même hôte ne sont pas uniques — la spécification s'appuie sur le champ clock_seq pour les différencier, limitant l'unicité à 64 valeurs par fenêtre de 7 minutes.

Aucun support de bibliothèque standard

Contrairement à UUID v1 et v4, UUID v2 n'est pas supporté par la plupart des bibliothèques UUID. Le package npm uuid, le module Python uuid et java.util.UUID de Java omettent tous v2. Une implémentation personnalisée est requise.

Sémantique spécifique à POSIX

Le concept de domaine local (UID/GID) est intrinsèquement spécifique à POSIX et ne se transpose pas de manière significative à Windows, aux systèmes embarqués ou aux environnements cloud où le concept d'identifiant d'utilisateur POSIX est absent.

Contexte historique

UUID v2 a été défini dans le cadre du Distributed Computing Environment (DCE/RPC) de l'Open Software Foundation au début des années 1990. L'objectif était de créer des UUID pouvant transporter un contexte d'autorisation — spécifiquement, permettre à un serveur RPC d'identifier l'utilisateur appelant sans étape d'authentification séparée.

Le modèle de sécurité DCE supposait un environnement POSIX homogène où chaque noeud participait à un espace de noms UID/GID partagé. L'UID intégré permettrait au serveur de vérifier rapidement les listes de contrôle d'accès sans aller-retour vers un service de répertoire.

• Internet s'est éloigné des environnements POSIX homogènes vers des architectures cloud hétérogènes
• L'authentification moderne utilise des jetons (JWT, OAuth) plutôt que des UID intégrés dans les identifiants
• UUID v4 (entièrement aléatoire) et UUID v7 (ordonné dans le temps) couvrent les cas d'usage pratiques pour les identifiants uniques
• DCE/RPC lui-même est tombé en désuétude

RFC 4122 (2005) a inclus UUID v2 par référence à la spécification DCE, mais a délibérément omis l'algorithme de génération détaillé — notant qu'il était défini par DCE plutôt que par l'IETF.

RFC 9562 (2024), qui a mis à jour la norme UUID, a conservé UUID v2 pour l'exhaustivité historique mais a continué à noter sa nature spécifique à POSIX et l'absence d'un algorithme de génération complet dans la norme IETF.

UUID v2 vs UUID v1

UUID v2 est dérivé d'UUID v1. Voici comment ils se comparent :

UUID v2 n'offre rien de plus qu'UUID v1 pour un usage général, et est strictement pire à la plupart des égards. Il n'y a aucune raison de choisir UUID v2 pour un nouveau développement.

Exemples de code

UUID v2 n'a aucun support natif dans les bibliothèques standard. Les exemples suivants montrent comment travailler avec les valeurs UUID v2 :

Python — implémentation manuelle

import uuid, struct, time

def uuid_v2(local_id: int, local_domain: int = 0) -> str:
    """
    Generate a DCE Security UUID (v2).
    local_domain: 0 = POSIX UID, 1 = POSIX GID, 2 = Org
    local_id: 32-bit unsigned integer (e.g. os.getuid())
    """
    # Get a v1 UUID for the time and node fields
    v1 = uuid.uuid1()
    fields = list(v1.fields)  # [time_low, time_mid, time_hi_version, clock_seq_hi_variant, clock_seq_low, node]

    # Replace time_low with local_id
    fields[0] = local_id & 0xFFFFFFFF

    # Replace version nibble: clear lower 12 bits of time_hi, set version 2
    fields[2] = (fields[2] & 0x0FFF) | 0x2000

    # Replace clock_seq_low with local_domain
    fields[4] = local_domain & 0xFF

    return str(uuid.UUID(fields=tuple(fields)))


import os
print(uuid_v2(os.getuid(), local_domain=0))   # POSIX UID
print(uuid_v2(os.getgid(), local_domain=1))   # POSIX GID

Go — note

// The standard "github.com/google/uuid" package does NOT support v2.
// You would need to implement it manually, similar to the Python example above.
// Most Go developers use v4 or v7 for new projects.
import "github.com/google/uuid"

v4 := uuid.New()          // v4 — recommended for most use cases
v7, _ := uuid.NewV7()     // v7 — time-ordered, ideal for database primary keys

JavaScript — extraire les champs

Pour extraire le local_id et le domaine d'une chaîne UUID v2 existante :

// Extracting fields from a UUID v2 string
const uuidStr = '000003e8-1234-2abc-8200-a1b2c3d4e5f6'
//               ^^^^^^^^ ^^^^ ^    ^^
//               local_id      ver  variant+clockSeqHi
//                                  ^^ = local_domain (00 = POSIX UID)

const parts = uuidStr.split('-')

const localId     = parseInt(parts[0], 16)       // → 1000 (0x3e8)
const version     = parseInt(parts[2][0], 16)    // → 2
const localDomain = parseInt(parts[3].slice(2), 16) // low byte of octet pair

const DOMAIN_NAMES = ['POSIX UID', 'POSIX GID', 'Org']
console.log(`Local ID: ${localId}`)                       // Local ID: 1000
console.log(`Version:  ${version}`)                       // Version:  2
console.log(`Domain:   ${DOMAIN_NAMES[localDomain]}`)     // Domain:   POSIX UID

Foire Aux Questions