Ferramentas para desenvolvedores · Gerador UUID
GUID vs UUID: chaves, ordem de bytes e variante da Microsoft explicadas
· Fundo
uuid criptografia APIs do navegador
GUID é o nome da Microsoft para UUID, mas as chaves, letras maiúsculas e ordem de bytes podem fazer com que o mesmo identificador pareça diferente entre plataformas. Este post explica cada diferença e como comparar com segurança.
O mesmo ID que não corresponde entre sistemas — um serviço .NET e um serviço Java discordando sobre um registro
Um serviço .NET gera um GUID e o envia para um serviço Java, que tenta comparar o valor com um UUID do PostgreSQL. A comparação de strings falha e os sistemas relatam que os identificadores não correspondem, embora todos os três serviços funcionem com o mesmo 16 bytes subjacente. As diferenças são aparentemente cosméticas – colchetes, invólucro, ordem de bytes – mas fazem com que as comparações de strings falhem e confundam pontos de integração que não normalizam no limite. GUID é a terminologia da Microsoft para o que RFC 9562 chama de UUID: um identificador de 128 bits com o mesmo layout de bits. Os dois nomes referem-se à mesma estrutura fundamental, mas a representação difere de uma forma que pega os desenvolvedores de surpresa. Compreender a origem da confusão evita erros de integração.
GUID é um UUID - o formato 128 bits compartilhado e de onde veio a diferença de nomenclatura
GUID significa Identificador Globalmente Único e Identificador Globalmente Único e é o nome que a Microsoft usa para o que os padrões RFC chamam de UUID. O layout de 128 bits e a versão do sistema/variant são idênticos. RFC 4122 e RFC 9562 especificam o formato e o significado de UUID; A Microsoft os implementa e usa o termo GUID. A diferença de nomenclatura é histórica: a Microsoft usava GUID antes dos UUIDs serem padronizados pelo IETF, e a terminologia da Microsoft permaneceu no ecossistema .NET. No nível de bits, um GUID e um UUID são completamente intercambiáveis. No nível de formatação, eles diferem na apresentação: o código .NET geralmente escreve GUIDs com colchetes e letras maiúsculas, enquanto os UUIDs canônicos RFC usam letras minúsculas e sem colchetes.
Chaves e letras maiúsculas — o formulário {XXXXXXXX-...} no estilo de registro e como normalizá-lo
Um UUID na forma canônica RFC é escrito como oito, quatro, quatro, quatro e doze caracteres hexadecimais minúsculos separados por hífens: 550e8400-e29b-41d4-a716-446655440000. Um .NET GUID é convencionalmente exibido com colchetes e letras maiúsculas: {550E8400-E29B-41D4-A716-446655440000}. As chaves vêm do formato do Registro do Windows; maiúsculas é uma convenção de exibição. Ambos os formulários representam 128 bits idêntico. Para combinar um GUID de .NET com um UUID do PostgreSQL, retire as chaves e normalize a caixa, depois compare as strings. ToolAcre a verificação bem formada aceita a forma canônica e remove automaticamente os colchetes. A normalização é uma pequena transformação de texto que preserva todo o significado.
Ordem de bytes mista-endian — como os três primeiros campos são armazenados em little-endian na estrutura GUID e por que Guid.ToByteArray difere da ordem de bytes RFC
A diferença perigosa entre GUID e UUID é a ordem dos bytes. RFC 9562 especifica que os três primeiros campos (grupos hexadecimais 8, 4 e 4) são armazenados na ordem de bytes big-endian (rede). .NET A estrutura Guid armazena os três primeiros campos em little-endian: os bytes são invertidos antes de gravar no armazenamento. O mesmo 16 bytes, quando escrito por .NET Guid.ToByteArray() e interpretado por código compatível com RFC, produz representações de texto completamente diferentes. Um UUID 550e8400-e29b-41d4-a716-446655440000 na ordem de bytes RFC é armazenado como bytes 55 0e 84 00 e2 9b 41 d4 a7 16 44 66 55 44 00 00.
A variante herdada da Microsoft – o que significa um c ou d no primeiro caractere do quarto grupo
Além da ordem de bytes, os identificadores herdados da Microsoft às vezes usam um campo de variante não padrão. Onde RFC 9562 especifica que o primeiro caractere do quarto grupo deve ser 8, 9, a ou b, os GUIDs herdados da Microsoft podem usar c, d, e ou f. Esses ainda são UUIDs válidos, mas estão em conformidade com uma variante legada anterior à padronização RFC. Se você encontrar um GUID com c ou d no primeiro caractere do quarto grupo, você terá um valor de 128 bits válido que não está em conformidade com os bits variantes de RFC. O .NET moderno gera GUIDs compatíveis com RFC, portanto, novos identificadores não devem apresentar esse problema. Os bits variantes legados são raros, mas importantes de serem reconhecidos.
Exemplo resolvido - o mesmo 16 bytes renderizado na ordem RFC e na ordem da estrutura GUID, mostrando exatamente quais caracteres são trocados
Pegue o UUID 550e8400-e29b-41d4-a716-446655440000 e converta-o para .NET GUID formato de matriz de bytes usando a convenção little-endian. Na ordem RFC, os bytes são: primeiro campo (550e8400) é igual a 55 0e 84 00, segundo campo (e29b) é igual a e2 9b, terceiro campo (41d4) é igual a 41 d4, quarto e quinto são iguais a a7 16 44 66 55 44 00 00. Em .NET little-endian: o primeiro campo torna-se 00 84 0e 55, o segundo torna-se 9b e2, o terceiro torna-se d4 41 e o restante permanece em big-endian. A matriz de bytes completa é 00 84 0e 55 9b e2 d4 41 a7 16 44 66 55 44 00 00. Se um sistema Java lê esses bytes esperando a ordem RFC, ele os interpreta como 00840e55-9be2-d441-a716-446655440000.
O que isso não cobre — SQL NEWSEQUENTIALID do servidor e pedidos, que são um tópico de armazenamento próprio
O comportamento da função SQL do servidor NEWSEQUENTIALID e suas propriedades específicas de ordenação de identificador são tópicos específicos da camada de armazenamento e do banco de dados. Esta postagem se concentra nas diferenças de formato e ordem de bytes no nível do aplicativo e da serialização. Problemas profundos de manipulação de UUID e ordem de bytes específicos do banco de dados são melhor abordados na documentação específica dessa plataforma de banco de dados. Diferentes sistemas de banco de dados têm diferentes abordagens e abordagens para armazenamento, indexação, classificação e suporte nativo UUID. Alguns bancos de dados detectam automaticamente os bits de versão e variante, enquanto outros exigem declarações de tipo explícitas e manipulação de ordem de bytes na fronteira entre sistemas e armazenamento.
Conclusão: normalize no limite - a verificação ToolAcre aceita a forma canônica, que é a forma para padronizar ao trocar IDs
Normalize no limite quando os identificadores cruzarem um limite do sistema .NET/non-.NET. Remova os colchetes, normalize a caixa de forma consistente e troque os três primeiros campos de bytes se os bytes vierem de .NET Guid.ToByteArray(). A forma canônica RFC é o padrão de referência: oito, quatro, quatro, quatro e doze caracteres hexadecimais minúsculos com hífens, sem colchetes, ordem de bytes big-endian. Ao trocar com sistemas .NET, combine um formato normalizado e aplique as conversões explicitamente no código de integração. Documente cuidadosamente o manuseio da ordem de bytes e teste as conversões. As principais semelhanças fundamentais entre GUID e UUID significam que a maioria dos 128 bits são idênticos.