Versões de GUID explicadas: v1–v7 e qual escolher

2026-07-09

Tags: Windows · GUID · Guia · QuickGUID

---

Abra qualquer biblioteca UUID e você verá uuid1(), uuid3(), uuid4(), uuid5() e, cada vez mais, uuid7(). A especificação define oito versões. Qual usar de fato?

A resposta curta: v4 para quase tudo, v7 para chaves primárias de banco de dados, v5 quando você precisa que a mesma entrada produza sempre o mesmo GUID. O restante deste artigo explica o porquê — com disposições de bytes, as razões reais de cada versão e um guia rápido de código por linguagem.

Se você é novato em GUIDs, comece por O que é um GUID? para o básico de estrutura e unicidade. Este post é o companheiro técnico — ele afunda em cada versão.

O panorama de versões de GUID/UUID

Cada versão é uma receita diferente para preencher os mesmos 128 bits. O nibble de versão (primeiro dígito hex do terceiro segmento) diz qual receita foi usada.

Versão	Fonte de geração	Ordenável	Uso típico
v1	Tempo + MAC	Sim	Sistemas legados (risco de privacidade)
v2	DCE Security	Sim	Raro, especializado
v3	Hash de namespace MD5	Não	Obsoleto (use v5)
v4	Aleatório	Não	Padrão geral
v5	Hash de namespace SHA-1	Não	IDs determinísticos
v6	Tempo v1 reordenado	Sim	Substituto direto do v1
v7	Timestamp em milissegundos	Sim	Chaves primárias de banco de dados
v8	Definido pelo fornecedor	Personalizado	Especializado

As versões v1, v4, v5 e v7 cobrem 99 % do uso real. Vamos passar por cada uma.

v1: Tempo e endereço MAC

v1 é a receita original da RFC 4122. Ela empacota três coisas em 128 bits:

| time_low (32) | time_mid (16) | ver+time_hi (16) | var+clk_seq (16) | node/MAC (48) |

• Timestamp de 60 bits — intervalos de 100 nanossegundos desde 15/10/1582 (data de adoção do calendário gregoriano). O timestamp é dividido entre time_low, time_mid e time_hi.
• Sequência de clock de 14 bits — um contador que desambigua dois GUIDs gerados no mesmo tick de clock, ou quando o relógio do sistema foi retrocedido.
• Nó de 48 bits — o endereço MAC da placa de rede.

O problema do endereço MAC

O campo nó é uma impressão digital de hardware. Qualquer GUID v1 que você publica carrega o endereço MAC da sua máquina — e ao contrário de um endereço IP, um endereço MAC é projetado para ser globalmente único e persistente. Isso é um vazamento real de privacidade.

Não é teórico. Pesquisadores mostraram que dá para rastrear documentos até a máquina que os criou lendo os GUIDs v1 embutidos nos metadados do arquivo. A própria Microsoft removeu a geração de v1 da telemetria do Office depois que isso foi demonstrado. Sistemas operacionais modernos também aleatorizam o MAC mostrado às redes Wi-Fi pelo mesmo motivo.

Veredito: evite v1 em código novo. Ele sobrevive em sistemas legados, interfaces COM e algumas ferramentas próximas ao hardware — mas não há motivo para gerá-lo você mesmo hoje.

v2: DCE Security

v2 é a versão que você basicamente nunca vai encontrar. Ela pega a disposição do v1 (timestamp + MAC) e sobrepõe um UID/GID POSIX — os identificadores locais de usuário e grupo do modelo de segurança DCE (Distributed Computing Environment) — de modo que o UUID possa carregar informação de controle de acesso além da sua unicidade.

v2 existe para autenticação DCE/RPC e ACLs em sistemas corporativos legados. A menos que você mantenha software que fale explicitamente DCE Security, você nunca vai gerar nem consumir um v2. Ele aparece aqui puramente para que a lista de versões esteja completa e você não fique se perguntando o que significa um «2» naquele nibble se um dia encontrar um.

v3: Por que foi descontinuado

v3 é idêntico a v5 exceto em que usa MD5 em vez de SHA-1. MD5 tem ataques de colisão práticos — duas entradas diferentes podem ser forjadas para produzir o mesmo hash. Isso quebra a garantia de determinismo do v3 em cenários adversariais.

