Pourquoi deux empreintes SHA-256 sont différentes et comment vérifier un fichier

Deux calculs SHA-256 effectués sur les mêmes octets donnent toujours la même empreinte. Si les valeurs diffèrent réellement, vérifiez d’abord le fichier choisi, l’algorithme et les caractères invisibles. Un téléchargement incomplet, un espace ou un saut de ligne suffit généralement à changer le résultat. Avant d’utiliser un fichier téléchargé, comparez son empreinte complète à celle publiée par une source fiable.

Choisir entre fichier et texte

Pour contrôler un PDF, une archive ou un programme téléchargé, utilisez le calculateur d’empreinte de fichier. Il calcule SHA-256 sur les octets du fichier sélectionné. Ne copiez pas son contenu dans une zone de texte : cette opération peut changer l’encodage ou les fins de ligne.

Pour comparer une chaîne de caractères, choisissez le générateur de hachage SHA-256. Il encode le texte saisi en UTF-8, puis calcule son empreinte, espaces et retours à la ligne compris. Un fichier texte et le texte affiché à l’écran ne représentent donc pas forcément les mêmes octets.

Vérifier un téléchargement pas à pas

Retrouvez l’empreinte sur le site officiel de l’éditeur, pour la bonne version et le bon fichier. Une archive ZIP et le document qu’elle contient ont des empreintes différentes.
Vérifiez que la référence utilise SHA-256. Une valeur hexadécimale SHA-256 comporte 64 caractères. La norme définit une sortie de 256 bits. Référence NIST.
Dans le calculateur de fichier, cliquez sur « Choisir un fichier ». Contrôlez le nom et la taille affichés, puis cliquez sur « Calculer SHA-256 ».
Utilisez « Copier l’empreinte » et comparez les 64 caractères à la référence. Le bouton copie seulement l’empreinte ; la comparaison reste à faire. Les lettres hexadécimales A–F et a–f représentent les mêmes valeurs.
En cas de différence, n’exécutez pas le fichier. Vérifiez la version attendue, puis téléchargez-le à nouveau depuis la source officielle. Si l’écart persiste, demandez une confirmation à l’éditeur.

Un exemple avec un seul saut de ligne

Dans le générateur de texte, saisissez exactement abc, sans guillemets, espace ni retour à la ligne. Cliquez sur « Calculer l’empreinte ». Les trois octets UTF-8 sont 61 62 63 en hexadécimal. Le résultat est :

ba7816bf8f01cfea414140de5dae2223b00361a396177a9cb410ff61f20015ad

Placez ensuite le curseur après le c, appuyez une fois sur Entrée et relancez le calcul. Avec ce saut de ligne LF, l’entrée compte quatre octets : 61 62 63 0a. Le résultat devient :

edeaaff3f1774ad2888673770c6d64097e391bc362d7d6fb34982ddf0efd18cb

Pour reproduire ces résultats avec des fichiers, enregistrez le premier en UTF-8 sans BOM ni saut final, puis le second avec un seul LF final. Le calculateur doit afficher respectivement 3 et 4 octets. Certains éditeurs ajoutent automatiquement un saut de ligne : contrôlez ce réglage.

Les différences qui ne se voient pas

Un espace après un mot, une tabulation ou une ligne vide font partie du contenu. Les fins de ligne LF et CRLF utilisent des octets différents. Un fichier UTF-8 avec BOM possède aussi des octets initiaux supplémentaires par rapport au même texte enregistré sans BOM.

Les accents peuvent également surprendre : un é et un e suivi d’un accent combiné peuvent se ressembler à l’écran tout en ayant des représentations différentes. Le générateur ne les normalise pas automatiquement. L’inspecteur d’encodage UTF-8 aide à examiner le BOM et les fins de ligne des fichiers texte de 5 Mio maximum. L’encodage proposé doit être confirmé ; sans BOM, il n’est pas toujours identifiable. Ne convertissez pas le fichier avant de vérifier son empreinte d’origine.

Ce que la vérification permet de conclure

Une concordance SHA-256 constitue un contrôle d’intégrité solide, sans être une garantie mathématique d’unicité : les fonctions de hachage sont conçues pour rendre les collisions difficiles à trouver. RFC 6234.

Elle ne prouve pas que le fichier est inoffensif ou que son auteur est bien celui annoncé. Si un attaquant fournit à la fois un fichier modifié et son empreinte, les deux correspondent. La provenance de la référence reste essentielle. Une signature numérique vérifiée avec une clé de confiance apporte une vérification d’authenticité distincte.

Checklist avant de conclure

Même fichier, même version et même algorithme
Référence obtenue auprès d’une source fiable
Empreinte complète comparée, sans confondre majuscules et minuscules
Aucune modification, conversion ou réexportation entre les calculs

Questions fréquentes

Renommer un fichier change-t-il son empreinte ?

Non : son nom n’entre pas dans le calcul. En revanche, modifier des métadonnées enregistrées à l’intérieur du fichier change ses octets et généralement son empreinte.

Puis-je retrouver le fichier à partir de son SHA-256 ?

SHA-256 n’est pas un chiffrement et ne possède pas de clé de déchiffrement. Une empreinte sert à comparer des données, pas à les restaurer ni à cacher un secret prévisible.

Pourquoi un gros fichier ne passe-t-il pas ?

Le calcul reste dans le navigateur, mais le fichier est chargé entièrement en mémoire. L’API utilisée ne traite pas l’entrée en flux ; la limite pratique dépend donc de l’appareil et du navigateur. La page et ses ressources sont néanmoins chargées depuis le site. Documentation MDN.