破損した PNG スクリーンショットを修復する

すべての PNG は同じ 8 バイトのシグネチャ—89 50 4E 47 0D 0A 1A 0A—で始まります。これは意図的にいくつもの仕掛けを詰め込んだ指紋です。上位ビットの立ったバイト 0x89 は 7 ビットしか通さないチャンネルを検出し、0D 0A と単独の 0A は改行コードの変換を検出し、1A（DOS のファイル終端）は不用意な type コマンドが以降を吐き出すのを止めます。その後に一連のチャンクが続き、それぞれが整然としたパッケージになっています。4 バイトのビッグエンディアンの長さ、4 バイトの ASCII タイプ、データ、そして標準の反転多項式 0xEDB88320 を用いてタイプとデータ（長さは決して含めません）に対して計算された 4 バイトの CRC-32 です。

3 つのチャンクが画像を担います。IHDR が最初に来て、常に 13 バイトです。幅（u32）、高さ（u32）、続いてビット深度、カラータイプ、圧縮方式、フィルター方式、インターレース方式を表す各 1 バイトです。現代の OS のスクリーンショットはほぼ必ず 8 ビット、非インターレース、カラータイプ 2（トゥルーカラー）または 6（アルファ付きトゥルーカラー）です。IDAT は画像を保持し、ときに連続する複数の IDAT チャンクに分割されます。その内部には、DEFLATE で圧縮されたフィルター済みスキャンラインの zlib ストリーム（ヘッダーバイト 0x78）が収まっています。各行の先頭には 0〜4 のフィルターバイト（None, Sub, Up, Average, Paeth）が付き、上から下へと書き込まれます。IEND は空の終端マーカーで、固定の CRC AE 42 60 82 を持ちます。

スクリーンショットには、見覚えのある補助チャンクも含まれます—最初の文字が小文字であることが、それらが任意であることを示します—たとえば pHYs（ピクセル密度。Retina のキャプチャがその倍率を報告できるようにします）、iCCP や sRGB（カラープロファイル）、tEXt/eXIf（キャプチャツールが刻むメタデータ）などです。これらは 1 ピクセルも失うことなく破損したり欠落したりできます。デコーダーは、理解できない補助チャンクをどれでも読み飛ばしてよいことになっているからです。

各チャンクが自己検証するため、PNG の破損のうち丸ごと 1 群は、当て推量ではなく分かりきった答えを持ちます。

• チェックサムが誤り、データは正しい。 最も多い誤警報です。チャンクのバイトは無傷なのに、保存されている CRC がもはや一致しないため、厳格なデコーダー（や pngcheck）は CRC error in chunk IDAT でファイルを拒否します。データから CRC-32 を再計算して書き戻せば、ゼロの損失でファイルは再び有効になります—誤っていたのはチェックサムだけだったのです。
• 寸法のゼロ化や破損。 IHDR の幅や高さがゼロになっていると、どのデコーダーもキャンバスを確保できず、ファイルは開きません。しかし IHDR は、数値が正しかった当時に計算された独自の CRC を持っています。これにより、修復はジオメトリを総当たりで求められます。候補となる幅／高さの値を試し、それぞれについてチャンクの CRC を再計算し、保存されている値と一致したところで止めます。元の寸法は計算からそのまま導き出されます—当て推量はありません。
• 改行 / テキストモードによる文字化け。 ASCII モードの FTP クライアント、チャットのブリッジ、あるいはファイルをテキストとして書き直したスクリプトを通ったスクリーンショットは、すべての 0D 0A を単独の 0A に（またはその逆に）置き換え、ファイル全体のバイトを破損させます。シグネチャはまさにこれを検出するよう設計されており、置換が一貫している場合は 1 バイト単位で元に戻せます。
• IEND の欠落や破損。 それ以外は完全でありながら末尾の終端マーカーを失ったファイルは、「不完全なファイル」の警告を発します。有効な IEND を書き直せば、既にすべて揃っている画像を厳格なデコーダーが受け入れられるようになります。

正直な限界は、ピクセルデータそのものが失われたところから始まります。そしてスクリーンショットはその両方に見舞われます。

切り詰め—上部は戻る。 これはスクリーンショットが壊れる最も一般的な形です。ディスクが一杯になって中断した保存、スマホを抜いたときに途切れたコピー、80 パーセントで止まったクラウド同期などです。ファイルの前半は無傷で、末尾—通常は IEND を含みます—は単に存在しません。スキャンラインは上から下へと書き込まれるため、切り詰められた PNG は画像の上部として救出されます。データが終わるところまでの本物のピクセルです。修復は有効なトレーラーを書き直し、デコーダーがファイルを受け入れて生き残った分を描けるようにします。切断より下の行は破損しているのではなく、存在しません。だからどんなツールもそれらを返せません—結果は正直な部分復元です。

IDAT の途中での破損—下部はノイズ。 破損が末尾ではなく DEFLATE ストリームの内部に落ちた場合、回復不能になる理由は DEFLATE そのものにあります。これは各部分が直前の内容に依存する 1 本の連続したストリームで、再同期できる定期的なマーカーがありません。デコーダーはひとたび不良バイトに当たると流れを見失い（zlib は incorrect data check / invalid distance too far back を報告します）、それ以降のすべてはノイズとしてデコードされます。途中で 1 バイト反転しただけで、1 行だけでなくその下のすべての行を失いかねません—画像は当たった箇所より上はきれいで、下はゴミになります。だからこそスクリーンショットは、鮮明な上部とにじんだ、あるいは灰色の下半分とともに開くのです。切り詰められた JPEG が与えるのと同じ形の結果です。

これを、インデックスをデータと分けて保持する形式—QuickTime 動画の moov、SQLite の b-tree—と比べてみてください。そちらではマップを再構築すればファイル全体が救われます。PNG はピクセルを 1 本の分割不能な DEFLATE ストリームに保持するため、途中の傷は切断より下では永続的です。