Gerador de UUID grátis

Sobre UUIDs

Um UUID (Universally Unique Identifier) é um identificador de 128-bit projetado para ser único no espaço e no tempo. A versão mais comum, UUID v4, é gerada usando números aleatórios ou pseudoaleatórios. O formato é 8-4-4-4-12 caracteres hexadecimais, por exemplo 550e8400-e29b-41d4-a716-446655440000.

Uma história de quatro décadas, de Apollo ao RFC 9562

O conceito de UUID originou-se no Apollo Network Computing System (NCS) em meados dos anos 1980, concebido na Apollo Computer por Paul Leach e Rich Salz para suportar computação distribuída sem registo central. O formato foi adoptado pelo Open Software Foundation Distributed Computing Environment (OSF DCE) em 1989 e padronizado internacionalmente em 1995 como ITU-T X.667 / ISO/IEC 9834-8. A IETF dobrou a spec no RFC 4122 (Leach, Mealling, Salz) em Julho de 2005, que se tornou a referência canónica durante duas décadas. O RFC 4122 foi actualizado pelo RFC 9562 em Maio de 2024, que manteve todas as versões originais (v1 a v5), acrescentou três novas versões (v6, v7, v8), e formalmente definiu as constantes especiais «Nil UUID» (todos zeros) e «Max UUID» (todos uns). A linhagem de versões importa porque cada versão troca propriedades diferentes: baseada no tempo (ordenável, com fugas); baseada no nome (determinística a partir de entradas); aleatória (universal, opaca); personalizada (o que precisar). A melhor prática moderna para novas aplicações deslocou-se de v4 (aleatória) para v7 (timestamp + aleatório) para chaves primárias, enquanto v4 permanece a resposta certa para identificadores opacos onde a ordenabilidade é indesejável.

As oito versões, em linguagem clara

• v1 (timestamp + endereço MAC). 60 bits de timestamp (intervalos de 100 nanossegundos desde a época gregoriana 1582) mais o endereço MAC da máquina de origem. A grande desvantagem: ela revela o endereço MAC da máquina geradora, o que é uma preocupação de privacidade. O autor do vírus Melissa foi famosamente identificado em 1999 em parte traçando UUIDs v1 em documentos Word até uma máquina específica.
• v2 (DCE security). Variante de v1 que inclui um POSIX UID/GID. Quase nunca usada na prática; documentada por completude.
• v3 (baseada em nome, MD5). UUID determinística derivada do hash MD5 de (UUID de namespace + string de nome). As mesmas entradas produzem sempre o mesmo UUID, útil para traduzir chaves naturais (URLs, nomes de domínio, distinguished names) para forma UUID.
• v4 (aleatória). 122 bits de aleatoriedade (os 6 bits restantes são tags de versão + variant). A versão mais amplamente usada, o por defeito que quase qualquer biblioteca «dá-me um UUID» retorna.
• v5 (baseada em nome, SHA-1). Igual a v3 mas usando SHA-1 em vez de MD5. Preferida sobre v3 para novas aplicações porque o SHA-1 está menos partido que o MD5, embora ambos tenham ataques de colisão conhecidos.
• v6 (RFC 9562, Maio de 2024, ordenada por tempo). Reordena os bits de timestamp v1 para que a ordenação lexicográfica corresponda à cronológica. Resolve a queixa «v1 não ordena por tempo»; ainda revela o endereço MAC por defeito.
• v7 (RFC 9562, Maio de 2024, timestamp Unix + aleatório). Os primeiros 48 bits são o timestamp Unix em milissegundos; os restantes 74 bits são aleatórios. Ordena naturalmente por tempo de criação, inclui dados de timestamp sem revelar a identidade da máquina, e é a recomendação moderna para chaves primárias de bases de dados. Postgres 18+ tem uuidv7() incorporado; SQL Server tem NEWSEQUENTIALID() com propriedades semelhantes.
• v8 (personalizada). Reservada para layouts específicos da aplicação. O campo de versão marca-a como v8 e os bits de variant estão definidos correctamente; tudo o resto depende da aplicação. Use-a quando precisar de incorporar os seus próprios dados estruturados no envelope com forma de UUID.

Por que v7 é cada vez mais preferida sobre v4 para chaves de base de dados

