「Unexpected end of archive」— その意味と、それでも取り出せるもの

正確なエラー文と、それが伝えていること

どのツールがファイルを開くかによって文言は変わりますが、意味は変わり ません。WinRAR はこう表示します：

Unexpected end of archive、そしてしばしばそれと並んで The archive is either in unknown format or damaged。

7-Zip は同じ失敗を Unexpected end of data、あるいは損傷が ファイルの先頭にまで及んでいる場合は Cannot open the file as archive と表現します。Linux や macOS では、コマンドラインの unzip が unexpected end of file、あるいはより正確な End-of-central-directory signature not found と報告します。

これらの文字列は、どれもが一つの状況を言い表しています。フォーマットが 定めるよりも前に、ツールがファイルを使い果たしてしまった、ということ です。ZIP や RAR には定まった形があり、特定の構造が決まった場所に あるはずだと想定されています。ファイルがその形の求める長さより短いと、 ツールは予期せず末尾に到達して停止します。ここでの「unexpected（予期 しない）」とは、そういう意味です。これはランダムな不具合ではなく、 たいていはデータがめちゃくちゃになっているわけでもありません。末尾が 欠けたファイルなのです。

ZIP はインデックスをいちばん末尾に保持する

末尾の欠落がなぜこれほど致命的なのかを理解するには、ZIP がどう配置 されているかを知っておくと役立ちます。アーカイブは、二つのものが縫い 合わされたものです。まず来るのがエントリ——あなたが追加した各ファイル が圧縮され、次々に連ねて書き込まれ、それぞれの前には名前とサイズを 記した小さなローカルヘッダーが付きます。次に、すべての エントリの後に来るのがセントラルディレクトリ——アーカイブ 内のすべてのファイルと、それぞれが始まる正確なバイトオフセットを列挙 した表です。

ZIP はまずファイルを、最後にそれらを列挙するディレクトリを格納します。切り詰められたダウンロードで失われるのはディレクトリであって、その前にあるファイルではありません。

セントラルディレクトリは、アーカイブのインデックスです。ZIP をダブル クリックすると、ツールは末尾にジャンプしてそのディレクトリを読み取り、 それを使ってファイル一覧を表示します。インデックスを末尾に置くのは 意図的な設計です——これにより、元々の ZIP フォーマットは、アーカイブ 全体を書き直すことなくファイルを追記できました。難点は、ツールが最初に 必要とするただ一つの構造が、いちばん最後に格納される構造でもある、と いうことです。そのため、ファイルの末尾から始まるどんな損傷も、まっすぐ インデックスに命中します。これは表計算ファイルを脆くしているのと同じ パターンで、というのも .xlsx ファイルは実のところ ZIP であり、自分自身のディレクトリを末尾に持っているからです。

なぜ途中で切れたダウンロードは、ファイルではなくインデックスを失うのか

ZIP は先頭から末尾へと書き込まれ、転送されます。ダウンロードが止まったり、 クラウド同期があきらめたり、コピーの途中で USB ドライブが抜かれたり すると、ディスクに残るのは中断前に届いた分だけです。先頭は無傷で、 後半は単に存在しません。ディレクトリは後半にあるので、あらゆる切り詰め の最初の犠牲者になります。先頭付近のエントリ、つまり実際の圧縮ファイル は、手つかずのまま残っています。

これこそが、このエラーがこれほど復元しやすい理由のすべてです。ツールは ディレクトリを見つけられないため、通常の方法でアーカイブを開くことを 拒み、予期しない終端を報告します。しかし、ファイルそのものは初めから 問題ではありませんでした。修復の処理は、欠けたディレクトリを無視し、 代わりにアーカイブを先頭からたどって、各ローカルヘッダーを読み、それに 続く圧縮データを取り込み、見つけたものから新しいディレクトリを作り直し ます。アーカイブは再び開き、物理的に生き残ったすべてのエントリを一覧 表示します。

