Gerador de UUID

Onde os UUIDs são usados

Um UUID (identificador universalmente único, também chamado de GUID no Windows) é um valor de 128 bits escrito como 32 dígitos hexadecimais em cinco grupos: 8-4-4-4-12, por exemplo 3f1c2b7e-9a4d-4c1e-8b2f-6d0e5a7c9b13. A ideia é que qualquer sistema possa criar um sozinho, sem consultar um contador central, e ainda assim ter certeza de que ele nunca vai colidir com um ID criado em outro lugar.

Essa propriedade é útil em muitos lugares:

• Chaves primárias em bancos de dados, principalmente quando os registros são criados em vários servidores ou offline em dispositivos clientes e sincronizados depois.
• IDs de requisição e de correlação que acompanham uma operação pelos logs de vários serviços.
• Nomes de arquivos enviados, para que dois usuários enviando photo.jpg nunca sobrescrevam um ao outro.
• Chaves de idempotência para APIs de pagamento e de pedidos.
• Dados de teste e de seed que precisam de IDs realistas.

Versão 4 e versão 7

A ferramenta oferece as duas versões que importam para projetos novos hoje. As duas têm o mesmo formato e o mesmo tamanho; a diferença está no conteúdo dos bits.

UUID v4 (aleatório)

Fora 6 bits fixos que marcam a versão e a variante, todos os 122 bits são aleatórios. Dá para reconhecer um v4 pelo 4 no início do terceiro grupo. Eles vêm do crypto.randomUUID() do navegador, que usa a fonte de aleatoriedade criptograficamente segura do sistema operacional.

Use v4 quando o ID não pode revelar nada: tokens de convite em URLs, IDs públicos de recursos, qualquer caso em que conhecer um ID não deva ajudar a adivinhar outro nem a saber quando ele foi criado.

UUID v7 (ordenado por tempo)

Padronizado na RFC 9562 em 2024, o v7 coloca na frente um timestamp Unix de 48 bits em milissegundos e preenche os 74 bits restantes com dados aleatórios. O terceiro grupo começa com 7. Como o timestamp vem primeiro, os valores v7 ficam em ordem de criação quando ordenados como strings ou bytes simples.

Isso importa para bancos de dados. Índices B-tree guardam as chaves em ordem, e chaves v4 aleatórias caem em páginas aleatórias, causando divisões de página e mau uso do cache à medida que as tabelas chegam a milhões de linhas. Chaves ordenadas por tempo são acrescentadas perto do fim do índice, de forma parecida com um inteiro autoincremental, mantendo a propriedade de "gerar em qualquer lugar". Para tabelas novas em PostgreSQL, MySQL ou SQL Server, o v7 costuma ser a melhor chave primária.

Duas ressalvas: o timestamp é legível, então um v7 revela quando o registro foi criado, com precisão de milissegundos. E este gerador não acrescenta um contador abaixo do milissegundo, então IDs gerados no mesmo milissegundo, como acontece dentro de um mesmo lote, ficam ordenados entre si pela parte aleatória, e não pela ordem de geração.

Qual a chance de uma duplicata

Com 122 bits aleatórios, existem cerca de 5,3 × 10^36 valores v4 possíveis. Pelo limite do paradoxo do aniversário, você precisaria gerar cerca de 2,7 × 10^18 deles para chegar a 50% de chance de uma única colisão. A um bilhão por segundo, isso levaria mais de 80 anos.

No v7, a parte aleatória tem 74 bits, mas só precisa ser única entre os IDs criados no mesmo milissegundo. Mesmo com um milhão de IDs por milissegundo, a chance de colisão continua desprezível.

Na prática, duplicatas vêm de bugs, não da matemática: um ID de exemplo fixo no código copiado para produção, um gerador aleatório com seed ou não criptográfico, ou uma máquina virtual clonada repetindo estado. Gerar no navegador com a aleatoriedade segura do sistema evita os dois últimos casos.

Detalhes de formato e armazenamento

• Maiúsculas e minúsculas. A RFC 9562 diz que os UUIDs são escritos em minúsculas e comparados sem diferenciar maiúsculas. A opção Maiúsculas existe para sistemas e documentações que usam o estilo GUID do Windows.
• Chaves e hifens. Algumas ferramentas da Microsoft mostram GUIDs entre {chaves}. Tire-as, ou tire os hifens, só se o sistema de destino esperar essa forma.
• Armazenamento. Guarde UUIDs num tipo nativo (uuid no PostgreSQL, BINARY(16) no MySQL) em vez de CHAR(36). A forma binária ocupa 16 bytes em vez de 36 e é comparada mais rápido.
• Tamanho do lote. Até 500 de uma vez, um por linha, prontos para colar num script SQL ou numa planilha. Clicar em Gerar novos substitui a lista inteira.

UUIDs são identificadores, não segredos. Um v4 é difícil de adivinhar, mas se ele dá acesso a alguma coisa, trate isso como um link de conveniência, não como autenticação. Para credenciais, use o gerador de senhas. Para decodificar o momento de criação de um v7, pegue os 12 primeiros dígitos hexadecimais, converta-os para decimal e cole o número no conversor de timestamp Unix.