Chaves primárias aleatórias (UUIDs v4) têm um custo de performance bem documentado em bases de dados que organizam linhas por chave primária num B-tree ou índice semelhante. Cada nova inserção aterra numa posição aleatória do índice, o que fragmenta as páginas do índice, aumenta a amplificação de escrita no disco, e estraga a cache de páginas porque as linhas inseridas recentemente estão espalhadas por muitas páginas em vez de agrupadas. Chaves sequenciais (inteiros auto-incrementais, ULIDs, UUIDs v7) inserem-se todas na borda direita do índice, o que mantém o working set pequeno e a amplificação de escrita mínima. A crítica do «anti-padrão de chave aleatória» remonta à documentação inicial do SQL Server em torno de NEWID versus NEWSEQUENTIALID, e foi rearticulada pela comunidade Postgres para v4 vs v7. O trade-off: v7 revela o tempo de criação de cada linha, o que pode ser uma preocupação de privacidade ou fuga de informação em algumas aplicações (p. ex., pode dizer quando uma conta foi criada lendo o seu UUID). Para a maioria das aplicações, o ganho de performance supera a fuga de timestamp; para aplicações de alta privacidade, v4 permanece a resposta certa.

Probabilidade de colisão, a matemática do paradoxo do aniversário

UUID v4 tem 122 bits de aleatoriedade, dando aproximadamente 5,3 × 10³⁶ valores possíveis. O paradoxo do aniversário diz que se precisa aproximadamente da raiz quadrada do tamanho do namespace para ter 50 % de hipótese de qualquer colisão, cerca de 2,3 × 10¹⁸ UUIDs. Para pôr isso em termos humanos: se gerar 1 mil milhões de UUIDs por segundo continuamente, precisaria de cerca de 86 anos para ter 50 % de hipótese de uma única colisão. Para taxas de geração à escala de aplicação ordinária (milhares ou milhões por dia), o risco prático de colisão é zero. A causa mais provável de «UUIDs duplicados» em sistemas reais é um gerador com bug a usar Math.random() em vez de um CSPRNG, ou um gerador com entropia insuficiente no arranque, ou um processo que acidentalmente semeia dois geradores identicamente, não a matemática subjacente. Este gerador usa crypto.randomUUID() do navegador (onde disponível) ou crypto.getRandomValues(), ambos retirando do CSPRNG do sistema operativo (Linux getrandom(), Windows BCryptGenRandom, macOS SecRandomCopyBytes), a mesma fonte de entropia usada para chaves de sessão TLS.

Implementação no navegador: crypto.randomUUID()

A API Web Crypto expõe crypto.randomUUID() como um gerador de uma chamada que retorna uma string UUID v4 conforme à RFC 4122. Foi enviada no Chrome 92 (Julho 2021), Firefox 95 (Dezembro 2021) e Safari 15.4 (Março 2022), e tem estado disponível como baseline em todos os navegadores modernos desde aproximadamente 2022. Para navegadores mais antigos, o fallback padrão é alocar um Uint8Array de 16 bytes, preenchê-lo com crypto.getRandomValues(), definir o nibble de versão para 4 (o nibble alto do 7º byte = 0x40), definir os bits de variant para 10xxxxxx (os dois bits altos do 9º byte = 0x80), e formatar os bytes como string hex 8-4-4-4-12. Este gerador usa crypto.randomUUID() quando presente e o fallback manual caso contrário, a saída é idêntica de qualquer maneira, apenas ligeiramente mais lenta no caminho de fallback. Ambos os caminhos correm inteiramente no seu navegador; nada atravessa a rede.

Casos de uso, e o que cada um realmente precisa

• Chaves primárias de base de dados: especialmente sistemas distribuídos ou shardados onde coordenar um contador inteiro é impraticável. v7 é a recomendação moderna; v4 se precisar de opacidade de timestamp.
• IDs de correlação de pedidos API. Cada pedido recebido obtém um UUID que viaja por cada serviço a jusante na cadeia de chamadas; logs de qualquer serviço podem ser ligados de volta ao pedido de origem via o ID. Stripe, Twilio e AWS X-Ray fazem todos isto.
• Chaves de idempotência para pedidos HTTP. O cabeçalho Idempotency-Key da Stripe aceita um UUID; se o cliente repetir o mesmo pedido com a mesma chave, a Stripe devolve a resposta em cache em vez de cobrar o cartão duas vezes. Este padrão é agora padrão em APIs de pagamento.
• Tokens de sessão, com ressalvas. Um UUID v4 é criptograficamente aleatório e tem 122 bits de entropia, o que é mais que suficiente para um ID de sessão. Mas tokens de sessão que são apenas um UUID são vulneráveis a ataques de enumeração se algum endpoint relacionado os revelar; a melhor prática moderna é usar tokens mais longos e assinados (JWTs, Paseto) para o estado da sessão.
• Nomes de ficheiros para deduplicação de uploads. Gere um UUID para cada upload, armazene o ficheiro em /uploads/{uuid}.ext: nunca terá colisão de nome independentemente do nome de ficheiro original, e não pode acidentalmente servir o ficheiro de outro utilizador adivinhando a URL.
• IDs de mensagem em sistemas guiados por eventos. Kafka, RabbitMQ, AWS SQS e a maioria das plataformas pub/sub recomendam um UUID por mensagem para tracing e deduplicação; v7 é cada vez mais o por defeito pela propriedade ordenável por timestamp.
• Geração de dados de teste. Bibliotecas Faker em todas as linguagens usam UUIDs como IDs por defeito para linhas de teste geradas.
• Identificadores de nós de sistema distribuído. Um novo nó a iniciar num cluster gera um UUID para si mesmo; o coordenador do cluster usa esse ID para encaminhar tráfego e identificar o nó nos logs.

