O que é o UUID v7 e como funciona este gerador
O gerador de UUID v7 da BroBroGo cria identificadores únicos de 36 caracteres que combinam um carimbo temporal Unix de 48 bits (milissegundos) com bits aleatórios. Basta indicar uma quantidade entre 1 e 100 e escolher o formato (maiúsculas ou minúsculas, com ou sem hífenes) e o resultado aparece instantaneamente. Cada identificador pode ser copiado individualmente ou todos de uma vez. A grande novidade é que os UUIDs v7 são ordenáveis por data de criação — resolvem o problema de localidade de índice que aflige o UUID v4 — e permanecem criptograficamente imprevisíveis.
Nada é enviado para os servidores da BroBroGo: a geração é feita localmente no browser, usando a função crypto.getRandomValues() e o timestamp do sistema. Isto garante privacidade e baixa latência. O utilizador escolhe o número de IDs, activa ou desactiva maiúsculas e hífenes, e o ecrã mostra uma lista limpa com o estado "Pronto." ou "Gerado." após cada operação. Se copiar todos, aparece "Copiado tudo!".
A estrutura do UUID v7: timestamp mais aleatoriedade
O UUID v7 é definido na especificação RFC 9562 (sucessora da RFC 4122). Ocupa 128 bits, representados como uma string de 36 caracteres no formato xxxxxxxx-xxxx-7xxx-yxxx-xxxxxxxxxxxx. Os primeiros 48 bits são o timestamp Unix em milissegundos, em big-endian. Os 74 bits seguintes são aleatórios, sendo que 4 bits identificam a versão (7) e 2 bits identificam a variante (10). O resultado é uma sequência como 018f3a6e-7a3c-7b00-8000-1a2b3c4d5e6f.
A parte temporal faz com que dois UUIDs gerados em momentos diferentes ordenem cronologicamente. Contudo, se forem criados no mesmo milissegundo, a ordem entre eles é arbitrária — o gerador não insere um contador incremental. Isto é uma escolha deliberada da norma, que prefere simplicidade e paralelismo a uma ordenação estrita dentro do mesmo milissegundo. Para aplicações que exigem ordenação fina mesmo em alta concorrência, é necessário um mecanismo externo (como um contador monotónico).
O random de 74 bits (aproximadamente 2,36×10²² valores) torna a colisão praticamente impossível para volumes realistas. A geração no browser utiliza crypto.getRandomValues(), que fornece aleatoriedade criptograficamente forte — adequada para tokens de sessão, chaves de API ou identificadores de eventos.
Porque a ordenação temporal importa para bases de dados
O UUID v4 é completamente aleatório: os seus 122 bits de aleatoriedade distribuem-se uniformemente. Quando usado como chave primária em bases de dados relacionais (PostgreSQL, MySQL, SQL Server), o índice B‑tree sofre fragmentação porque os valores inseridos não têm relação com a ordem de chegada. Isto obriga a rebalanceamentos frequentes, reduz o desempenho de escrita e aumenta o espaço em disco.
O UUID v7 resolve este problema: as primeiras letras do identificador reflectem o momento da criação. Inserções consecutivas caem em páginas de índice próximas, minimizando a fragmentação. O ganho é mais notório em tabelas com muitas escritas concorrentes — até 5× a taxa de inserção em alguns benchmarks. Além disso, a ordenação por ORDER BY id reflecte a ordem cronológica, útil para auditorias, event sourcing e logs.
No entanto, há uma nuance: como a ordenação não é estrita dentro do mesmo milissegundo, duas inserções no mesmo milissegundo podem aparecer trocadas. Para a maioria dos casos, o erro é irrelevante; para sistemas que exigem ordem total, é preciso adicionar um campo created_at separado ou usar ULID (que inclui um contador de 10 bits).
Comparação com UUID v4 e outros formatos
| Formato | Tamanho (caracteres) | Base temporal | Aleatoriedade | Ordenável | Colisão (risco) |
|---|---|---|---|---|---|
| UUID v4 | 36 | Não | 122 bits | Não | Muito baixo |
| UUID v7 | 36 | 48 bits | 74 bits | Sim (ms) | Muito baixo |
| ULID | 26 | 48 bits | 80 bits | Sim (ms) | Muito baixo |
| NanoID | 21 (padrão) | Não | ~126 bits* | Não | Baixo |
- UUID v4 continua a ser útil quando a ordenação não é relevante e se quer máxima imprevisibilidade.
- ULID é mais curto (26 caracteres, base32) e inclui um contador de 10 bits que garante ordenação estrita dentro do mesmo milissegundo. Mas não é um formato RFC e não tem hífenes.
- NanoID usa um alfabeto URL‑safe, mas não oferece ordenação temporal.
- UUID v7 é o formato canónico recomendado pela IETF para novos sistemas que precisam de ordenação e compatibilidade com a sintaxe UUID.
O gerador da BroBroGo foca‑se exclusivamente em UUID v7, mas permite alternar entre maiúsculas e minúsculas e remover os hífenes (útil para armazenamento compacto, embora aí perca o formato padrão).
Opções de personalização: maiúsculas e hífenes
O gerador oferece duas opções que alteram a representação textual do UUID v7:
- Maiúsculas: por omissão, os hexadecimais são minúsculos (
a-f). Activar esta opção converte‑os para maiúsculas (A-F). O formato padrão da RFC usa minúsculas, mas muitas bases de dados e sistemas legacy preferem maiúsculas. A escolha é puramente estética; ambos representam o mesmo valor de 128 bits. - Incluir hífenes: os hífenes separam os grupos de 8-4-4-4-12 caracteres. Removê‑los produz uma string contínua de 32 caracteres hexadecimais (
018f3a6e7a3c7b0080001a2b3c4d5e6f). Isto reduz o tamanho em 4 bytes e torna o ID mais fácil de copiar para campos numéricos, mas não é um UUID válido segundo a RFC.
Ambas as opções regeneram imediatamente a lista quando alteradas. Isto é útil para testar formatos diferentes sem precisar de recarregar a página.
Privacidade e geração local no browser
Ao contrário de muitos serviços online que geram IDs no servidor e depois os devolvem, este gerador executa todo o código no browser do utilizador. O timestamp e a aleatoriedade são obtidos via JavaScript, sem qualquer pedido HTTP. Isto significa que:
- Nenhum dado sai do computador.
- Não há logs de IP ou de timestamps gerados.
- O gerador funciona mesmo sem ligação à Internet (depois de carregada a página).
- A latência é nula — os IDs aparecem no mesmo instante.
Para quem trabalha com dados sensíveis (identificadores de pacientes, transacções financeiras, chaves de sessão), esta abordagem elimina o risco de intercepção ou armazenamento indevido. O utilizador mantém o controlo total sobre a geração.
FAQ
1. Posso usar UUID v7 como chave primária numa base de dados?
Sim, e é uma boa prática para sistemas com muitas escritas. A ordenação temporal reduz a fragmentação de índice. No entanto, tenha em conta que a ordenação não é estrita dentro do mesmo milissegundo — se precisar de ordem total, combine com um campo created_at ou considere ULID.
2. Qual a diferença entre UUID v7 e ULID?
Ambos ordenam por timestamp: UUID v7 usa 48 bits de tempo (como ULID) mas tem 36 caracteres com hífenes. ULID é mais curto (26 caracteres) e garante ordenação estrita dentro do mesmo milissegundo graças a um contador de 10 bits. O UUID v7 é o formato padrão IETF; ULID é uma especificação da comunidade.
3. É seguro gerar UUID v7 no browser?
Sim, desde que o browser suporte crypto.getRandomValues() (todos os modernos). Esta função fornece aleatoriedade criptograficamente forte, adequada para identificadores secretos. A geração local impede que os IDs sejam interceptados durante a transmissão.
4. Porque não posso gerar mais de 100 UUIDs de cada vez?
O limite de 100 é uma restrição de usabilidade para evitar listas demasiado longas que dificultem a cópia manual. Se precisar de milhares, execute o gerador várias vezes ou utilize uma ferramenta de linha de comandos.
5. Os UUIDs gerados são realmente únicos?
Sim, para todos os fins práticos. Com 74 bits de aleatoriedade, a probabilidade de colisão ao gerar 1 bilião de IDs é inferior a 1 em 10¹⁴. A adição do timestamp reduz ainda mais o risco, pois IDs de momentos diferentes têm prefixos diferentes.
6. Devo usar maiúsculas ou minúsculas?
É indiferente para a unicidade. Algumas bases de dados tratam maiúsculas como maiúsculas e minúsculas como minúsculas, causando problemas de comparação. Por isso, a escolha mais segura é manter o formato minúsculo (padrão RFC). Se o sistema legacy exigir maiúsculas, active a opção.