Uma letra visível, duas sequências
A palavra Café pode conter um único é composto, U+00E9, ou um e seguido de um acento agudo combinado, U+0065 U+0301. Muitas fontes desenham-nas de forma semelhante. Em UTF-8 o é composto usa os bytes C3 A9, enquanto o final decomposto usa 65 CC 81. SHA-256 faz hash dos bytes de entrada, então essas duas ortografias dão digestões diferentes, mesmo que um leitor possa ver a mesma palavra. Isso não é uma falha de hash. É uma incompatibilidade entre comparação visual e comparação de bytes. Preserve o formulário de origem ao investigar um resumo inesperado.
Normalizar sob um acordo explícito
Unicode NFC compõe sequências elegíveis em uma forma canônica; NFD decompõe-los. Se dois sistemas concordarem em normalizar para NFC antes de codificar como UTF-8 e hash, as duas ortografias Café no exemplo alcançam a mesma sequência de bytes canônica. A ferramenta NFC incorporada permite testar a entrada decomposta. A ordem é importante: normalize caracteres, codifique esses caracteres para bytes UTF-8 e, em seguida, faça o hash dos bytes exatos. O hashing primeiro destrói as informações necessárias para reconciliar ortografias equivalentes. Documente o formulário de normalização no contrato de dados para que cada participante realize a mesma operação.
- Café: composto é ou e + acento
- NFC → uma sequência de caracteres escolhida
- UTF-8 bytes → resumo SHA-256
Não normalize tudo cegamente
Normalização pode mudar o texto fonte exato, e as formas de compatibilidade NFKC e NFKD fazem substituições mais amplas do que NFC e NFD. Isso pode ser útil para um índice de pesquisa, mas inapropriado para uma transcrição legal, uma assinatura digital sobre um documento existente ou um sistema que promete arquivamento byte-byte. Uniformizar maiúsculas e minúsculas, remover espaços nas bordas e alterar quebras de linha são escolhas adicionais, não partes automáticas de NFC. Uma especificação de protocolo s pode exigir os bytes originais ou definir um procedimento de canonização diferente. Siga essa regra em vez de aplicar a normalização depois de descobrir uma incompatibilidade.
Verifique os bytes com um teste controlado
Crie duas strings curtas: uma com é composto e uma com e mais a marca de combinação. Execute cada um através do UTF-8 byte viewer e observe C3 A9 versus 65 CC 81 no final. Hasheie as strings brutas separadamente; seus digestões devem ser diferentes. Em seguida, aplique NFC a cada um, inspecione seus bytes novamente e compare os digestões SHA-256. Fique de olho em espaços, quebras de linha e caracteres ocultos na entrada copiada, que também podem alterar um resumo. O teste deve comparar algoritmos e codificações idênticos; um valor SHA-256 não pode ser comparado diretamente com SHA-512.
Escolha a comparação que você realmente precisa
Para uma verificação de integridade de arquivo, o hashing de bytes originais é geralmente o ponto: qualquer alteração de byte deve ser visível. Para deduplicar nomes inseridos por humanos, uma política de normalização de texto documentada pode fazer sentido antes do hashing, embora os nomes também tenham problemas de letras maiúsculas e minúsculas e idioma que um único formulário Unicode não resolve. Para senhas e autenticação, projetos de segurança dedicados governam a normalização e o hashing de senha; um SHA-256 simples de uma senha não é armazenamento suficiente. Indique se o objetivo é identidade de byte, equivalência de texto normalizado ou semelhança humana. Estas são promessas diferentes, e nenhum conversor pode inferir a promessa pretendida apenas pela aparência.