Der "CRC error" und IDAT-Schäden bei einem PNG

Ein PNG beginnt mit einer festen Signatur von 8 Bytes — den Bytes 89 50 4E 47 0D 0A 1A 0A — und alles danach ist eine Kette von Chunks. Jeder Chunk ist gleich aufgebaut: eine Länge von 4 Bytes in Big-Endian (die nur die Daten zählt), ein Typ aus 4 ASCII-Bytes wie IHDR, IDAT oder IEND, die Daten selbst und eine abschließende CRC-32 von 4 Bytes. Diese Prüfsumme wird über Typ und Daten des Chunks berechnet — nicht über seine Länge — mit dem üblichen Polynom nach ISO-3309 / ITU-T V.42 (in gespiegelter Form 0xEDB88320). Ein "CRC error" bedeutet, dass ein Decoder diesen Wert neu berechnet hat und er nicht mit den vier Bytes auf der Festplatte übereinstimmte: der Beweis, dass sich die Bytes des Chunks seit dem Schreiben der Datei verändert haben.

Jedes Werkzeug formuliert es auf seine Weise. pngcheck gibt CRC error in chunk IDAT (computed 12ab34cd, expected 89ef01ab) aus; libpng meldet libpng error: IDAT: CRC error oder das knappere Read Error; ImageMagick lässt die darunterliegende zlib-Schicht als IDAT: invalid distance too far back durchscheinen; ein Browser zeichnet schlicht nichts. Der im Meldungstext genannte Chunk sagt dir, was auf dem Spiel steht. Ein CRC error bei einem Neben-Chunk (ancillary) — tEXt, gAMA, pHYs, sRGB, deren Typ mit einem Kleinbuchstaben beginnt — ist kosmetisch, und das Bild lässt sich weiterhin decodieren. Ein CRC error bei einem kritischen Chunk (den vieren, deren Typ mit einem Großbuchstaben beginnt: IHDR, PLTE, IDAT, IEND) ist das, was die Datei wirklich am Öffnen hindert.

Die drei Chunks, die das Bild tragen, sind IHDR, IDAT und IEND. IHDR ist genau 13 Bytes lang: Breite und Höhe (je 4 Bytes), dann die Bittiefe, der Farbtyp (0 Graustufen, 2 Truecolor, 3 indiziert, 4 Grau+Alpha, 6 RGBA), die Kompressionsmethode, die Filtermethode und die Interlace-Methode. IDAT enthält die komprimierten Pixel und ist häufig auf mehrere aufeinanderfolgende Chunks verteilt, die vor dem Dekomprimieren aneinandergehängt werden müssen. IEND ist ein leerer Marker der Länge null, der besagt, dass die Datei vollständig ist. Das Werkzeug liest diese Struktur lokal, prüft jede CRC und benennt den schuldigen Chunk, bevor es ein einziges Byte verändert.

Weil jeder Chunk seine eigene Prüfsumme trägt, hat eine ganze Klasse von PNG-Schäden einen deterministischen Fix — die richtige Antwort ergibt sich aus der Mathematik, sie wird nicht geraten.

Eine falsche CRC über intakten Daten. Der harmloseste Fehler: Die Daten des Chunks sind Byte für Byte korrekt, aber seine gespeicherte CRC-32 ist veraltet — ein häufiges Ergebnis eines Editors, der die Daten neu geschrieben hat, ohne die Prüfsumme zu aktualisieren, oder eines einzelnen gekippten Bits innerhalb des 4-Byte-CRC-Felds selbst. Die CRC aus Typ und Daten neu zu berechnen und zurückzuschreiben macht die Datei wieder gültig, ganz ohne Verlust. Die Prüfsumme war das Einzige, was falsch war.

Auf null gesetzte oder verwürfelte Abmessungen. Wenn die Breite oder Höhe in IHDR beschädigt ist, kann kein Decoder eine Zeichenfläche reservieren, und die Datei öffnet nicht — oft als libpng error: Invalid IHDR data. Aber IHDR speichert seine eigene CRC, berechnet zu einer Zeit, als die Abmessungen noch korrekt waren. Das macht die Wiederherstellung zu einer Suche: Man probiert Kandidatenpaare aus Breite/Höhe durch, berechnet für jedes die CRC-32 des 13-Byte-Chunks neu und hält an, sobald sie mit dem gespeicherten Wert übereinstimmt. Die ursprünglichen Abmessungen fallen unmittelbar aus der Rechnung heraus, exakt, ohne jedes Raten.

