Gerador UUID v2
Gera UUID v2 DCE Security com domínio e ID local
O que é UUID v2?
UUID v2 é a versão UUID de Segurança DCE, padronizada como parte da especificação do Ambiente de Computação Distribuída (DCE) e referenciada no RFC 4122. Ela estende UUID v1 incorporando um identificador de usuário ou grupo POSIX (UID/GID) no campo de timestamp.
A estrutura é semelhante à do UUID v1, mas o campo de 32 bits time_low é substituído por um identificador local de 32 bits (ex.: um UID POSIX) e um campo local_domain de 1 byte identifica que tipo de ID local é. O timestamp é truncado como resultado, reduzindo sua precisão e garantias de unicidade.
UUID v2 é extremamente raro no software moderno. A maioria dos desenvolvedores nunca precisará gerar um. Esta página documenta o formato por completude e para auxiliar na decodificação de valores UUID v2 encontrados em sistemas legados.
Estrutura do UUID v2
Um UUID v2 tem o mesmo formato de 128 bits com hífens que outras versões UUID. Os campos diferem do UUID v1 da seguinte forma:
| Campo | Bits | Propósito |
|---|---|---|
| local_id | 32 | <code>local_id</code> — identificador de domínio local de 32 bits (ex.: UID POSIX de <code>/etc/passwd</code>), substitui o campo time_low do UUID v1 |
| time_mid | 16 | <code>time_mid</code> — 16 bits do meio do timestamp truncado do UUID v1 |
| time_hi+version | 16 | <code>time_hi_and_version</code> — 12 bits superiores do timestamp com o nibble de versão definido como <code>2</code> |
| variant+clock_hi | 8 | <code>clock_seq_hi_and_reserved</code> — bits de variante mais a porção alta da sequência de relógio |
| local_domain | 8 | <code>local_domain</code> — identificador de domínio: <code>0</code> = Usuário POSIX (UID), <code>1</code> = Grupo POSIX (GID), <code>2</code> = Organização |
| node | 48 | <code>node</code> — endereço MAC de 48 bits do host gerador |
Exemplo: 000003e8-92e0-21ef-8000-325096b39f47 — local_id 0x000003e8 = UID 1000, local_domain 0x00 = Usuário POSIX
Valores de Domínio Local
O byte local_domain especifica o tipo de identificador local incorporado no UUID:
Os valores de domínio são definidos pela especificação DCE. Valores 3–255 são reservados. Na prática, apenas o domínio 0 (Pessoa/UID) é comumente encontrado em valores UUID v2 do mundo real.
Por que UUID v2 É Raramente Usado
Três características tornam UUID v2 impraticável para a maioria das aplicações modernas:
Resolução de Timestamp Grosseira
O timestamp é truncado para 28 bits (aproximadamente granularidade de 7,2 minutos). Dentro dessa janela, UUIDs gerados com o mesmo local_id e domínio no mesmo host não são únicos — a especificação depende do campo clock_seq para diferenciá-los, limitando a unicidade a 64 valores por janela de 7 minutos.
Sem Suporte de Biblioteca Padrão
Ao contrário de UUID v1 e v4, UUID v2 não é suportado pela maioria das bibliotecas UUID. O pacote npm uuid, o módulo uuid do Python e java.util.UUID do Java omitem v2. Implementação personalizada é necessária.
Semântica Específica de POSIX
O conceito de domínio local (UID/GID) é inerentemente específico de POSIX e não se traduz significativamente para Windows, sistemas embarcados ou ambientes de nuvem onde o conceito de um ID de usuário POSIX está ausente.
Contexto Histórico
UUID v2 foi definido como parte do Ambiente de Computação Distribuída (DCE/RPC) da Open Software Foundation no início dos anos 1990. O objetivo era criar UUIDs que pudessem carregar contexto de autorização — especificamente, para que um servidor RPC pudesse identificar o usuário chamante sem uma etapa de autenticação separada.
O modelo de segurança DCE assumia um ambiente POSIX homogêneo onde cada nó participava de um namespace UID/GID compartilhado. O UID incorporado permitiria ao servidor verificar rapidamente listas de controle de acesso sem uma ida e volta a um serviço de diretório.
- A internet se afastou de ambientes POSIX homogêneos em direção a arquiteturas de nuvem heterogêneas
- A autenticação moderna usa tokens (JWT, OAuth) em vez de UIDs incorporados em identificadores
- UUID v4 (totalmente aleatório) e UUID v7 (ordenado por tempo) cobrem os casos de uso práticos para identificadores únicos
- O próprio DCE/RPC caiu em desuso generalizado
RFC 4122 (2005) incluiu UUID v2 por referência à especificação DCE, mas omitiu deliberadamente o algoritmo de geração detalhado — observando que era definido pela DCE em vez da IETF.
RFC 9562 (2024), que atualizou o padrão UUID, reteve UUID v2 por completude histórica, mas continuou a observar sua natureza específica de POSIX e a ausência de um algoritmo de geração completo no padrão IETF.
UUID v2 vs UUID v1
UUID v2 é derivado do UUID v1. Veja como eles se comparam:
| Aspecto | UUID v1 | UUID v2 |
|---|---|---|
| Bits de timestamp | 60 bits (~precisão de 100 ns) | 28 bits (~precisão de 7,2 minutos) |
| Identificador local | Nenhum | UID/GID POSIX de 32 bits |
| Domínio local | Não presente | 0=UID, 1=GID, 2=Org |
| Campo de nó | Endereço MAC | Endereço MAC |
| Suporte de biblioteca | Amplamente suportado | Raramente suportado |
| Padrão | RFC 4122 / RFC 9562 | Especificação DCE (referenciada pelo RFC 4122) |
| Uso prático | IDs legados ordenados por timestamp (Cassandra) | Apenas contextos de Segurança DCE |
UUID v2 não oferece nada sobre UUID v1 para uso de propósito geral, e é estritamente pior na maioria dos aspectos. Não há razão para escolher UUID v2 para novo desenvolvimento.
Exemplos de Código
UUID v2 não tem suporte nativo em bibliotecas padrão. Os exemplos a seguir mostram como trabalhar com valores UUID v2:
Python — implementação manual
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 — nota
// 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 — extrair campos
Para extrair o local_id e o domínio de uma string UUID v2 existente:
// 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
google/uuid suporta a geração de UUID v2 via uuid.NewDCEGroup() e uuid.NewDCEPerson() — uma das poucas bibliotecas mainstream que o faz.