Alternativas que vale a pena conhecer

UUID é o por defeito universal mas não a única opção, e várias alternativas valem a pena ser conhecidas para casos de uso específicos. ULID (Universally Unique Lexicographically Sortable Identifier, Alex Knol, ~2016): 128 bits como UUID, mas codificado como 26 caracteres Crockford-Base32 em vez de 32 dígitos hex, mais compacto e URL-safe insensível a maiúsculas/minúsculas. Os primeiros 48 bits são um timestamp Unix em milissegundos, por isso ULIDs ordenam-se lexicograficamente por tempo de criação. Conceptualmente muito próximo de UUID v7, precedendo-o por anos. Snowflake (Twitter, 2010): 64 bits, muito mais pequeno que UUID, cabe num BIGINT SQL. 41 bits de timestamp + 10 bits de ID de máquina + 12 bits de sequência por milissegundo. Usado pelo Twitter/X, Discord, Instagram, e muitos sistemas à escala onde chaves primárias de 64 bits são uma restrição rígida. KSUID (Segment, 2017): 27 caracteres, timestamp com precisão de segundo + 128 bits de aleatoriedade. Troca precisão de milissegundo por uma representação de string mais pequena que UUID. nanoid (Andrey Sitnik, 2017): uma biblioteca minúscula que produz identificadores aleatórios URL-safe de comprimento configurável. O por defeito de 21 caracteres fornece resistência a colisões semelhante a UUID v4 em muito menos bytes. Para uma URL pública onde de outra forma incorporaria um UUID, nanoid é mais curto e mais amigável. O trade-off: identificadores nanoid não têm os bits marcadores de versão + variant que os distinguem como UUIDs, por isso não encaixam em sistemas que esperam valores com forma de UUID.

Segurança de URL e variações de formato

UUIDs na sua forma canónica com hífenes (550e8400-e29b-41d4-a716-446655440000) são URL-safe, cada carácter (letras minúsculas, dígitos, hífenes) está no conjunto não reservado definido pelo RFC 3986. Isto significa que pode deixar cair um UUID directamente num path de URL ou query string sem percent-encoding. Alguns sistemas retiram os hífenes por compactidade, produzindo uma string hex de 32 caracteres (550e8400e29b41d4a716446655440000) que ainda é URL-safe; a conversão é reversível porque a estrutura UUID é fixa. Alguns sistemas envolvem UUIDs em chavetas ({550e8400-e29b-41d4-a716-446655440000}), a convenção GUID da Microsoft; as chavetas são decorativas e nunca viajam em URLs. Alguns sistemas põem os caracteres hex em maiúsculas; os UUIDs são insensíveis a maiúsculas/minúsculas segundo a spec, mas a consistência dentro de um sistema importa. Este gerador oferece todas as três opções (maiúsculas, chavetas, sem hífenes) para compatibilidade com qualquer pipeline a que esteja a alimentar os UUIDs.

UUID vs GUID, a mesma coisa, nome diferente

UUID é o termo padrão usado pela IETF, ISO e a maioria dos projectos open-source. GUID (Globally Unique Identifier) é o termo Microsoft usado em Windows, .NET, COM/OLE, SQL Server, Active Directory e o Registo Windows. Ambos referem-se ao identificador idêntico de 128 bits no mesmo formato hex 8-4-4-4-12. Funcionalmente intermutáveis, um GUID gerado pelo Windows pode ser usado em qualquer lugar onde um UUID seja esperado, e vice-versa. A única diferença que vale a pena conhecer: a geração de GUID da Microsoft historicamente usou UUID v4 em muitas APIs mas UUID v1 (com endereço MAC) em alguns contextos COM/OLE mais antigos; isto está documentado na especificação COM da Microsoft. Se receber um GUID de um sistema de origem Microsoft e quiser saber qual versão é, verifique o nibble de versão (o 13º carácter hex, '1' para v1, '4' para v4, etc.).