Verstümmelung von Zeilenumbrüchen und des höchsten Bits. Die 8-Byte-Signatur wurde als Stolperdraht für Korruption im Textmodus entworfen: Das Paar 0D 0A fängt eine CRLF→LF-Umwandlung ab, das abschließende 0A fängt LF→CRLF ab, und das führende 89 (mit gesetztem höchstem Bit) fängt eine 7-Bit-Übertragung ab, die es entfernt hat. Wenn ein PNG durch einen FTP-Client im ASCII-Modus oder ein Skript geschleust wurde, das es als Text neu geschrieben hat, ist die Ersetzung konsistent und umkehrbar — man macht die Transformation rückgängig, und die ursprünglichen Bytes kehren in der gesamten Datei zurück, nicht nur in der Signatur.

Innerhalb der IDAT-Chunks bilden die Pixel einen einzigen zlib-Datenstrom: einen 2-Byte-Header (üblicherweise 78 9C), einen mit deflate komprimierten Rumpf und eine 4-Byte-Adler-32-Prüfsumme ganz am Ende. Vor der Kompression wird jeder Bildzeile (scanline) ein 1 Byte langer Filtertyp vorangestellt (0 None, 1 Sub, 2 Up, 3 Average, 4 Paeth), der jeden Pixel aus seinen Nachbarn vorhersagt. Die Zeilen werden von oben nach unten geschrieben, und allein diese Tatsache entscheidet, was sich wiederherstellen lässt, sobald die Daten selbst — nicht nur eine Prüfsumme — beschädigt sind.

Abschneidung. Der häufigste Bruch: ein Download, der zu früh abbrach, eine Kopie, die beim Abziehen eines Laufwerks unterbrochen wurde, ein Absturz mitten im Schreiben. Der vordere Teil der Datei ist intakt, und das Ende — meist samt IEND und der Adler-32 — fehlt schlicht, sodass Decoder EOF while reading IDAT oder das incorrect data check von zlib melden. Weil deflate von oben nach unten decodiert, rettet das Werkzeug jede vollständige Bildzeile bis zum Schnitt, schreibt ein frisches, gültiges IEND und übergibt dir ein ehrliches Teilergebnis: deine echten Pixel, so weit nach unten, wie die Bytes reichen.

Korruption mitten im Stream. Wenn der Schaden im Deflate-Rumpf statt am Ende landet, ist die Grenze hart. Deflate ist ein einziger fortlaufender Stream ohne periodische Resync-Marker, sodass inflate den Faden verliert, sobald es auf ein fehlerhaftes Byte trifft — du siehst invalid distance too far back, invalid literal/length code oder invalid block type —, und alles nach dieser Stelle decodiert als Rauschen. Ein einziges beschädigtes Byte auf halber Höhe kann jede darunterliegende Zeile kosten, nicht nur eine einzelne. Das Werkzeug behält die Zeilen, die oberhalb der Wunde sauber decodiert wurden; es kann den Stream darunter nicht wieder zusammennähen, und eine im Zeilensprung (Adam7) gespeicherte Datei verliert zusätzlich die späteren Durchläufe, die den unteren Bildteil geschärft hätten.

Zwei ehrliche Aussichtslosigkeiten. Eine Datei mit 0 Bytes oder lauter Nullen hat kein Bild, das sich wiederherstellen ließe — das ist ein Problem der Datenrettung für den Speicher, keine Reparatur. Und wenn die Daten eines Chunks (nicht bloß seine CRC) überschrieben wurden, kann die Prüfsumme den Schaden belegen, ihn aber nie rückgängig machen. Alles Obige läuft vollständig in deinem Browser-Tab — der Parser ist abhängigkeitsfreies TypeScript —, sodass ein PNG, das vielleicht ein privates Foto, ein Screenshot oder ein gescanntes Dokument ist, nie auf einen Server kopiert wird: Öffne den Netzwerk-Tab (Network) und bestätige, dass 0 Bytes das Gerät verlassen.