Ferramentas para desenvolvedores · Gerador UUID
UUID Versões 1 a 8 explicadas: qual você deve gerar?
· Fundo
uuid criptografia APIs do navegador
Oito versões compartilham um formato, mas resolvem problemas diferentes: ordenação temporal, reprodutibilidade, aleatoriedade ou layouts personalizados. Esta postagem explica cada um e fornece um caminho de decisão.
Um formato, oito receitas – por que a versão é importante quando você escolhe uma função de biblioteca
O padrão UUID define um formato 128 bits como trinta e seis caracteres hexadecimais com hífens. RFC 9562 define oito receitas distintas – versões um a oito – para preencher esses bits com diferentes padrões e significados. A versão nibble (primeiro caractere do terceiro grupo) identifica qual método produziu o valor, servindo como rótulo. Escolher a versão errada significa armazenar informações temporais desnecessárias, perder garantias de ordenação para desempenho do banco de dados ou entender mal as funções de segurança do identificador. Esta postagem aborda cada versão, qual problema concreto ela resolve, quando os desenvolvedores a encontram na prática e fornece uma estrutura de decisão para selecionar a versão certa para seus requisitos específicos de sistema.
v1 e v6: time plus node — o layout original baseado em tempo e a versão reordenada que classifica corretamente
A versão 1 combina um carimbo de data / hora de 60 bits com um identificador de nó (originalmente um endereço MAC, embora as implementações modernas usem valores aleatórios para evitar vazamento de informações de hardware). O carimbo de data/hora registra intervalos de 100 nanossegundos desde outubro 15, 1582. O campo do nó pode revelar quando o identificador foi gerado e onde ele se originou geograficamente, e é por isso que as implementações modernas evitam endereços MAC. A versão 6 reorganiza o mesmo carimbo de data/hora e informações de nó para melhorar a classificação, movendo bits de tempo de alta ordem para a frente, fazendo com que os UUIDs da v6 sejam classificados corretamente em ordem lexicográfica. Se o seu aplicativo precisar de UUIDs que classifiquem naturalmente por hora de criação com localidade de índice superior, a v6 é a escolha moderna.
v2: DCE Segurança — a variante raramente usada que incorpora identificadores POSIX
A versão 2 raramente é usada em novos sistemas. Ele incorpora identificadores de usuário ou grupo POSIX no layout UUID, tornando-o útil apenas em ambientes legados onde esses identificadores carregam significado organizacional. O design v2 assume um modelo de computação específico (DCE Security) que é incomum em sistemas distribuídos modernos. A maioria das organizações associa UUIDs a usuários ou grupos em sua camada de aplicação por meio de junções de banco de dados ou tabelas de pesquisa, e não codificando o ID do usuário no próprio identificador. Essa separação de preocupações facilita a alteração de modelos de autorização, a migração de dados de usuários e a manutenção de trilhas de auditoria. A codificação de credenciais diretamente em UUIDs cria um acoplamento forte e dificulta a evolução dos sistemas.
v3 e v5: baseado em nome — IDs determinísticos com hash de um namespace e um nome com MD5 ou SHA-1
As versões 3 e 5 UUIDs são determinísticas: o mesmo namespace e nome sempre produzem o mesmo identificador, ideal para representar mapeamentos estáveis de dados externos. A versão 3 usa MD5 e a versão 5 usa SHA-1 como algoritmos de hash, refletindo suas respectivas idades e adoção. Quando um registro de cliente chega para importação, um UUID v5 derivado de um namespace fixo será idêntico em várias execuções de importação, evitando registros duplicados. Esse determinismo significa que UUID é reproduzível e previsível para qualquer pessoa que conheça o namespace e a entrada. O valor prático brilha em cenários de integração de dados: reconciliação de registros de clientes de vários sistemas, prevenção de duplicatas em importações recorrentes e atribuição de IDs estáveis a itens.
v4: aleatório — 122 bits de um CSPRNG e a escolha padrão ao fazer o pedido não importa
A versão 4 é a escolha padrão quando o pedido não é necessário e você deseja geração independente sem coordenação central. Um UUID v4 é composto por 122 bits de uma fonte aleatória criptograficamente segura, com seis bits definidos para valores fixos (nibble de versão 4 e RFC 9562 bits variantes 10). A aleatoriedade é o ponto principal: cada chamada produz um valor diferente, as colisões permanecem extremamente improváveis e nenhum estado externo ou coordenação é necessário. É a versão que ToolAcre gera usando crypto.randomUUID() ou crypto.getRandomValues(). Esta versão é adequada para referências de objetos, dados não estruturados e a maioria das funções fora de chaves primárias ou contextos de classificação.
v7 e v8: Unix time and custom — a versão moderna ordenada por tempo para chaves de banco de dados e a saída de emergência para layouts personalizados
A versão 7, padronizada em RFC 9562, traz propriedades modernas ordenadas por tempo para o formato UUID. Ele usa um carimbo de data / hora Unix de milissegundos de 48 bits, 12 bits de precisão inferior a milissegundos e 62 bits aleatórios combinados. O carimbo de data/hora de milissegundos Unix é válido até o ano 10889, tornando-o adequado para sistemas. O resultado é classificado corretamente em ordem lexicográfica e cabe em uma coluna UUID padrão de 128 bits sem manipulação especial ou conversão de codificação. Se seu aplicativo precisar de identificadores classificados por hora de criação no formato UUID padrão, v7 é a prática recomendada atual. A versão 8 é um pacote padronizado para formatos definidos pela implementação, útil apenas se você precisar de layouts de bits específicos não cobertos pela v1-v7.
Exemplo resolvido — um caminho de decisão aplicado a três cenários: uma referência pública API, uma chave primária e um ID estável para registros importados
Três cenários do mundo real ilustram a seleção de versão: primeiro, uma referência pública API deve ser estável em instâncias API, não deve vazar o tempo de criação e deve ser a mesma nas reinicializações do servidor, para que instâncias diferentes gerem a mesma referência para o mesmo documento. Use v5 com um namespace e nome de documento estáveis. Segundo, uma chave primária para uma tabela em crescimento contínuo precisa ser única, não deve causar fragmentação do índice e deve ser gerada por qualquer instância de aplicação sem coordenação central. Use v7 para identificadores classificáveis com suporte padrão ao ecossistema UUID. Terceiro, os registros arquivados que exigem pesquisa estável precisam de identificadores imutáveis.
Conclusão: escolha por propriedade, não por hábito — o gerador ToolAcre produz UUIDs aleatórios a partir do CSPRNG do navegador para os casos que exigem v4
A seleção da versão segue o design do esquema e os requisitos do sistema, não por convenção ou familiaridade. UUIDs aleatórios (v4) são o padrão porque não requerem estado ou coordenação e produzem identificadores independentes adequados para a maioria das funções. Versões ordenadas por tempo (v6, v7) resolvem problemas de localidade de índice ao custo de vazamento de informações temporais ou requisitos de sincronização de relógio. Versões determinísticas (v3, v5) evitam importações duplicadas e permitem mapeamentos externos estáveis ao custo da previsibilidade – qualquer pessoa que conheça seu namespace pode recalculá-los. ToolAcre gera UUIDs v4 aleatórios a partir do gerador criptograficamente seguro do navegador. Quando você precisar de uma versão diferente, a verificação bem formada confirma que os identificadores analisados são válidos.