A RFC 4122 manteve v3 para retrocompatibilidade, mas v5 o substituiu. Não há motivo para gerar v3 hoje. Se você encontrar um v3 no mundo real, trate-o como legado.

v4: O padrão aleatório

v4 é o que você obtém de praticamente toda chamada «gerar um GUID»: [guid]::NewGuid(), Guid.NewGuid(), crypto.randomUUID(), uuid.uuid4(), NEWID(). Ele preenche 122 dos 128 bits com aleatoriedade criptograficamente forte (os outros 6 bits são os marcadores de versão e variante).

Sem timestamp, sem MAC, sem estado de máquina — aleatoriedade pura. Isso torna o v4 seguro para expor, trivialmente paralelizável e resistente o suficiente a colisões para qualquer carga realista. Para a matemática completa de colisões (e por que a afirmação viral de «um bilhão de anos» entende errado o paradoxo do aniversário), veja o artigo principal.

Veredito: este é o seu padrão. Escolha v4 a menos que você tenha um motivo específico para escolher outra coisa.

v5: IDs de namespace determinísticos

Esta é a versão de que a maioria dos desenvolvedores ouviu falar mas nunca usou de fato — e ela resolve um problema genuinamente útil.

v5 permite derivar o mesmo GUID da mesma entrada, sempre. Entregue um UUID de namespace e uma string de nome, e ele devolve um identificador determinístico:

import uuid

# Mesma entrada → mesmo GUID, a cada execução, em cada máquina
dns_guid = uuid.uuid5(uuid.NAMESPACE_DNS, 'example.com')
url_guid = uuid.uuid5(uuid.NAMESPACE_URL, 'https://prunelab.net/blog/guid-explained')

print(dns_guid)  # sempre  cf14e0a3-... (mesmo valor)
print(dns_guid == uuid.uuid5(uuid.NAMESPACE_DNS, 'example.com'))  # True

Como funciona

Internamente, v5 concatena os bytes do UUID de namespace com os bytes UTF-8 do nome, roda SHA-1 sobre o resultado, pega os primeiros 16 bytes e então estampa os bits de versão (5) e variante. O namespace em si é um UUID — NAMESPACE_DNS, NAMESPACE_URL, NAMESPACE_OID e NAMESPACE_X500 são predefinidos, mas você pode usar qualquer UUID como namespace.

Quando v5 é a ferramenta certa

• Fixtures de teste reproduzíveis — gere IDs para dados de teste que ficam estáveis entre execuções, para que um teste que falha aponte sempre para a mesma entidade.
• Identificadores derivados de URL — transforme uma URL em um GUID sem consulta ao banco. Dois sistemas que calculam independentemente uuid5(NAMESPACE_URL, url) para a mesma URL sempre concordam.
• Desduplicação idempotente — importe o mesmo registro duas vezes e o GUID colide consigo mesmo, então você detecta a duplicata só pela chave.

O contraste-chave com v4: v4 devolve um valor único por chamada (mesmo para entradas idênticas); v5 devolve um valor estável para entradas idênticas. Eles não são intercambiáveis.

Veredito: recorra a v5 sempre que precisar de um GUID que se derive de forma reproduzível a partir de uma string de entrada.

v6: A correção do v1 que você provavelmente não precisa

v6 contém exatamente os mesmos dados que v1 — o mesmo timestamp, a mesma sequência de clock e MAC — mas reorganiza os bits de timestamp para que o valor se ordene naturalmente em ordem cronológica. Em v1 o timestamp é dividido de forma desajeitada (low, mid, high); em v6 ele é armazenado high-first, então a ordenação lexicográfica de strings iguala à ordenação por tempo.

v6 foi padronizado em 2024 na RFC 9562 ao lado de v7. Ele existe principalmente como caminho de migração direto para sistemas já atrelados ao modelo clock-e-MAC do v1: você mantém sua lógica de timestamp existente e simplesmente reescreve a disposição dos bits.

