今すぐ修復
- ファイルをドロップ
- 修復はローカルで実行
- 結果をダウンロード
PNG スクリーンショットはどこから来て—どこで壊れるのか
スクリーンショットの一生は、キャプチャ → ディスクへの書き込み →(たいていは)自動同期 → 貼り付けまたは共有、です。破損はほぼ必ず最後の 3 つのステップのどれかで入り込み、どれで起きたかがあなたに見分けられる指紋を残します。
- Windows。 PrtScn は画像をクリップボードだけに置きます—貼り付けて「名前を付けて保存」するまで何も保存されないので、クラッシュすると完全に失われます。Win+PrtScn と Snipping Tool は本物の
.pngをPictures\Screenshotsに書き込み、そのフォルダーはしばしば OneDrive にリダイレクトされています。OneDrive がスクリーンショットを着地した瞬間にアップロードし始めると、アップロード途中の再起動やサインアウトが切り詰められたファイルを残しかねません—おなじみの「画像の上部は問題ないが、下部は灰色」という結果です。 - macOS。 ⌘⇧3/4/5 は既定で PNG(ウインドウのキャプチャは透明な角を保つため、多くはカラータイプ 6、RGBA)をデスクトップに保存します。デスクトップが iCloud Drive にある場合、同じ同期途中の切り詰めが当てはまります。書き込みがディスクに書き出される前にキャプチャ UI やフローティングサムネイルを強制終了しても、ファイルが途中で切れることがあります。
- Android。 スクリーンショットは
DCIM/ScreenshotsまたはPictures/Screenshotsに収まり、Google フォトにバックアップされます。もろいのはスクロールまたは「範囲を拡大」のスクリーンショットです。OS は複数のフレームを 1 枚の縦長の PNG につなぎ合わせますが、その合成の工程が中断されると、出力は単に短いのではなく不正な形になりかねません。 - 貼り付けて再ダウンロードした。 これはスクリーンショット特有のケースです。人々が Slack、Discord、Teams、あるいはチケット管理ツールに直接ドロップするのがスクリーンショットだからです。それらのサービスはアップロード時にしばしば再エンコードします。その結果をダウンロードすると、以前の破損は新しいピクセルに焼き付けられ、あるいはあなたが保存したファイルは実は
.pngにリネームされた HTML のプレビューだったりします。 - テキストモードのブリッジを通した。 ASCII モードのままの FTP クライアント、古いメールゲートウェイ、あるいはファイルをテキストとして書き直したスクリプトを通されたスクリーンショットは、すべての
0D 0Aを単独の0Aに(またはその逆に)置き換えます。PNG のシグネチャはまさにこれを検出するよう意図的に作られており、置換が一貫している場合は 1 バイト単位で元に戻せます。
パターンに注目してください。スクリーンショットの主要な失敗は風変わりな破損ではなく、早く止まってしまった保存や同期です。これは復元にとって良い知らせです。短いファイルにも、切断点までの本物のピクセルがまだ含まれているからです。
なぜスクリーンショットの寸法は復元できる種類の破損なのか
スクリーンショットを開けなくするのに完璧に直せる唯一の破損は、壊れた IHDR—幅と高さを格納する 13 バイトのヘッダー—です。それらをゼロにすると、どのデコーダーもキャンバスを確保できず、フォトやプレビューはただファイルを拒否します。しかし IHDR は、あらゆる PNG チャンクと同じく、数値が正しかった当時に計算された CRC-32 を持っています。つまり、正しいジオメトリは総当たりで求められるのです。候補となる幅/高さの組を試し、それぞれについてチャンクの CRC を再計算し、保存されている値と一致したところで止めます。(その CRC とそれが守るチャンクの詳しい仕組みは PNG の CRC エラーのページにあります。)
スクリーンショットはその探索をほぼ自明にします。寸法が任意ではなく、短いディスプレイ解像度のリストに集中するからです。Windows のキャプチャはおそらく 1920×1080、2560×1440、あるいは 3840×2160 でしょう。スマートフォンは 1080×2400 や 1179×2556 のような既知のパネルサイズです。そして macOS の Retina キャプチャはバッキングストアの解像度、すなわちポイントサイズを 2 倍にしたものです—14 インチ MacBook Pro の全画面キャプチャは 3024×1964、16 インチは 3456×2234 です。スクリーンショットがしばしば持つ pHYs チャンクはそのピクセル密度を記録するので、Retina の「@2×」キャプチャは自分自身の倍率さえ教えてくれます。任意の画像では遅いジオメトリ探索が、スクリーンショットでは数回の試行で解決します。答えがほぼ必ず標準的な解像度だからです。
何が戻るのか—そして修復の前に試すこと
スクリーンショットの通常の不具合は短いファイルなので、通常の結果は正直な部分復元です。PNG は 1 本の連続した圧縮ストリームの中で行を上から下へと書き込むため、切り詰められたキャプチャはバイトが終わるところまできれいにデコードされ、ツールは有効なトレーラーを書き直して、ビューアーが生き残った分を受け入れられるようにします。切断より下の行は一度も書き込まれておらず、だからどんなツールもそれらを返せません。末尾ではなくストリームの内部に落ちた破損は、その下のすべての行を失わせます。(そのストリームがなぜ再同期できないのか—そしてなぜ途中での被弾が永続的なのか—は PNG の CRC エラーのページで説明しています。)
ただし修復の前に、スクリーンショットには他のどんな壊れたファイルよりも速い抜け道があることが多いのです。まずこれらを試してください。
- 被写体はまだ画面に出ていますか? スクリーンショットを撮り直すのは考えうる最も安上がりな解決策で、まっさらなファイルが手に入ります。できるなら、何よりも先にこれをしてください。
- Windows では PrtScn がクリップボードに保持します。 保存したファイルが壊れていても、それ以降まだ何もコピーしていなければ、Paint やフォトに貼り付けて(Ctrl+V)、新しい PNG として「名前を付けて保存」してください—クリップボードのコピーは破損したファイルとは独立しています。
- 自動同期されたショットのもう一方のコピーを確認する。 ローカルのファイルがアップロード途中で切り詰められた場合、OneDrive / iCloud / Google フォトのコピーは完全かもしれません—あるいはその逆です。ファイルサイズを比べてください。たいていは大きくて新しいほうが勝ちます。同期されたプレースホルダーを信じるのではなく、クラウド版を新たにダウンロードしてください。
- macOS のフローティングサムネイルがまだ表示されていますか? それをクリックしてキャプチャを開き直し、消える前に再エクスポートしてください—そのメモリ上のコピーは、失敗した書き込みを経ていません。
これらのどれも当てはまらないときは、上にファイルをドロップしてください。チャンクの走査、CRC のチェック、ストリームのデコードはすべてブラウザのタブ内でただのコードとして動き、ネットワーク(Network)タブを開けば 0 バイトしか出ていかないことを確認できます—スクリーンショットに銀行の残高、非公開のチャット、パスワードが写っているときには、これが重要です。
修復できるものとできないもの
修復できる
- 書き込み途中の保存を捕まえた自動アップロードのフォルダー(OneDrive / iCloud / Google フォト)に切り詰められたスクリーンショット—切断より前に書き込まれた行は本物のピクセルとしてデコードされて戻ります
- ゼロ化または破損した IHDR の幅/高さ。スクリーンショットの寸法はほぼ必ず標準的なディスプレイ解像度なので、素早く復元できます
- 保存された CRC-32 が、それ以外は無傷なデータともはや一致しないチャンク—CRC を再計算し、ファイルは損失ゼロで有効になります
- ASCII モードの転送や、ファイルをテキストとして書き直したチャットのブリッジによる改行 / テキストモードの文字化け(CR-LF ↔ LF)
- 画像データはそれ以外完全なファイルにおける、欠落または不正な IEND 終端マーカー
修復できない
- 切り詰められたスクリーンショットの切断より下の行—それらのピクセルは一度も書き込まれておらず、どんなツールもでっち上げられません
- 途中の IDAT 被弾より下の画像の行—圧縮ストリームは再同期できないため、それ以降はすべてノイズです
- 破損後にチャットサービスやエディターが再エンコードしたスクリーンショット—誤ったピクセルがもう焼き付いています
- つなぎ合わせがひどく失敗して完全なフレームが 1 枚も書き込まれなかった、スクロール / 「範囲を拡大」のショット
- 0 バイト、あるいはすべてゼロとして読み取られるファイル—再構築すべき画像がありません(それは修復ではなくデータ復旧の仕事です)
修復が失敗した場合、その理由(データの欠落か構造の破損か)をお伝えします。失敗した修復に料金が請求されることはありません。