Le "CRC error" et les dommages IDAT d'un PNG

Un PNG commence par une signature fixe de 8 octets — les octets 89 50 4E 47 0D 0A 1A 0A — et tout ce qui suit est une chaîne de chunks. Chaque chunk suit exactement la même disposition : une longueur de 4 octets big-endian (qui ne compte que les données), un type ASCII de 4 octets comme IHDR, IDAT ou IEND, les données elles-mêmes, et un CRC-32 final de 4 octets. Ce checksum est calculé sur le type et les données du chunk — et non sur sa longueur — à l'aide du polynôme standard ISO-3309 / ITU-T V.42 (dans sa forme réfléchie, 0xEDB88320). Une "CRC error" signifie qu'un décodeur a recalculé cette valeur et qu'elle ne correspondait pas aux quatre octets présents sur le disque : la preuve que les octets du chunk ont changé depuis l'écriture du fichier.

Chaque outil l'exprime à sa manière. pngcheck affiche CRC error in chunk IDAT (computed 12ab34cd, expected 89ef01ab) ; libpng lève libpng error: IDAT: CRC error ou le plus laconique Read Error ; ImageMagick laisse transparaître la couche zlib sous-jacente sous la forme IDAT: invalid distance too far back ; et un navigateur, lui, ne dessine tout simplement rien. Le chunk nommé dans le message vous indique l'enjeu. Une CRC error sur un chunk auxiliaire (ancillary) — tEXt, gAMA, pHYs, sRGB, dont le type commence par une minuscule — est cosmétique et l'image se décode quand même. Une CRC error sur un chunk critique (les quatre dont le type commence par une majuscule : IHDR, PLTE, IDAT, IEND) est ce qui empêche vraiment le fichier de s'ouvrir.

Les trois chunks qui portent l'image sont IHDR, IDAT et IEND. IHDR fait exactement 13 octets : largeur et hauteur (4 octets chacune), puis la profondeur de bits, le type de couleur (0 niveaux de gris, 2 couleurs réelles, 3 indexé, 4 gris+alpha, 6 RGBA), la méthode de compression, la méthode de filtrage et la méthode d'entrelacement. IDAT contient les pixels compressés et se répartit fréquemment sur plusieurs chunks consécutifs qu'il faut concaténer avant de décompresser. IEND est un marqueur vide, de longueur nulle, qui indique que le fichier est complet. L'outil lit cette structure localement, vérifie chaque CRC et identifie le chunk fautif avant de modifier le moindre octet.

Comme chaque chunk porte son propre checksum, toute une catégorie de dommages d'un PNG bénéficie d'une réparation déterministe — la bonne réponse se connaît par le calcul, elle ne se devine pas.

Un CRC erroné portant sur des données intactes. La défaillance la plus bénigne : les données du chunk sont correctes octet par octet, mais son CRC-32 enregistré est périmé — résultat courant d'un éditeur qui a réécrit les données sans mettre à jour le checksum, ou d'un seul bit inversé à l'intérieur même du champ CRC de 4 octets. Recalculer le CRC à partir du type et des données puis le réécrire rend le fichier de nouveau valide, sans la moindre perte. Le checksum était la seule chose erronée.

Dimensions mises à zéro ou brouillées. Si la largeur ou la hauteur d'IHDR est corrompue, aucun décodeur ne peut réserver un canevas et le fichier ne s'ouvre pas — souvent sous la forme libpng error: Invalid IHDR data. Mais IHDR conserve son propre CRC, calculé à l'époque où les dimensions étaient encore correctes. Cela transforme la récupération en une recherche : on essaie des paires largeur/hauteur candidates, on recalcule le CRC-32 du chunk de 13 octets pour chacune, et on s'arrête lorsqu'il correspond à la valeur enregistrée. Les dimensions d'origine ressortent directement de l'arithmétique, exactes, sans rien deviner.

Dégâts de fins de ligne et du bit de poids fort. La signature de 8 octets a été conçue comme un piège pour la corruption en mode texte : la paire 0D 0A détecte une conversion CRLF→LF, le 0A final détecte LF→CRLF, et le 89 initial (dont le bit de poids fort est activé) détecte un transfert sur 7 bits qui l'a supprimé. Quand un PNG est passé par un client FTP en mode ASCII, ou par un script qui l'a réécrit comme du texte, la substitution est cohérente et réversible — on annule la transformation et les octets d'origine reviennent dans tout le fichier, pas seulement dans la signature.

À l'intérieur des chunks IDAT, les pixels forment un unique flux de données zlib : un en-tête de 2 octets (habituellement 78 9C), un corps compressé avec deflate et un checksum Adler-32 de 4 octets tout à la fin. Avant la compression, chaque ligne de balayage (scanline) est précédée d'un octet de type de filtre (0 None, 1 Sub, 2 Up, 3 Average, 4 Paeth) qui prédit chaque pixel à partir de ses voisins. Les lignes sont écrites de haut en bas, et ce seul fait détermine ce qui est récupérable une fois que ce sont les données elles-mêmes — et non plus un simple checksum — qui sont endommagées.

Troncature. La rupture la plus courante : un téléchargement qui s'est arrêté trop tôt, une copie interrompue au retrait d'un disque, un plantage en pleine écriture. L'avant du fichier est intact et la fin — d'ordinaire y compris IEND et l'Adler-32 — manque tout simplement, si bien que les décodeurs signalent EOF while reading IDAT ou le incorrect data check de zlib. Comme deflate décode de haut en bas, l'outil récupère chaque ligne de balayage complète jusqu'à la coupure, écrit un IEND neuf et valide, et vous remet un résultat partiel honnête : vos vrais pixels, aussi loin que les octets s'étendent.

Corruption au milieu du flux. Quand les dommages tombent à l'intérieur du corps deflate plutôt qu'à la fin, la limite est nette. Deflate est un flux continu sans marqueurs périodiques de resynchronisation, si bien que dès qu'inflate tombe sur un octet défectueux il perd le fil — vous voyez invalid distance too far back, invalid literal/length code ou invalid block type — et tout ce qui suit se décode comme du bruit. Un seul octet corrompu à mi-hauteur peut coûter toutes les lignes situées en dessous, pas seulement une ligne. L'outil conserve les lignes qui se sont décodées proprement au-dessus de la blessure ; il ne peut pas recoudre le flux en dessous, et un fichier entrelacé (Adam7) perd en outre les passes ultérieures qui auraient affiné le bas de l'image.

Deux cas perdus d'avance, en toute honnêteté. Un fichier de 0 octet ou entièrement à zéro n'a aucune image à reconstruire — c'est un problème de récupération de données du support de stockage, pas une réparation. Et quand les données d'un chunk (et pas seulement son CRC) ont été écrasées, le checksum peut prouver les dommages mais jamais les inverser. Tout ce qui précède s'exécute entièrement dans l'onglet de votre navigateur — l'analyseur est du TypeScript sans dépendances — de sorte qu'un PNG qui est peut-être une photo privée, une capture d'écran ou un document numérisé n'est jamais copié vers un serveur : ouvrez l'onglet Réseau (Network) et vérifiez que 0 octet quitte votre machine.