Privacidade: porque é que apenas-no-navegador importa mesmo aqui

Um UUID não tem significado intrínseco, então porque importa que o gerador corra localmente? Duas razões. Primeiro, quando um UUID é usado como token de sessão, chave de idempotência ou qualquer outro identificador tipo-segredo, gerá-lo num servidor de terceiros significa que esse servidor viu o valor antes de você o usar, uma exposição pequena mas real. Segundo, geradores do lado do servidor que prometem «aleatoriedade criptográfica» não podem ser verificados pelo utilizador; um servidor com bug ou malicioso poderia retornar valores não aleatórios que parecem aleatórios, e não teria forma de detectar o viés. Um gerador apenas-no-navegador executa a mesma chamada crypto.randomUUID() que a sua aplicação executaria no lado do servidor; a entropia vem da mesma fonte do sistema operativo (Linux getrandom(), Windows BCryptGenRandom, macOS SecRandomCopyBytes); nenhum terceiro vê a saída. Pode verificar abrindo o separador Network das DevTools enquanto clica em Gerar, não há pedidos de saída. Ponha a página offline (modo avião) depois de carregar e o gerador continua a funcionar.

Perguntas frequentes

Qual é a diferença entre UUID e GUID?

Eles são essencialmente a mesma coisa. UUID é o termo padrão (RFC 4122), enquanto GUID (Globally Unique Identifier) é a terminologia da Microsoft. Ambos se referem a um identificador de 128-bit no mesmo formato hexadecimal 8-4-4-4-12.

Dois UUIDs podem ser iguais?

Teoricamente sim, mas a probabilidade é astronomicamente baixa. O UUID v4 tem 122 bits aleatórios, dando cerca de 5.3 × 10³⁶ valores possíveis. Seria necessário gerar bilhões de UUIDs por segundo durante décadas para ter 50% de chance de uma única colisão.

Estes UUIDs são criptograficamente seguros?

Sim. Este gerador usa a Web Crypto API (crypto.getRandomValues), que fornece valores aleatórios criptograficamente fortes. A saída é adequada para casos de uso sensíveis à segurança, como tokens de sessão.

Devo usar UUID v4 ou v7 para a minha chave primária de base de dados?

v7 é a recomendação moderna se a sua base de dados a suportar. v4 (aleatória) insere em posições aleatórias em índices B-tree, fragmenta o índice, e estraga a cache de páginas. v7 (timestamp + aleatório, RFC 9562 Maio 2024) insere na borda direita do índice porque os IDs ordenam-se por tempo de criação, mesma performance de escrita que inteiros auto-incrementais, com a distribuição e unicidade dos UUIDs. Postgres 18+ tem uuidv7() incorporado. O trade-off: v7 revela o tempo de criação de cada linha, o que pode ser uma preocupação de privacidade em algumas aplicações. Para a maioria dos casos de uso, o ganho de performance supera a fuga de timestamp.

O que são ULID, KSUID e nanoid?

Formatos de ID alternativos. ULID (Alex Knol, ~2016): 128 bits como UUID mas codificados como 26 caracteres Crockford-Base32; ordena lexicograficamente por timestamp. KSUID (Segment, 2017): 27 caracteres, timestamp com precisão de segundo + 128 bits aleatórios. nanoid (Andrey Sitnik, 2017): biblioteca minúscula que produz IDs aleatórios URL-safe de comprimento configurável; o por defeito de 21 caracteres dá resistência a colisões semelhante a UUID v4 em muito menos bytes. Snowflake (Twitter, 2010): IDs de 64 bits que cabem num BIGINT SQL, usados pelo Twitter, Discord e Instagram. Use UUID quando o sistema receptor espera formato UUID; use as alternativas quando tiver requisitos específicos de tamanho, ordenabilidade ou amizade-de-URL.

Os UUIDs são enviados para algum lugar?

Não. Cada UUID é gerado localmente no seu navegador usando a API Web Crypto. O gerador nunca faz um pedido de rede, verifique no separador Network das DevTools enquanto clica em Gerar, ou ponha a página offline depois de carregar e confirme que a ferramenta continua a funcionar. Seguro para gerar tokens de sessão, chaves de idempotência ou outros identificadores onde não queira que um terceiro tenha visto o valor antes de você o usar.

Ferramentas relacionadas