Gerador UUID v2

Gera UUID v2 DCE Security com domínio e ID local

Clique em Gerar para criar um UUID
Nota:UUID v2 codifica o domínio local e o ID na estrutura do UUID
Note:UUID v2 é um formato legado definido para contextos de segurança DCE. Raramente é necessário em aplicações modernas. Para IDs únicos de propósito geral, UUID v4 é recomendado.

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:

CampoBitsPropósito
local_id32<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_mid16<code>time_mid</code> — 16 bits do meio do timestamp truncado do UUID v1
time_hi+version16<code>time_hi_and_version</code> — 12 bits superiores do timestamp com o nibble de versão definido como <code>2</code>
variant+clock_hi8<code>clock_seq_hi_and_reserved</code> — bits de variante mais a porção alta da sequência de relógio
local_domain8<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
node48<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

Note:Como o campo local_id substitui o campo time_low, o timestamp no UUID v2 tem apenas 28 bits de largura (em comparação com 60 bits no UUID v1). Isso reduz a precisão do timestamp para aproximadamente 7,2 minutos — UUIDs gerados dentro da mesma janela de 7 minutos do mesmo host/domínio/combinação local_id podem não ser únicos.

Valores de Domínio Local

O byte local_domain especifica o tipo de identificador local incorporado no UUID:

0POSIX_UID
ID de Usuário POSIX — o UID numérico de <code>/etc/passwd</code>, obtível via <code>os.getuid()</code>
1POSIX_GID
ID de Grupo POSIX — o GID numérico de <code>/etc/group</code>, obtível via <code>os.getgid()</code>
2ORG
Organização — um identificador organizacional personalizado de 32 bits; a semântica é definida pela aplicação

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.

Warning:Não use UUID v2 para novos projetos. O formato não fornece vantagens sobre UUID v4 ou v7 para IDs únicos de propósito geral. Se você encontrou um UUID v2 em um sistema legado, use esta ferramenta para decodificar seus campos. Para novo desenvolvimento, use UUID v4.

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:

AspectoUUID v1UUID v2
Bits de timestamp60 bits (~precisão de 100 ns)28 bits (~precisão de 7,2 minutos)
Identificador localNenhumUID/GID POSIX de 32 bits
Domínio localNão presente0=UID, 1=GID, 2=Org
Campo de nóEndereço MACEndereço MAC
Suporte de bibliotecaAmplamente suportadoRaramente suportado
PadrãoRFC 4122 / RFC 9562Especificação DCE (referenciada pelo RFC 4122)
Uso práticoIDs 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

Python
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

Go
// 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:

JavaScript
// 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
Note:O pacote Go google/uuid suporta a geração de UUID v2 via uuid.NewDCEGroup() e uuid.NewDCEPerson() — uma das poucas bibliotecas mainstream que o faz.

Perguntas Frequentes

Posso gerar um UUID v2 em JavaScript?
Nenhuma biblioteca padrão suporta a geração de UUID v2 em JavaScript. Você precisaria construir os bytes manualmente: pegue um UUID v1, substitua o campo time_low (bytes 0–3) pelo seu identificador local, defina o byte 9 para o valor do seu domínio e defina o nibble de versão como 2. Esta ferramenta não gera UUID v2 — ela apenas os decodifica.
O que o campo local_id contém?
O local_id é um inteiro sem sinal de 32 bits cujo significado depende do byte local_domain. Para o domínio 0, é o UID POSIX do usuário que executa o processo (ex.: 1000 para o primeiro usuário não root em um sistema Linux). Para o domínio 1, é o GID POSIX. Para o domínio 2, o significado é definido pela aplicação.
O timestamp em um UUID v2 é confiável?
Apenas como um indicador grosseiro. Como apenas 28 bits dos 60 bits do timestamp UUID v1 são retidos, a precisão efetiva é de aproximadamente 7,2 minutos. Você pode decodificar um tempo de geração aproximado, mas não um preciso. Dentro de uma janela de 7 minutos, múltiplos valores UUID v2 com o mesmo local_id e domínio do mesmo host terão timestamps idênticos.
Quais sistemas ainda usam UUID v2?
UUID v2 é encontrado principalmente em sistemas DCE/RPC legados dos anos 1990, algumas versões do DCOM da Microsoft (que é baseado em DCE/RPC) e middleware de computação distribuída mais antigo. Sistemas modernos usam quase universalmente UUID v4 ou v7.
Por que RFC 4122 não inclui o algoritmo UUID v2?
RFC 4122 declara explicitamente que o algoritmo de geração UUID v2 é definido pela especificação DCE, não pela IETF. Como a IETF não tinha autoridade sobre a especificação DCE, eles incluíram apenas uma referência. É por isso que a maioria das bibliotecas UUID que seguem RFC 4122 omite suporte a UUID v2.
UUID v2 é o mesmo que um GUID?
Não. GUID (Identificador Globalmente Único) é o nome da Microsoft para o mesmo conceito. GUIDs seguem o mesmo formato RFC 4122 de 128 bits. A única diferença prática é que GUIDs Microsoft legados podem usar a variante Microsoft (bits altos 110) em vez da variante RFC 4122 — isso afeta a ordem de bytes na representação binária. A representação textual é idêntica.