今すぐ修復
- ファイルをドロップ
- 修復はローカルで実行
- 結果をダウンロード
Google Drive の 「Download folder（フォルダをダウンロード）」と Dropbox の 「Download as .zip（.zip としてダウンロード）」は、接続が切れると同じように失敗します。どのツールでも開けない ZIP が手元に残るのです。原因はほぼいつもごくありふれたもの — ファイルが切り詰められ、末尾の索引が欠けているだけで、中身がぐちゃぐちゃになっているわけではありません。上にアーカイブをドロップすると、ツールはブラウザ内で本当の構造を読み取り、転送が止まる前に完全に書き込まれたエントリを見つけ出し、ファイル全体を拒否するのではなくそれらを取り出します。何もアップロードされません。
切り詰め vs ビット腐敗：ひとつのラベルの下にある、まったく別の二つの故障
まったく別の二つの問題が、どちらも「壊れたアーカイブ」と呼ばれます。そして直し方は、あなたのがどちらかによって変わります。切り詰め（truncation）とは、ファイルが短いということです。最後のバイトが届く前にダウンロードが止まったので、アーカイブの末尾が欠けています。ビット腐敗（bit-rot）とは — ここでは転送中に混入したバイトの誤りのことで — ファイルの長さは正しいのに一部のバイトが間違っている状態を指します。途中のどこかで、ビットが反転したりゼロで埋まったりしたブロックがあるのです。この二つを見分けるのは十秒で済み、そして何を取り戻せるかのすべてを決めます。
まず容量を確認しましょう。Google Drive も Dropbox も、ファイルの詳細ペインに本当のバイト数を表示します。それを自分のディスク上のコピーと比べてください。自分のほうが小さければ、それは切り詰めです — それで話は終わりです。切り詰められた ZIP は End Of Central Directory レコード — ファイルの末尾 22 バイト強に置かれる PK\x05\x06 シグネチャ — を失っているので、索引を読もうと末尾へシークする展開ソフトはゴミか何も見つけられません。だからこそ unzip は End-of-central-directory signature not found や cannot find zipfile directory と言い、7-Zip と WinRAR は 「Unexpected end of archive（アーカイブが予期せず終了）」と言い、Windows 内蔵の展開機能は 「The Compressed (zipped) Folder is invalid.（圧縮フォルダーが無効です）」と言うのです。
容量は一致するのに展開がやはり失敗するなら、ビット腐敗です。索引は存在するので、ツールはアーカイブの中まで入り、代わりにファイル単位で失敗します。7-Zip は 「Data error（データエラー）」か 「CRC failed（CRC 不一致）」と報告し、unzip -t は該当するエントリに対して bad CRC と出力します。ZIP の各エントリは、非圧縮データの CRC-32 をローカルヘッダと中央ディレクトリの両方に保存しています。展開したバイトがその値にハッシュされなければ、ツールはそのファイルが壊れていると分かります — しかし他のファイルはたいてい無事です。
そもそもなぜクラウドのダウンロードがアーカイブを壊すのか
中断した転送は、何よりもアーカイブを切り詰めます。そしてクラウドストレージは独自のひねりを加えます。Drive の 「Download folder」や Dropbox の 「Download as .zip」を使うと、サーバーはその場で ZIP を組み立てながらストリーミングで送ってきます。送りながら圧縮しているため、各ファイルのサイズや CRC を事前に知りません。そこで各エントリで 汎用ビット 3（general-purpose bit 3）を立て、CRC とサイズを圧縮データの後ろにある データディスクリプタ（PK\x07\x08）へ書き込みます。ストリームの途中で接続が切れれば、有効な ZIP のきれいな先頭部分だけが残り、中央ディレクトリはまったくありません — 教科書どおりの切り詰めです。
大きなフォルダはこれを悪化させます。ZIP64 のしきい値 — ファイル数 65,535 超、またはデータ 4 GiB 超 — を越えるからです。ZIP64 アーカイブは PK\x06\x06 の ZIP64 EOCD レコードと PK\x06\x07 のロケータを最末尾に持ちます — 転送が早く止まったときに失う末尾メタデータがさらに増えるわけです。
クラウド特有の二つの罠が、破損のふりをします。第一に、Google Drive は大きなファイルのウイルススキャンを拒み、バイトの代わりに HTML の中間ページ（interstitial）を返します。もしそのリンクを wget や curl、スクリプトで取得したなら、あなたの「.zip」は実際には PK\x03\x04 ではなく <!DOCTYPE html> で始まっているかもしれません — それは Web ページであって、アーカイブではありません。第二に、ファイルを並列のバイト範囲で取りにいく 分割ダウンロードマネージャは、ある範囲が黙って失敗すると隙間や重複ブロックを残すことがあり、長さは完全なのに中央が壊れたファイルを生みます。これは切り詰めではなくビット腐敗です。ファイルを16進ビューアで開き、先頭 4 バイトが 50 4B 03 04（PK\x03\x04）かどうか確かめれば、そもそも ZIP を持っているのかどうかがすぐ分かります。
この救出処理が実際に取り出すもの
上にファイルをドロップすると、ツールは欠けている、あるいは読めない索引を無視して 先頭から前方へと走査し、PK\x03\x04 のローカルファイルヘッダをひとつずつ捕まえ、続く deflate ストリームをバイトが尽きるまで展開します。切り詰められたアーカイブでは、切れ目より前に完全に書き込まれたエントリはすべて無傷で戻ります。失われる、あるいは部分的になるのは、切り詰め点にまたがった一つのファイルだけです。ビット腐敗の場合、CRC-32 がなお一致するエントリはふつうに展開され、ツールはアーカイブ全体を切り捨てるのではなくハッシュが合わない特定のエントリだけを印付けします。これはあなたのタブの中で走る純粋な TypeScript です — unzip のバイナリもなく、何も送信されません。
RAR と 7z も、構造は違えど同じ原理に従います。RAR（シグネチャは v4 が Rar!\x1a\x07\x00、v5 が Rar!\x1a\x07\x01\x00）はファイルを独立したブロックに格納するので、損傷より前のものはなお復号でき、リカバリレコード（recovery record）付きで作られた RAR ははるかによく修復できます。そのレコードは、欠けたブロックを再構築するためにこそ存在するからです。.7z（シグネチャ 7z\xBC\xAF\x27\x1C）は厄介なケースです。ヘッダのデータベースを末尾に置き、多くのファイルを一本のストリームに連結する ソリッド（solid）圧縮をふつう使うので、末尾の喪失やストリーム途中のバイト誤りは、最後の無傷ブロック以降のすべてで展開を壊しかねません。ツールは生き残ったブロックが許すぶんだけ救い出し、ソリッドストリームを続けられないときはそれをはっきり伝えます。
正直な限界：失われたバイトは失われたまま
ディスクに一度も届かなかったバイトは、何をしても取り戻せません。ダウンロードが 70% で止まったなら、圧縮データの最後の 30% はローカルには単に存在せず、どんなツールも — このツールも、WinRAR 自身の Repair 機能も、有料の復元スイートも — それをでっち上げることはできません。切り詰めの本当の解決策は Drive や Dropbox から再ダウンロードすることで、できればサーバー側で圧縮したフォルダは避けるのがよいでしょう。元のファイルを直接落とすか、フォルダを小さなバッチに分けて落とせば、転送が最後まで終わる可能性が高まります。
圧縮ストリーム内のビット腐敗も、壊れた当のファイル一つのレベルでは同じく容赦がありません。deflate は状態を持つストリームなので — ビットが一つ反転しただけで、その地点から Huffman/LZ77 の復号が脱線します — 影響を受けたエントリは、CRC-32 がどのファイルを直撃したかを正確に教えてくれたにもかかわらず、たいてい誤りの箇所で切り詰められた形で戻ってきます。暗号化されたアーカイブ（AES-256 の ZIP、RAR や 7z のパスワード保護）は、エントリが暗号文なのでパスワードなしには走査できません。この救出処理が確実に防ぐのは、途中まで届いたアーカイブが丸ごと失われることです。十ファイル中九つが着地したのなら、十個目を追いかけて九つを失う理由はありません。そしてすべてがローカルで走るので、金融記録やソースコード、個人的な書類を収めたアーカイブが、中を覗くためだけに見知らぬサーバーへコピーされることは決してありません — Network タブ（ネットワークタブ）を開けば、一バイトも出ていかないことを確認できます。
修復できるものとできないもの
修復できる
- 中断した Drive/Dropbox のダウンロードで切り詰められた ZIP — 切れ目より前に書き込まれたエントリは、PK\x03\x04 のローカルヘッダを走査して復元します
- 一つのエントリのビット腐敗：CRC-32 がなお検証されるファイルはふつうに展開され、壊れたエントリはアーカイブ全体を失敗させる代わりに印付けされます
- データディスクリプタ（PK\x07\x08）をストリーミングし、接続断で中央ディレクトリを失った、サーバー側で圧縮されたフォルダ
- 末尾の PK\x06\x06 レコードと PK\x06\x07 ロケータを欠いた ZIP64 のフォルダダウンロード（ファイル数 65,535 超、または 4 GiB 超）
- 損傷より前のブロックがなお復号できる RAR アーカイブ — リカバリレコードがあれば劇的によくなります
- 生き残った最後の完全な（ソリッド）圧縮ブロックまでの 7z アーカイブ
修復できない
- 圧縮データが切り詰め点より後ろにあったファイル — それらのバイトはディスクに一度も届いていません（代わりに再ダウンロードを）
- 実際には Google Drive のウイルススキャン HTML ページである「.zip」— それは Web ページであって、アーカイブではありません
- ストリーム途中のバイト誤りに直撃された一つのエントリ、その deflate ストリームが壊れた地点より先
- 最後の無傷ブロックより先の 7z ソリッドストリーム（連鎖の後ろのファイルは展開できません）
- パスワードなしの暗号化／パスワード保護されたアーカイブ（エントリは暗号文です）
修復が失敗した場合、その理由（データの欠落か構造の破損か）をお伝えします。失敗した修復に料金が請求されることはありません。