Ferramentas para desenvolvedores · Gerador UUID
Lendo um UUID manualmente: onde residem a versão e os bits variantes
· Como funciona
uuid criptografia APIs do navegador
Dois caracteres hexadecimais em cada UUID informam qual versão o produziu e qual layout variante ele segue. Aprenda a lê-los rapidamente e a saber o que eles não podem lhe dizer.
Qual sistema fez esse ID? - a questão log-forense que a versão nibble pode responder
Uma string UUID possui 36 caracteres: trinta e dois dígitos hexadecimais e quatro hifens nas posições 8-4-4-4-12. Dois caracteres em cada UUID - aparecendo nas posições 14 e 19 - codificam metadados: o campo de versão informa qual algoritmo gerou o ID e o campo de variante informa qual layout padrão ele segue. Ler esses dois caracteres sem ferramentas é a habilidade forense de log: você identifica um UUID em um dump de banco de dados ou mensagem de erro e sabe imediatamente se é um carimbo de data/hora v1 (que vaza o tempo de criação), um valor aleatório v4 (que foi gerado a partir de um CSPRNG) ou qualquer outra coisa. O número da versão ocupa os bits 48–51 do UUID, que mapeia para o primeiro caractere hexadecimal do terceiro grupo.
O layout de 128 bits em cinco grupos — como 8-4-4-4-12 mapeia em bytes e por que os grupos são históricos, não funcionais
Para a sequência xxxxxxxx-xxxx-4xxx-xxxx-xxxxxxxxxxxx, o caractere na posição 14 é a versão. RFC 9562 define versões 1 até 8: v1 é baseado no tempo gregoriano e vaza o tempo de criação; v4 é aleatório; v7 é baseado em tempo Unix e classificável. As versões 0, 9 e superiores são reservadas ou não utilizadas. Se você vir uma v1 UUID, você sabe que a hora e o endereço de hardware foram misturados; se você vir v4, o ID é bytes aleatórios com bits de versão definidos; se você vir a v7, ela será classificada por hora de criação. A versão não é opcional; todo UUID formado corretamente tem um. O campo variante ocupa os bits 64–65 do UUID, os dois bits mais significativos do octeto 8.
A versão nibble - o primeiro caractere do terceiro grupo, o que significa 1 a 8 e o que 0 ou 9 indica
Na representação de texto xxxxxxxx-xxxx-xxxx-Nxxx-xxxxxxxxxxxx, o primeiro caractere do quarto grupo (posição 19) codifica a variante. Para a variante RFC 9562 (o padrão em uso moderno), esse caractere deve ser 8, 9, a ou b - as representações hexadecimais de 1000, 1001, 1010 e 1011 em binário. Qualquer outro caractere (0–7, c–f) indica uma variante diferente: 0–7 são NCS compatibilidade com versões anteriores; c – d são GUIDs legados da Microsoft com ordem de bytes little-endian; e–f são reservados. Quando você lê a posição 19 e vê 8, 9, a ou b, você está olhando para um RFC 9562 UUID. Qualquer outro valor significa que os bytes seguem uma interpretação diferente. O layout de 128 bits se divide em octetos 0–15, mas o formato de texto os separa por grupos para facilitar a leitura, não para funcionar.
O campo variante - por que o primeiro caractere do quarto grupo é 8, 9, a ou b para UUIDs RFC e qual sinal c/d (herdado da Microsoft) ou 0–7 (NCS)
Os cinco grupos representam limites históricos do campo: os três primeiros campos contêm o carimbo de data/hora e a versão nos UUIDs v1, o quarto campo contém a sequência do relógio e a variante, o quinto campo contém o identificador do nó. A versão 4 e versões posteriores UUID não usam esses nomes de campo, mas as mesmas posições de bits ainda carregam a versão e a variante. Ler um UUID v4 significa aceitar que a maioria dos 128 bits são cargas aleatórias, mas dois deles - nas posições 14 e 19 no texto - são fixos por padrão. Esses bits fixos provam que o ID é uma variante v4 e RFC. O nil UUID é 00000000-0000-0000-0000-000000000000, todos zeros, e não carrega nenhuma versão. O máximo UUID é ffffffff-ffff-ffff-ffff-ffffffffffff, todos os caracteres f, e também é reservado e não versionado.
Exemplo resolvido - decodificando três identificadores de amostra caractere por caractere, incluindo v4 e v7
Todos os outros UUID bem formados têm uma versão no terceiro grupo e uma variante no quarto. Teste-se com três IDs de amostra: 123e4567-e89b-12d3-a456-426614174000 (v1, variante RFC porque a posição 19 é a); 9b2e4f1a-4f3e-4c1a-8a7d-1b2c3d4e5f60 (v4, variante RFC porque a posição 19 é 8); 018f0c2e-1b5a-7c3d-9e4f-5a6b7c8d9e0f (v7, variante RFC porque a posição 19 é 9). O inspetor ToolAcre confirma sua leitura. Uma verificação de formato não pode informar se um ID é exclusivo, existe em seu banco de dados ou foi gerado com segurança. A versão v1 usa tempo e hardware como entradas, portanto, UUIDs v1 idênticos de máquinas diferentes significam distorção do relógio ou problemas de sincronização. A versão v4 é aleatória, portanto, uma v4 UUID duplicada significa aleatoriedade quebrada ou uma colisão astronomicamente improvável (aproximadamente uma por 2. 7 trilhões de UUIDs com aleatoriedade sonora).
Nil e Max - os dois valores totalmente zero e totalmente F que não carregam nenhuma versão
Uma versão 0 ou 9 significa que a string não é um UUID válido. Ler a versão e a variante é o primeiro passo para entender o que é um ID; verificar se ele existe ou é exclusivo é a segunda e a terceira etapas, realizadas pelo seu banco de dados e pela lógica de negócios. Compreender as posições dos bits ajuda a depurar as migrações de dados. Ao importar UUIDs de sistemas legados, algumas ferramentas exportam campos variantes que não correspondem ao padrão RFC 9562. Um campo variante de c ou d indica um Microsoft GUID na ordem de bytes little-endian. Esses GUIDs são identificadores válidos em sistemas Microsoft, mas não interoperam com UUIDs RFC 9562 sem conversão de ordem de bytes. A posição de leitura 19 informa imediatamente qual sistema gerou o ID. Se você vir 8, 9, a ou b, você tem um padrão RFC UUID.
O que uma verificação de formato não pode dizer: se o ID existe no seu banco de dados, se foi gerado com segurança ou se é exclusivo
Se você vir c ou d, você tem um Microsoft GUID. Se você vir qualquer outro caractere, o identificador está malformado ou é proveniente de um sistema obscuro. O gerador ToolAcre sempre produz UUIDs RFC 9562 com posição 19 como um de 8, 9, a ou b. O campo de versão de três bits codifica sete valores possíveis (1–7; versão 0 e 8 têm significados especiais). A versão 1 é um carimbo de data/hora gregoriano, a versão 3 é um namespace baseado em MD5, a versão 4 é aleatória, a versão 5 é um namespace baseado em SHA-1, a versão 6 é baseada em carimbo de data/hora Unix (proposta), a versão 7 é classificável com base em carimbo de data / hora Unix (padronizada em RFC 9562), a versão 8 é reservada para formatos personalizados. A leitura do caractere position-14 informa imediatamente qual algoritmo foi usado. Se você estiver depurando colisões UUID ou classificações inesperadas, o número da versão é sua primeira pista. ToolAcre gera UUIDs v4 exclusivamente de criptografia.
Conclusão: dois caracteres, muito contexto - use a verificação ToolAcre bem formada para confirmar a análise de uma string e, em seguida, leia a versão mordiscar você mesmo
getRandomValues; cada UUID produzido tem um 4 na posição 14. Analisar a estrutura UUID manualmente é uma habilidade útil para depurar sistemas complexos onde as ferramentas não estão disponíveis. Em um incidente de produção, talvez seja necessário ler UUIDs de um despejo de banco de dados, log de erros ou cache sem executar uma ferramenta especial. Você procura a posição 14 para identificar a versão (vaza na hora? é aleatório? é classificável?). Você procura a posição 19 para identificar a variante (é padrão RFC? é um GUID da Microsoft? é reservado?). Esses dois caracteres, do total de 36, carregam os metadados. Os caracteres 34 restantes são carga útil: carimbo de data/hora ou bytes aleatórios ou outros dados específicos do algoritmo. Saber o que a carga representa ajuda você a entender a função do ID em seu sistema.