Ferramentas para desenvolvedores · Gerador UUID
RFC 4122 vs RFC 9562: O que mudou no padrão 2024 UUID
· Fundo
uuid criptografia APIs do navegador
Dois RFCs são citados para UUIDs e não dizem exatamente a mesma coisa. Esta postagem aborda o que RFC 9562 adicionou, esclareceu e descontinuou em relação a RFC 4122.
Qual RFC devo citar? — a confusão quando documentação e bibliotecas fazem referência a padrões diferentes
Dois RFCs são citados rotineiramente na documentação UUID e não dizem coisas idênticas. RFC 4122, publicado em 2005, definiu UUIDs e suas cinco versões (v1 a v5). RFC 9562, publicado em 2024, obsoleta RFC 4122 inteiramente, esclarece ambiguidades que os profissionais contornaram, adiciona três novas versões (v6, v7, v8) e atualiza as orientações sobre a implementação da aleatoriedade. Quando uma biblioteca cita RFC 4122, não está errado - essa biblioteca pode ter sido lançada antes de RFC 9562 ser publicada ou os mantenedores podem não ter a documentação atualizada. A verificação das citações RFC informa quando uma biblioteca foi atualizada significativamente pela última vez. Ao escrever novas especificações ou avaliar implementações, RFC 9562 é a referência normativa.
Obsoletar, não substituir o formato — tudo válido em RFC 4122 permanece válido; o layout e os bits variantes permanecem inalterados
RFC 9562 formalmente obsoleto RFC 4122 como o documento de referência atual, mantendo a representação familiar de 128 bits, grupos hexadecimais, posição de versão e layout de variante principal. As strings UUID existentes armazenadas não precisam ser reemitidas apenas porque existe uma RFC mais recente. A migração prática está na documentação, nos geradores e na política de validação: citar o padrão atual, entender as versões adicionadas e verificar se o código antigo dependia de uma ambiguidade que a revisão esclareceu. A compatibilidade ainda deve ser testada nos limites do sistema, especialmente quando uma biblioteca serializa estruturas Microsoft GUID ou impõe um conjunto mais restrito de versões do que o padrão descreve.
Três novas versões - v6 (tempo reordenado), v7 (ordenado por tempo da época Unix) e v8 (definido pela implementação)
RFC 9562 adiciona três novas versões ao padrão. A versão 6 reordena os bits do carimbo de data/hora v1 para produzir identificadores lexicograficamente classificáveis para melhor desempenho do banco de dados. A versão 7 usa um carimbo de data / hora Unix de milissegundos de 48 bits seguido por bits aleatórios, fornecendo geração ordenada por tempo sem preocupações de privacidade da v1. A versão 8 é uma saída de emergência para layouts definidos pela implementação. Nenhuma dessas versões altera o funcionamento da v1-v5 ou o que elas significam. Um UUID v1 de 2005 e um UUID v7 de 2024 podem coexistir no mesmo banco de dados, cada um com seus bits de versão identificando seu método de geração. As três novas versões abordam padrões comuns que surgiram na prática.
Max UUID junta-se a Nil - o valor totalmente F definido junto com o valor totalmente zero
RFC 4122 documentou o Nil UUID (todos zero bits) como um valor de referência especial em exemplos e documentação. RFC 9562 inclui a mesma definição Nil, mas define formalmente o Max UUID (todos os bits definidos como um) para limites de intervalo. Nem Nil nem Max são uma versão 4 aleatória UUID porque não possuem versão correta e bits variantes. O Max UUID é útil como um limite de intervalo superior em consultas de banco de dados: WHERE uuid_column <= MAX_UUID corresponde a todos os UUIDs possíveis. Nil é útil como sentinela para colunas UUID não atribuídas anuláveis. RFC 9562 documenta ambos sem obrigar seu uso em dados de aplicativos.
Orientação esclarecida — conselhos explícitos para usar um CSPRNG para campos aleatórios, em contadores monotônicos dentro de um milissegundo e sobre a preferência de versões ordenadas por tempo para localidade do banco de dados
A orientação de práticas recomendadas de RFC 9562 distingue a resistência à colisão da imprevisibilidade. Os campos aleatórios devem usar uma fonte apropriada ao modelo de ameaça do aplicativo, e a opacidade sensível à segurança exige um CSPRNG. Os geradores baseados em tempo têm um problema de monotonicidade separado quando vários identificadores compartilham um tick de carimbo de data/hora; o padrão descreve contadores e precisão adicional de carimbo de data/hora como métodos possíveis, cada um com regras de estado e de substituição. As versões baseadas em nomes permanecem identificadores determinísticos, não como provas de autenticidade. Esses esclarecimentos são importantes porque um analisador UUID pode aceitar todos os layouts, mesmo que seus requisitos de geração e propriedades de divulgação de informações sejam diferentes.
Onde as ideias de ULID aparecem — como o formato da comunidade influenciou o design da v7
RFC 9562 afirma que seus autores analisaram vários esquemas de identificadores classificáveis existentes, incluindo ULID, Snowflake e KSUID, enquanto desenvolviam os novos layouts. Isto apoia uma conclusão modesta: a procura operacional por identificadores distribuídos e ordenados no tempo informou a revisão. Isso não prova que um formato de comunidade tenha doado um layout de campo exato para a versão 7. A semelhança prática é suficiente para o trabalho de arquitetura: essas famílias colocam as informações de tempo perto da frente para que a ordem comum possa preservar a ampla ordem de criação e, em seguida, diferem na codificação, na coordenação e no comportamento dentro do tick. Escolha entre eles pela compatibilidade do ecossistema e pelas garantias documentadas, em vez de uma reivindicação de ancestralidade direta.
O que isso não cobre — uma diferença linha por linha; esta postagem segue as consequências práticas para os implementadores
Esta postagem abrangente segue as consequências práticas e a implementação de RFC 9562 para implementadores e usuários, não diferenças linha por linha contra RFC 4122. As especificações completas estão disponíveis nos órgãos de padronização e vale a pena ler para implementar o tratamento UUID em linguagens ou plataformas – o texto fornece detalhes confiáveis além do que uma visão geral pode cobrir. Esta postagem não descreve a mecânica em nível de bit de como a v6 reordena os bytes da v1 ou como a v7 codifica milissegundos Unix. Tanto os padrões quanto os guias de implementação continuam sendo a principal referência oficial para qualquer questão de implementação relacionada ao layout de bits, codificação ou verificação de conformidade.
Conclusão: atualize suas citações e seus padrões - o gerador ToolAcre segue a orientação CSPRNG que ambos os RFCs compartilham
Para qualquer novo trabalho, atualize a documentação e as especificações para citar RFC 9562. Cada UUID de RFC 4122 permanece válido sob RFC 9562 – a migração é puramente prospectiva e de natureza administrativa. A orientação esclarecida sobre a aleatoriedade criptográfica reforça que os identificadores devem provir de fontes criptograficamente seguras em sistemas de produção. ToolAcre segue as orientações de aleatoriedade criptográfica de ambos os RFCs, usando exclusivamente o Web Crypto API do navegador. Quando você encontra um UUID em logs, exportações de banco de dados ou respostas API, a verificação bem formada ToolAcre relata sua versão e variante em relação a RFC 9562. RFC 9562 é o esclarecimento e a modernização de um padrão já estável.