手早い確認で、切り詰めとそれより悪いものを見分けられます。元のサイズが わかっているなら、ファイルサイズと突き合わせてみてください。240 MB の アーカイブが 180 MB で届いていたら、それは教科書どおりの切り詰めで あり、欠けた 60 MB は損傷しているのではなく、別の場所にあるのです。 だからこそ、再ダウンロードが最初の一手になります。欠けたバイトは今も 入手元に存在していて、きれいなコピーは、部分的なものをどう救い出した ものよりも勝ります。アーカイブが Web ダウンロードやメールの添付から 来たものなら、修復する前にそちらの経路を試してください。この同じ話の Windows 固有版——エクスプローラー内蔵の展開機能が、上記のツールより 厳格である場合——は 「圧縮 (zip 形式) フォルダーは無効です」で扱っています。

部分展開：生き残ったものを取り出す

きれいなコピーが手に入らないとき、部分展開が現実的な目標であり、それは しばしば非常に良い結果になります。各エントリが自分専用のローカル ヘッダーと自分専用の圧縮ブロックを備えているため、切断より前に格納 されたファイルは、その後に失われたものから独立しています。修復ツールは アーカイブを順番に読み、データが切り詰められた地点に達するまで、各 エントリを復元します。結果は、すべてか無かではありません——「50 個の うち 42 個のファイルが戻ってきた」であり、欠けた 8 個は、転送が止まった ときにまだ通信の途中にあったものです。

正直に名指ししておくべき境界のケースが一つあります。切断のちょうど地点 にあるファイルは、たいてい中途半端です——ヘッダーと圧縮データの最初の 部分は届いたものの、残りは届きませんでした。そのファイルは、自身の 切り詰められた版として展開されるかもしれませんし、フォーマットや切断が どこまで進んだ地点で起きたかによっては、まったく展開できないかもしれ ません。それより前のものはすべてきれいに展開されます。ですから、妥当な 期待はこうです——切断までは完全なファイル、境界にはおそらく損傷した 一つのファイル、そしてその先には何もない。WinRAR の「壊れたファイルを 保持する」オプションや、他のツールの同等の設定は、まさにその境界の ファイルを、価値がある限り書き出すために存在しています。

本当に手の施しようがないとき

構造的な修復は、生き残ったデータの周りにインデックスを再構築します。 そこに存在しないデータを作り出すことはできず、いくつかの状況は、 どんなツールにもできることの外にあります。それらについて率直である ことが、あなたの時間を節約します：

• 損傷が末尾ではなく、ストリームの途中にある。 ZIP が 使う圧縮方式である DEFLATE には冗長性がありません。それは連続した ストリームであり、各部分がそれ以前の部分に依存しています。末尾で きれいに切られるのではなく、あるファイルの圧縮ブロックの内部でバイト が破損したり欠けたりしていると、展開は損傷地点で同期を失い、ファイル 内でそれ以降のすべてが復元不能になります。そのファイルの先頭は得られる かもしれませんが、全体は得られません。
• アーカイブが暗号化されている。 パスワード保護された、 あるいは AES で暗号化されたアーカイブは、構造的には修復でき、 ディレクトリを再構築し、エントリを再び一覧表示できますが、圧縮データは 暗号化されたままです。パスワードがなければ、復元されたエントリを使える ファイルへ復号することはできません。修復が直すのは入れ物であって、 暗号化を破るわけではありません。まっとうなツールなら、そうでないと 主張することはありません。
• 分割セットの必要な一部が欠けている。 分割アーカイブ （.z01、.z02、あるいは .part1.rar の類）は、一つの連続したストリームを複数のファイルに またがって格納します。途中の一部が届かなかった場合、ストリームには 本物の隙間ができ、隙間より後のボリュームを、その前のものにつなぐ ことはできません。
• ファイルがほとんど空である。 数メガバイトの元ファイル に対して数キロバイトで戻ってきたアーカイブや、ほとんどがゼロとして 読めるものには、復元すべき本物のエントリがありません。それは ダウンロードや復旧の問題であって、修復の問題ではありません。

こうしたケースを除けば、切り詰められたアーカイブは、向き合う破損の 中でも比較的やさしいものの一つです。というのも、フォーマット自身の 配置のおかげで、生き残ったファイルに一つずつ手が届くからです。