"Unexpected end of archive"

あなたが目にするメッセージは、どのツールとどの形式を相手にしているかを強く示すヒントです — 何かに手を付ける前に読み解く価値があります。それぞれが少しずつ違う地点で失敗するからです。

• WinRAR — "Unexpected end of archive." 定番です。WinRAR は、ブロックヘッダーやアーカイブ終端マーカーがまだ「この先があるはず」と示しているのに、ファイルの終端に達しました。.rar にも、WinRAR が開く ZIP にも当てはまります。
• 7-Zip — "Unexpected end of data"（ときに "Unexpected end of archive"）。 7-Zip は、きれいな切り詰め（「end of data」）を、誤ったシグネチャ（「is not archive」）や、反転したバイト（「Data error」）と区別します。「End of data」は具体的に、ストリームが途中で止まったこと — かき混ぜられたのではなく、切り詰められたこと — を意味します。
• Info-ZIP unzip — "cannot find zipfile directory … End-of-central-directory signature not found." unzip は末尾から後ろ向きに PK\x05\x06 を探しますが見つからず、そのためファイル一覧すら構築できません。データ自体は無事かもしれませんが、索引が失われているのです。
• Windows エクスプローラー — "The compressed (zipped) folder is invalid." 内蔵の展開機能は、この中で最も具体性に欠けます。たいていは同じ EOCD 欠落の話です — その正確な文言については "Compressed folder is invalid" をご覧ください。
• macOS のアーカイブユーティリティ — "Error 2 – No such file or directory." 有名なほど不透明です。見つけられない「ファイル」とは、末尾にあると期待していた中央ディレクトリレコードのことです。同じ切り詰めですが、とりわけ役に立たないメッセージです。
• Python zipfile — BadZipFile: File is not a zip file、あるいは .read() でのエラー。 EOCD が欠けていると、zipfile はそもそも開くことを拒みます。後方のエントリだけが切り詰められている場合は問題なく開き、そのメンバーを読むときにだけ失敗します。
• GNU tar / gzip — "Unexpected EOF in archive" / "unexpected end of file." まったく別の構造（中央索引がそもそも存在しない）です — 後述します。

あなたの文言がこのリストにあるなら、ほぼ間違いなく手元にあるのは短いファイルであって、かき混ぜられたものではありません — そして復旧は、どのツールが報告したかにかかわらず同じです。

どのアーカイブ形式も、「アーカイブは完全で、その内容はここに索引されている」と告げる小さな重要構造を保持しています。その構造はファイルの末尾、あるいはその近くに存在します — まさに切り詰めが真っ先に破壊する領域です。どのマーカーが欠けているかを知れば、どれだけ救出できるかがわかります。

• ZIP — End Of Central Directory（PK\x05\x06）。 ZIP は、ローカルエントリの連なり（それぞれ PK\x03\x04 で始まる）、次に PK\x01\x02 レコードの中央ディレクトリ、そして最後に 22 バイトの EOCD です。EOCD が索引です。大きな、あるいは 4 GB を超えるアーカイブは、その直前に ZIP64 の EOCD レコード（PK\x06\x06）とロケーター（PK\x06\x07）を加えます。末尾を失えば索引を失います — しかし、自己記述的なローカルエントリは失いません。
• RAR 4 — アーカイブ終端ブロック（HEAD_TYPE 0x7B）。 Rar!\x1A\x07\x00 シグネチャの後、RAR4 は独立して復号できるブロックを格納し、終端ブロックで締めくくります。切断より前のファイルはなお復号できます。リカバリレコード付きで作成された RAR なら、欠けたブロックをまるごと再構築できます。
• RAR 5 — アーカイブ終端ヘッダー（ヘッダータイプ 5）。 シグネチャは Rar!\x1A\x07\x01\x00、再設計されたヘッダー形式ですが、考え方は同じ — 切り詰めが取り除いてしまう専用の終端ヘッダーです。
• 7z — Start Header が末尾の End Header を指す。 37 7A BC AF 27 1C シグネチャと 2 バイトのバージョンの後には、NextHeaderOffset、NextHeaderSize、CRC を保持する 20 バイトの Start Header があります — ファイルの一番最後にあるヘッダーデータベースへのポインターです。ファイルを切り詰めると、そのポインターは最後のバイトより先を指します。さらに悪いことに、.7z は既定でソリッド圧縮を使い、ファイルを 1 本のストリームに連結するため、末尾を失うと最後の完全なブロック以降のすべてのファイルが壊れかねません。

パターンは普遍的です。展開器が最初に必要とするメタデータが最後に格納されるので、切り詰めが真っ先に殺すのがそのメタデータなのです。だからこそ "unexpected end" はこれほど頻発し、だからこそデータ自体はたいていまだ復旧できるのです。

tar は例外で、診断が異なるため独自の説明に値します。.tar には中央索引がまったくありません。それは 512 バイトレコードの素朴な並びです — ファイルごとに 1 つのヘッダーブロック（名前、サイズ、チェックサムを持つ ustar ヘッダー）、続いて次の 512 バイト境界まで詰められたファイルのデータ。アーカイブは連続する 2 つのすべてゼロの 512 バイトブロックによって終了が宣言されます。末尾のゼロブロックが届かなかった場合、完全に書き込まれた各ファイルが完璧に抽出できるにもかかわらず、tar は "Unexpected EOF in archive" と表示します — tar はレコードを先頭から末尾へたどるだけなので、尽きたバイトまでのすべてを復元します。

.tar.gz（または .tgz）は、その tar ストリームを gzip で包みます。gzip メンバーは 10 バイトのヘッダー（1F 8B 08 …）、deflate ストリーム、そして非圧縮データの CRC-32 と ISIZE（元のサイズを 2³² で割った余り）を保持する 8 バイトのトレーラーです。切り詰めると gzip は "unexpected end of file" と報告します — 切断点までは正しく解凍し、その後は照合すべきトレーラーがないのです。救出は ZIP と同じ原理です。無傷なバイトが許す限り前方へ復号します。

"Unexpected end" は症状です。原因があなたの最善手を決め、それには 3 つあります。

• 止まった、あるいはキャンセルされたブラウザのダウンロード。 アーカイブがリンク経由で、転送が最後まで終わらなかった場合（居残った .crdownload/.part、"Failed – Network error"）、正確にどのバイトが生き残るかの仕組みは固有のものです — 中断された ZIP のダウンロードをご覧ください。
• 完全に見えて実はそうでないクラウドのファイル。 Drive、Dropbox、OneDrive は、.zip にリネームされた HTML のエラーページや、部分的な同期を渡してくることがあります — 破損になりすます切り詰めです。短いファイルを本物のビット腐敗と見分けるには、壊れたクラウドのアーカイブを診断する方法をご覧ください。
• 元のファイル自体が短い。 元のファイルが本当に末尾を欠いているなら、どんなツールも欠けたバイトをでっち上げられません — それでも IntactFile は切断より前に書き込まれたすべてを抽出します。上にドロップして、無傷のエントリを救出してください。

どの場合でも、救出そのものは同一で、すべてあなたのタブ内で動きます。IntactFile は欠けた終端マーカーを無視し、ファイルの先頭から前方へ走査して各無傷エントリを捕まえ、生き残ったバイトが許す分を解凍します — 純粋な TypeScript で、アーカイブユーティリティのインストールは不要、そしてネットワーク（Network）タブを開けば、非公開のアーカイブのバイトが 1 つもあなたのマシンから出ていかないことを確認できます。