Para sistemas novos, v7 é quase sempre a melhor escolha. v7 usa um timestamp em milissegundos (mais simples que a contagem gregoriana de 100 ns do v1/v6), não embute um endereço MAC e tem um preenchimento aleatório mais limpo. v6 responde a «como modernizo o v1 sem mudar meu modelo de geração»; v7 responde a «o que devo usar daqui para frente».

v7: Ordenado no tempo para bancos de dados

v7 é a adição mais importante desde v4. Ele resolve um problema que v4 cria em bancos de dados.

O problema do v4 em bancos de dados

Quando um banco de dados usa GUIDs como chaves primárias, essas chaves sustentam um índice em árvore B+. Árvores B+ permanecem eficientes quando inserções são aproximadamente ordenadas — valores novos caem na borda direita e preenchem páginas existentes. GUIDs v4 aleatórios se espalham por todo o espaço de chaves, então cada inserção atinge uma página aleatória. Em tabelas grandes isso causa divisões de página constantes, fragmentação de índice, thrash de cache e amplificação de escrita. A correção no SQL Server (NEWSEQUENTIALID()) é um hack proprietário e não portátil que vaza o sequenciamento.

A disposição do v7

| unix_ts_ms (48) | ver (4) | rand_a (12) | var (2) | rand_b (62) |

• Timestamp Unix de 48 bits em milissegundos — campo líder, então os valores aumentam ao longo do tempo.
• Versão de 4 bits — definida como 7.
• rand_a de 12 bits — aleatório, ou opcionalmente um contador monotônico para ordenar dentro do mesmo milissegundo.
• Variante de 2 bits — o marcador RFC 9562 padrão.
• rand_b de 62 bits — aleatório.

Como o timestamp lidera, os GUIDs v7 gerados em sequência são naturalmente ordenados: inserções de índice se agrupam na borda direita, as páginas se preenchem de forma limpa, e a árvore B+ se comporta como com um inteiro auto-increment — e continua globalmente única sem coordenador central.

Quando v7 NÃO vale a pena

• Stores em memória (Redis, memcached) — sem árvore B+, sem custo de fragmentação. v4 serve.
• Tabelas pequenas — a diferença entre v4 e v7 é invisível abaixo de milhões de linhas.
• Colunas que não são chave — se o GUID é só um atributo armazenado e não uma chave de índice, a ordem é irrelevante.
• GUIDs que precisam ser opacos — v7 vaza o milissegundo de geração, o que pode ser indesejável em contextos sensíveis à segurança.

Veredito: se um GUID é uma chave primária clusterizada em um banco de dados real, use v7. Caso contrário v4.

v8: Definido pelo fornecedor

v8 é a saída de emergência: a RFC 9562 deixa o fornecedor definir sua própria disposição de bits, contanto que o nibble de versão seja 8 e os bits de variante estejam corretos. Todo o resto — largura do timestamp, fonte de aleatoriedade, codificação — fica por conta do implementador.

Você só verá v8 em sistemas que projetaram um esquema UUID personalizado por uma razão específica (por exemplo, embutir um shard ID ou node ID no UUID para roteamento). Se você não está construindo tal sistema, v8 é irrelevante; e se está, as regras são as do seu próprio esquema, não qualquer coisa neste artigo.

Qual versão você deveria realmente usar?

Um guia de decisão:

• «Gerando IDs para uso geral?» → v4. Esta é a resposta em 90 % dos casos.
• «Chave primária de banco de dados, ou precisa de ordenação temporal?» → v7. Especialmente para índices clusterizados em tabelas grandes.
• «Precisa do mesmo GUID para a mesma entrada sempre?» → v5. Mapeamento determinístico a partir de uma string.
• «Trabalhando com um sistema legado que espera v1?» → v1 (mantenha compatibilidade), mas planeje uma migração para v7.
• «Alguém me disse para usar v3?» → Não. Use v5 no lugar (MD5 no v3 está quebrado).
• «Eu quero o mais novo.» → Isso não é um motivo. v7 é novo e resolve um problema real (ordenação em BD); v6 é novo e principalmente uma ajuda de migração do v1. Escolha pelo caso de uso, não pela novidade.

Se você ainda está em dúvida, use v4. O padrão existe por um motivo.

