中断したダウンロードの ZIP

ZIP は先頭から末尾へ書き込まれますが、読むときは末尾から先頭へ向かって読みます。追加した各ファイルは ローカルファイルエントリとして格納されます — シグネチャ PK\x03\x04 で始まるヘッダーに、名前、圧縮方式(0 = 無圧縮 stored、8 = deflate)、そしてその後に圧縮バイトが続きます。しかし、それらのエントリがどこにあるかを示す正式なインデックスは、最後に書き込まれる セントラルディレクトリ(PK\x01\x02 レコード)で、22 バイトの End Of Central Directory レコード PK\x05\x06 の直前に置かれます。展開ツールはファイルを開くときに末尾へシークし、その PK\x05\x06 シグネチャを求めて後方へ走査します — レコードが可変長のコメントフィールドで終わるため、およそ 65,557 バイト手前まで遡ります。EOCD を見つけて初めて、アーカイブが何個のエントリを持ち、各セントラルディレクトリレコードがどこから始まるかがわかります。

ここで、70% で止まったダウンロードを思い浮かべてください。届かなかったバイトは、最後に書き込まれるもの — セントラルディレクトリと EOCD です。展開ツールは末尾へシークし、後方へ走査しますが、PK\x05\x06 をついに見つけられず、ファイルを 1 つも触らないうちに諦めます。これこそが、unzip の "End-of-central-directory signature not found"、7-Zip と WinRAR の "Unexpected end of archive"、エクスプローラーの "The Compressed (zipped) Folder is invalid"、macOS のアーカイブユーティリティの "Unable to expand … (Error 2)" の正確な原因です。どれも、保存されたファイルがかき混ぜられていることを意味しません — 末尾にある目次が失われている、ということを意味します。

中断したダウンロードが特にこの問題を起こしやすいのは、多くの ZIP がどう生成されるかに関係しています。サーバーがその場で組み立てるアーカイブ — クラウドストレージの「すべてダウンロード」、GitHub のソース tarball に並ぶ ZIP 版、エクスポート用のバンドルなど — は、たいてい ストリーミングで送られます。汎用ビットフラグのビット 3(0x0008)が立てられ、各ローカルヘッダーの圧縮サイズと CRC-32 はゼロのまま残され、本来の値はエントリのデータの後に データデスクリプタ(PK\x07\x08)として付け加えられます。そうしたアーカイブでは、サイズが保証される場所はセントラルディレクトリだけなので、末尾を失うと通常の展開ツールにとって二重の打撃になります。ブラウザが残した書きかけのファイル — Chrome/Edge の .crdownload、Firefox の .part、あるいは単にレスポンスの Content-Length より短い .zip — には、切断までのすべての完全なエントリが含まれ、それ以降は何も含まれません。

この救出処理は、欠けたインデックスをまったく必要としません。ZIP では各ローカルエントリが自己記述的だからです。ツールは末尾へシークする代わりに、オフセット 0 から前方へ走査し、見つけた各 PK\x03\x04 ローカルヘッダーで止まって、ファイル名と圧縮方式を読み取り、続く deflate ストリームを展開します。deflate は自己終端型です — ストリームはブロックの並びで、最後のブロックは BFINAL ビットが 1 に設定されているので、ストリーミング書き込みによってローカルヘッダーのサイズフィールドがゼロのまま残されていても、デコーダはエントリのデータがどこで終わるかを見つけられます。ストリームがきれいに終端すると、ツールは復元したファイルを記録し、末尾のデータデスクリプタ PK\x07\x08 があればそれを飛ばして、次の PK\x03\x04 へ進みます。これはあなたのタブ内で純粋な TypeScript として動作します — unzip バイナリも不要で、何も送信されません。

その結果、中断より前に完全に書き込まれたすべてのファイルが、元の名前とディレクトリのパスとともに、順番どおりに戻ってきます。10 個中 4 番目のファイルの途中でダウンロードが途絶えた場合、最初の 3 個は無傷で得られ、4 番目は部分的になるか失われます。届かなかった 6 個を呼び戻すことはできませんが、それらはそもそも目的ではありませんでした。「無圧縮(stored)」エントリ(方式 0、圧縮なし — ZIP の中に入れられた JPEG や MP4 などのすでに圧縮済みの中身によく使われます)は、救出がさらに簡単です。そのバイトは切り詰め地点までそのままコピーされるので、途中までしか届かなかった大きなファイルでも、何も得られないのではなく、使える先頭部分の断片が得られることがよくあります。

どんなツールも、ディスクに届かなかったバイトを返すことはできません。接続が 70% で切れたなら、圧縮データの最後の 30% はローカルには存在せず、何をもってしても — このページも、WinRAR の「修復(Repair)」も、有料の復元ソフトも — それを再構築することはできません。失われた末尾に対する唯一の本当の解決策は、元の場所から アーカイブをもう一度ダウンロードすることです。できれば HTTP レンジリクエスト(range requests)に対応したクライアントを使い、中断した転送が最初からやり直すのではなく、止まったところから再開できるようにするとよいでしょう。サーバーが ETag や Content-Length を送っていたなら、その長さをあなたの部分ファイルのサイズと比べることで、実際にどれだけ欠けているかが正確にわかります。

いくつか正直な注意点があります。暗号化された ZIP(圧縮時にパスワードが設定されたもの、汎用ビット 0)は、パスワードなしでは走査できません。エントリのデータは暗号文で、たどるべき deflate 構造がないからです。ZIP64 形式で書かれた非常に大きなアーカイブは、独自の末尾構造 — ZIP64 EOCD レコード(PK\x06\x06)とそのロケータ(PK\x06\x07) — を持ちますが、これらは従来の EOCD とまったく同じように末尾とともに失われます。それでも前方走査は、形式にかかわらずローカルエントリを復元します。そして、最初のローカルヘッダーの断片しか届かなかったほど短いダウンロードには、たどるものが何もありません。この両極端の間にあるものは、すべて復元の対象になります。

処理のすべてがあなたのブラウザ内で行われるため、中身を覗くためだけにアーカイブがサーバーへコピーされることは決してありません — 「すべてダウンロード」のバンドルに税務書類、エクスポートしたチャット履歴、非公開のソースコードが入っているときに、これは重要です。ネットワークタブを開き、復元を実行して、ファイルから 0 バイトも自分のマシンを離れないことを確認できます。