Une lettre visible, deux séquences
Le mot Café peut contenir un seul é composé, U+00E9, ou un e suivi d'un accent aigu combiné, U+0065 U+0301. De nombreuses polices les dessinent de la même manière. En UTF-8, le é composé utilise les octets C3 A9, tandis que la terminaison décomposée utilise 65 CC 81. SHA-256 hache les octets d'entrée, donc ces deux orthographes donnent des résumés différents même si un lecteur peut voir le même mot. Il ne s'agit pas d'un échec de hachage. Il s'agit d'un décalage entre la comparaison visuelle et la comparaison d'octets. Conservez le formulaire source lors de l’enquête sur un résumé inattendu.
Normaliser sous un accord explicite
Unicode NFC compose les séquences éligibles sous une forme canonique ; NFD les décompose. Si deux systèmes conviennent de normaliser en NFC avant d'encoder en UTF-8 et de hacher, les deux orthographes Café de l'exemple atteignent la même séquence d'octets canonique. L'outil NFC intégré vous permet de tester l'entrée décomposée. L'ordre est important : normalisez les caractères, codez ces caractères en octets UTF-8, puis hachez les octets exacts. Le hachage détruit d’abord les informations nécessaires pour réconcilier les orthographes équivalentes. Documentez le forme de normalisation dans le contrat de données afin que chaque participant effectue la même opération.
- Café : é composé ou e suivi d’un accent
- NFC → séquence de caractères convenue
- Octets UTF-8 → empreinte SHA-256
Ne normalisez pas tout aveuglément
La normalisation peut modifier le texte source exact et les formulaires de compatibilité NFKC et NFKD effectuent des substitutions plus larges que NFC et NFD. Cela peut être utile pour un index de recherche mais inapproprié pour une transcription juridique, une signature numérique sur un document existant ou un système qui promet un archivage octet par octet. Le pliage du boîtier, la réduction des espaces et la modification des fins de ligne sont des choix supplémentaires et non des éléments automatiques du NFC. La spécification d'un protocole peut exiger les octets d'origine ou définir une procédure de canonisation différente. Suivez cette règle au lieu d'appliquer la normalisation après avoir découvert une incompatibilité.
Vérifiez les octets avec un test contrôlé
Créez deux chaînes courtes : une avec é composé et une avec e plus la marque de combinaison. Exécutez chacun dans le visualiseur d'octets UTF-8 et notez C3 A9 contre 65 CC 81 à la fin. Hachez les chaînes brutes séparément ; leurs résumés devraient différer. Appliquez ensuite NFC à chacun, inspectez à nouveau leurs octets et comparez les résumés SHA-256. Gardez un œil sur les espaces, les nouvelles lignes et les caractères masqués dans les entrées copiées, qui peuvent également modifier un résumé. Le test doit comparer des algorithmes et des codages identiques ; une valeur SHA-256 ne peut pas être comparée directement avec SHA-512.
Choisissez la comparaison dont vous avez réellement besoin
Pour une vérification de l'intégrité d'un fichier, le hachage des octets d'origine est généralement la solution : tout changement d'octet doit être visible. Pour la déduplication des noms saisis par l'homme, une politique documentée de normalisation du texte peut avoir du sens avant le hachage, bien que les noms présentent également des problèmes de casse et de langue qu'un seul formulaire Unicode ne résout pas. Pour les mots de passe et l'authentification, des conceptions de sécurité dédiées régissent la normalisation et le hachage des mots de passe ; un simple mot de passe SHA-256 ne constitue pas un stockage suffisant. Indiquez si l'objectif est l'identité d'octet, l'équivalence de texte normalisée ou la similarité humaine. Ce sont des promesses différentes, et aucun convertisseur ne peut déduire celle prévue à partir de la seule apparence.