Gerar GUIDs por versão e linguagem

Linguagem / ferramenta	v4 (padrão)	v5 (determinístico)	v7 (ordenado)
PowerShell	[guid]::NewGuid()	—	—
C# / .NET	Guid.NewGuid()	—	Guid.CreateVersion7() (.NET 9+)
Python	uuid.uuid4()	uuid.uuid5(uuid.NAMESPACE_URL, 'name')	uuid.uuid7() (3.14 beta) / lib
JavaScript	crypto.randomUUID()	—	(npm uuid v11+)
Node.js (lib uuid)	uuid.v4()	uuid.v5('name', NAMESPACE)	uuid.v7()
SQL Server	NEWID()	—	—
PostgreSQL	gen_random_uuid()	—	(extensão)

Algumas notas: o suporte nativo a v7 ainda está pousando nas bibliotecas padrão em 2026. O pacote uuid do Node.js (v11+) e o .NET 9 o entregam nativamente; o Python adiciona uuid.uuid7() na 3.14; runtimes mais antigos precisam de uma biblioteca. O suporte a v5 é quase universal porque é pura matemática SHA-1 sem fonte de entropia necessária.

Perguntas frequentes

v7 vai substituir v4 como padrão?

Não. v4 segue como o padrão geral. v7 só vence quando o GUID é uma chave primária ordenada — para a maioria dos outros usos (tokens de sessão, IDs de requisição, hashes de conteúdo, tudo que não é banco) a aleatoriedade do v4 não é um inconveniente, e o timestamp líder do v7 só vazaria informação de timing sem benefício.

v1 ainda é seguro de usar?

Não. v1 embute o endereço MAC da sua placa de rede, que é uma impressão digital de hardware persistente. A própria Microsoft removeu v1 da telemetria do Office depois que pesquisadores rastrearam máquinas por documentos via GUIDs embutidos. Para código novo, evite v1 inteiramente; para v1 legado, planeje uma migração para v7.

Qual é a diferença entre v3 e v5?

Ambos são hashes de namespace determinísticos (mesma entrada → mesmo GUID). v3 usa MD5, v5 usa SHA-1. MD5 tem ataques de colisão práticos, então v3 é considerado quebrado para fins de integridade e foi substituído por v5. Não há motivo para gerar v3 hoje.

Posso converter um GUID v4 em v7?

Não. A versão não é um rótulo que você pode trocar — cada versão usa uma lógica de geração completamente diferente. v4 não tem timestamp para extrair, então a única forma de «obter um v7» é gerar um novo. Se você precisa migrar uma coluna de chave primária v4 para v7, na verdade você está adicionando uma nova coluna e reescrevendo-a.

.NET suporta v7 nativamente?

Sim. Guid.CreateVersion7() foi adicionado no .NET 9 (lançado em novembro de 2024). Se você está no .NET 8 ou anterior, use os pacotes NuGet GenVault ou UUIDv7, ou atualize.

QuickGUID: gere v4 e v7, converta qualquer formato

Para o trabalho diário com GUIDs, o QuickGUID é uma caixa de ferramentas nativa do Windows que cobre todo o fluxo:

• Geração em lote de v4 ou v7, até 1.000 de cada vez
• Conversão de 10+ formatos: padrão, sem hífens, chaves, Base64, array de bytes em C, macro DEFINE_GUID — tudo com pré-visualização ao vivo
• Extração inteligente: cole logs ou código-fonte, encontre e converta automaticamente cada GUID
• Decoradores ao vivo: aspas, prefixos/sufixos, maiúsculas/minúsculas — alterne globalmente e copie diretamente

Totalmente gratuito, 100% offline.

Para concluir

O sistema de versões existe porque diferentes trabalhos precisam de diferentes garantias: v4 dá a você aleatoriedade não rastreável, v5 dá reprodutibilidade, v7 dá ordenação. Por padrão v4, recorra a v7 em chaves de banco de dados, e use v5 quando entradas idênticas devem produzir GUIDs idênticos.

Novo em GUIDs? Comece com O que é um GUID? para o básico de estrutura, o formato com hífens e por que 128 bits bastam para tornar colisões um não-assunto na prática.