Outils de développement · Calculateur de hachage SHA
Même texte, différent SHA-256 : sauts de ligne, encodages et octets masqués
· Comment ça marche
sha-256 codage traitement de texte débogage
La ligne de commande dit une chose et le navigateur en dit une autre pour ce qui ressemble au même texte. Les nouvelles lignes de fin, UTF-16 et CRLF expliquent presque tous les cas ; cet article montre comment trouver les octets cachés.
echo dit un hachage, l'outil en dit un autre - l'inadéquation quotidienne et pourquoi aucun des deux n'est faux
Un terminal signale un résumé SHA-256 et un navigateur en signale un autre pour ce qui semble être un texte identique. L’outil de ligne de commande n’est pas cassé, et le navigateur non plus. Les octets hachés ne sont pas les mêmes, même si les caractères visibles semblent identiques. Cet article retrace les sources les plus courantes de ces octets cachés et montre comment les trouver avec un champ de texte et une visionneuse hexadécimale.
Le problème ne vient presque jamais de l'algorithme SHA-256 lui-même. SHA-256 est déterministe : les mêmes octets produisent toujours le même résumé, et le résumé est correct. Lorsque les sorties diffèrent, les octets diffèrent. La confusion vient du fait que « le même texte » est ambigu : une personne voit des caractères, mais une fonction de hachage voit des octets, et la traduction entre eux est l'endroit où se cachent les différences cachées.
La nouvelle ligne de fin - comment echo ajoute un octet et pas printf, et ce que cela fait à un résumé
La commande echo dans un shell ajoute un caractère de nouvelle ligne (U+000A, octet 0x0A) à sa sortie. C'est intentionnel : la convention sous Unix selon laquelle les fichiers texte se terminent par une nouvelle ligne donne à echo une tâche simple. Lorsque vous tapez echo abc dans un terminal et que vous le dirigez vers sha256sum, les octets digérés sont 61 62 63 0A (les codes ASCII pour a, b, c et l'octet pour la nouvelle ligne), et non 61 62 63. L'outil que ToolAcre utilise pour calculer les hachages hache les octets 61 62 63 et produit un résultat différent.
La commande printf n'ajoute pas de nouvelle ligne sauf si vous en écrivez une dans la chaîne de format. imprimer abc | sha256sum calcule le résumé des octets 61 62 63 seul, ce qui correspond à l'outil de navigation. C'est pourquoi comparer les hachages signifie souvent exécuter printf au lieu de echo, ou rediriger vers sha256sum avec l'indicateur -z, ou spécifier une entrée brute sous la forme fournie par votre outil. La nouvelle ligne masquée est la raison la plus courante pour laquelle un outil de navigation et un outil de ligne de commande ne sont pas d'accord.
UTF-8 versus UTF-16 — pourquoi les mêmes caractères sont des octets différents dans certains shells et éditeurs
UTF-8 et UTF-16 codent les mêmes caractères sous différentes séquences d'octets. Le caractère é (U+00E9, un e avec un accent aigu) code sous forme de deux UTF-8 octets : 0xC3 0xA9. Dans UTF-16, qui correspond à la façon dont JavaScript représente en interne les chaînes, le même caractère occupe deux octets dans un ordre différent (en fonction du boutisme) ou une forme entièrement différente s'il est composé d'un caractère de base et d'une marque de combinaison. Lorsque vous copiez café à partir d'une application Windows et que vous le collez dans un outil de hachage de navigateur, les octets hachés par l'outil peuvent ne pas correspondre à ceux hachés par un terminal Mac, car les systèmes ont utilisé par défaut des encodages ou des formes de normalisation différents.
L'outil de hachage ToolAcre convertit explicitement le texte en UTF-8 avant le hachage via TextEncoder. Il s'agit du même codage que la ligne de commande Unix utilise par défaut. Le code source dans apps/dev/src/lib/base64.js montre la fonction textToBytes appelant new TextEncoder().encode(), qui garantit UTF-8. Si un autre système utilise UTF-16 ou Latin-1 ou tout autre codage, les octets produits seront différents. L'outil affiche le nombre d'octets à côté du résumé, c'est pourquoi le collage de café et la comparaison avec un hachage de ligne de commande afficheront différents nombres d'octets si les encodages divergent.
CRLF, BOM et normalisation — fins de ligne, marques d'ordre d'octet et accents composés ou décomposés en tant que différences d'entrée invisibles
CRLF (retour chariot + saut de ligne, octets 0x0D 0x0A) est la convention de fin de ligne sous Windows ; LF (saut de ligne seul, octet 0x0A) est la convention Unix. Un fichier texte qui semble identique lorsqu'il est ouvert dans un éditeur de texte peut comporter des fins de ligne différentes, et ces octets font partie de l'entrée du hachage. Un fichier édité sous Windows et vérifié par rapport à un SHA-256 calculé sur un système Unix ne correspondra pas si un système a converti les fins de ligne et l'autre non.
La marque d'ordre des octets (BOM, octets 0xEF 0xBB 0xBF pour UTF-8) est une séquence facultative au début d'un fichier qui signale l'encodage. Certains éditeurs l'ajoutent ; certains outils le suppriment ; certains l'ignorent. Si un fichier contient une nomenclature et que vous le hachez octet par octet, les octets de la nomenclature font partie du résumé. Si vous copiez ensuite le texte visible (dont un visualiseur masque la nomenclature) dans un outil qui n'ajoute pas de nomenclature, les résumés ne correspondront pas. Les formes de normalisation de texte (NFD versus NFC pour les accents composés et décomposés) ajoutent une autre couche : la même lettre accentuée peut être représentée comme un seul caractère précomposé ou comme un caractère de base suivi d'un accent combiné, et les séquences d'octets sont différentes.
Exemple concret : une chaîne hachée avec et sans nouvelle ligne, puis en deux encodages, avec chaque différence d'octet affichée
Première méthode de diagnostic : utilisez un outil de vidage hexadécimal ou un convertisseur en ligne pour voir exactement sur quels octets vos outils fonctionnent. Collez le texte dans un encodeur base64, encodez-le et vous obtenez un enregistrement textuel des octets. Décodez ensuite le base64 sur la ligne de commande avec base64 -d et dirigez-le vers od -A x -t x1z pour voir la séquence d'octets hexadécimaux. Si les octets correspondent, l'algorithme est correct ; sinon, la différence sera visible.
Deuxième méthode de diagnostic : utilisez le calculateur de hachage ToolAcre SHA pour hacher progressivement des entrées plus longues, en commençant par un seul caractère. Ajoutez une nouvelle ligne (ce qui signifie taper Entrée dans la zone de texte), ajoutez des espaces, ajoutez le même texte avec des séquences d'échappement UTF-16 si l'entrée provient d'une source non-ASCII. Regardez le résumé changer à chaque ajout. Le nombre d'octets affiché à côté du résumé vous indique le nombre d'octets hachés par l'outil, ce qui réduit considérablement la recherche.
Casse hexadécimale et espaces dans la sortie - les différences purement esthétiques
La représentation hexadécimale d'un résumé n'est pas sensible à la casse. Les lettres majuscules et minuscules représentent toutes deux les mêmes octets : A = 10, a = 10. Certains outils émettent des majuscules, d'autres des minuscules, d'autres encore le permettent. Si un résumé est en minuscules et un autre en majuscules, il s’agit du même résumé. Les espaces dans l’affichage du résumé sont purement cosmétiques. Un résumé affiché sous la forme ba78 16bf par rapport à ba7816bf est le même ; l'espace n'est qu'un choix de formatage. Les disparités causées par la casse ou les espaces ne sont pas de véritables discordances.
Les différences de formatage à largeur fixe sont également invisibles au niveau des octets. Un résumé affiché avec des traits d'union, des espaces ou des deux-points (comme ba-78-16-bf) est une convention de formatage qui facilite la lecture par les humains, et non une modification des octets réels. L'outil ToolAcre émet toujours des minuscules sans séparateurs, qui est le format imprimé par la plupart des outils de ligne de commande. Si vous comparez avec un outil qui émet différemment, convertissez d'abord vers la même représentation.
Ce que cela ne couvre pas : le hachage de fichiers, où les mêmes principes s'appliquent mais les octets proviennent du disque plutôt que d'un champ de texte
Le calculateur de hachage ToolAcre SHA effectue la conversion UTF-8 avant le hachage, affiche le nombre d'octets d'entrée et propose des formulaires de sortie base64 et hexadécimaux. Le fichier source apps/dev/src/lib/hash.js montre la fonction hashText appelant digestBytes, qui transmet bytes.slice().buffer à crypto.subtle.digest. Les commentaires dans ce fichier documentent explicitement que l'étape UTF-8 est intentionnelle et notent la différence entre les différents encodages. Le test de votre entrée par rapport au vecteur connu (hachages abc en ba7816bf8f01cfea414140de5dae2223b00361a396177a9cb410ff61f20015ad en hexadécimal) permet d'établir que l'outil de navigation fonctionne correctement ; tout écart indique une différence d’octets dans l’entrée.
Le hachage de fichiers suit le même principe. Ce sont les octets du fichier qui comptent : une différence de fin de ligne lorsque vous exportez d'un système et importez vers un autre peut modifier chaque résumé. Certains outils offrent des options pour gérer les fins de ligne lors de la comparaison ; d'autres hachent le fichier tel quel. Savoir si votre outil hache le fichier en binaire ou effectue d'abord la normalisation du texte est essentiel pour la reproductibilité.
À retenir : des octets de hachage, pas du texte – le calculateur de hachage ToolAcre SHA hache les octets que vous collez, alors vérifiez ce que vous avez collé en premier
La comparaison et la vérification ne fonctionnent que lorsque vous hachez les mêmes octets. Commencez par confirmer que vous hachez exactement la même entrée : exécutez echo -n (ou printf) au lieu de echo pour éviter la nouvelle ligne, spécifiez explicitement l'encodage UTF-8 si votre outil le permet, vérifiez que CRLF n'a pas été inséré par un éditeur ou un utilitaire système. Hachez ensuite avec la calculatrice ToolAcre et l'outil de ligne de commande côte à côte. Si les résumés correspondent, les octets étaient identiques. Si ce n'est pas le cas, utilisez l'affichage du nombre d'octets et la méthode de vidage hexadécimal pour trouver la différence cachée.
Une fois que vous avez compris où les octets ont divergé, vous pouvez choisir de les normaliser à des fins de comparaison. Certaines sommes de contrôle sont destinées à vérifier l'intégrité du fichier exactement tel qu'il existe sur le disque, auquel cas le hachage octet par octet est l'objectif. D'autres visent à vérifier que le contenu visible est le même, auquel cas la normalisation des fins de ligne et du codage est correcte. Ni l’un ni l’autre n’a tort ; ils répondent à des questions différentes. L'algorithme SHA-256 a toujours raison ; la question est seulement de savoir si vous lui demandez de hacher la même entrée dans les deux cas.