Una letra visible, dos secuencias
La palabra Café puede contener una única é compuesta, U+00E9, o una e seguida de un acento agudo combinado, U+0065 U+0301. Muchas fuentes los dibujan de manera similar. En UTF-8, la é compuesta usa bytes C3 A9, mientras que la terminación descompuesta usa 65 CC 81. SHA-256 codifica los bytes de entrada, por lo que estas dos grafías dan resúmenes diferentes aunque un lector pueda ver la misma palabra. Esto no es un error de hash. Es una falta de coincidencia entre la comparación visual y la comparación de bytes. Conserve el formato fuente al investigar un resumen inesperado.
Normalizar bajo un acuerdo explícito
Unicode NFC compone secuencias elegibles en una forma canónica; NFD los descompone. Si dos sistemas acuerdan normalizarse a NFC antes de codificar como UTF-8 y hash, las dos grafías de Café en el ejemplo alcanzan la misma secuencia de bytes canónica. La herramienta NFC integrada le permite probar la entrada descompuesta. El orden importa: normalice los caracteres, codifique esos caracteres en bytes UTF-8 y luego haga un hash de los bytes exactos. El hashing primero destruye la información necesaria para conciliar ortografías equivalentes. Documentar el formulario de normalización en el contrato de datos para que todos los participantes realicen la misma operación.
- Café: é compuesta o e más acento
- NFC → secuencia de caracteres acordada
- Bytes UTF-8 → resumen SHA-256
No normalices todo a ciegas.
La normalización puede cambiar el texto fuente exacto y las formas de compatibilidad NFKC y NFKD realizan sustituciones más amplias que NFC y NFD. Esto puede resultar útil para un índice de búsqueda, pero inapropiado para una transcripción legal, una firma digital sobre un documento existente o un sistema que promete un archivo byte por byte. El plegado de cajas, el recorte de espacios y el cambio de finales de línea son opciones adicionales, no partes automáticas de NFC. La especificación de un protocolo puede exigir los bytes originales o definir un procedimiento de canonicalización diferente. Siga esa regla en lugar de aplicar la normalización después de descubrir una discrepancia.
Comprueba los bytes con una prueba controlada.
Crea dos cadenas cortas: una con é compuesta y otra con e más la marca de combinación. Ejecute cada uno a través del visor de bytes UTF-8 y observe C3 A9 frente a 65 CC 81 al final. Hash las cadenas sin procesar por separado; sus resúmenes deberían diferir. Luego aplique NFC a cada uno, inspeccione sus bytes nuevamente y compare los resúmenes SHA-256. Esté atento a los espacios, las nuevas líneas y los caracteres ocultos en la entrada copiada, que también pueden cambiar un resumen. La prueba debe comparar algoritmos y codificaciones idénticos; un valor SHA-256 no se puede comparar directamente con SHA-512.
Elige la comparación que realmente necesitas
Para comprobar la integridad del archivo, el objetivo suele ser el hash de los bytes originales: cualquier cambio de byte debe ser visible. Para deduplicar nombres ingresados por humanos, una política de normalización de texto documentada puede tener sentido antes del hash, aunque los nombres también tienen problemas de mayúsculas y minúsculas y de idioma que un solo formulario Unicode no resuelve. Para las contraseñas y la autenticación, los diseños de seguridad dedicados rigen la normalización y el hash de contraseñas; una contraseña SHA-256 simple no es suficiente almacenamiento. Indique si el objetivo es la identidad de bytes, la equivalencia de texto normalizado o la similitud humana. Se trata de promesas diferentes y ningún convertidor puede inferir cuál es la prevista únicamente a partir de la apariencia.