ZIPアーカイブの最大サイズが4GBの場合、どのように33GBのZIPアーカイブを持つことができますか?

ZIPアーカイブの最大サイズが4GBの場合、どのように33GBのZIPアーカイブを持つことができますか?

私はこれを持っています:

-rw-r--r--  1 user user 36166999908 Jan 29  2022 tmp.archive.part1.zip
-rw-r--r--  1 user user  5579574562 Jan 29  2022 tmp.archive.part2.zip
-rw-r--r--  1 user user  5097536636 Jan 29  2022 tmp.archive.part3.zip
-rw-r--r--  1 user user 10612382236 Dec 29 02:19 tmp.archive.part4.zip 
                          G  M  k    

したがって、このZIPファイルのサイズはそれぞれ36GB、5、5、10GBですが、すべて1か所で読み取った最大値である2^32 4GBを超えます。彼らは「zip64」が2^64サイズを受け入れると言いますが、私が何を持っているのかわかりません。 zip -hは次のように言います。

Copyright (c) 1990-2008 Info-ZIP - Type 'zip "-L"' for software license.
Zip 3.0 (July 5th 2008). Usage: ...

文書によると、

file tmp.archive.part1.zip
tmp.archive.part1.zip: Zip archive data, at least v1.0 to extract

それはどのように可能ですか?

私はzipmergeがこれらのファイルに対してまったく機能しないことを知りました。

私の問題は、これらのzipファイルを実際に抽出せずに(可能であれば)1つにマージする必要があることです(システムにスペースとファイル数のクォータがありません)。誰かがここで別の質問に投稿したzip2tar Pythonスクリプトを試しましたが、それも失敗しました。彼らはファイルがzipファイルではないか、コアダンプと競合するだけだと言っても、ファイルが好きではありません。

私が示したように、これらのzipファイルがzip 3.0で作成された場合、より良いzipmergeまたはサイズのためにブロックされないものはありますか?

答え1

「ZIP」アーカイブにはいくつかの種類があるためです。

PKZIPの最初のバージョンによって実装された元のZIP形式には、アーカイブサイズが4GiBに制限されていました(そして、アーカイブメンバーサイズ(圧縮と非圧縮)にも対応する制限もありました)。ただし、バージョン4.5形式ではZIP64拡張子が導入され、ファイルヘッダーとアーカイブエントリの関連フィールドをアーカイブの他の場所に格納されているセカンダリフィールドに移動し、アーカイブメンバー数を調整してこの制限を16EiBに拡張しました。同様に(クラシックZIPは65535人のアーカイブメンバーに制限されています)。

しかし、、ツールが実際にこれらの拡張フィールドを見つけない限り、その拡張フィールドは無視され、ツールは正しく機能しません。これは、ZIP64アーカイブがまだ残っているためです。技術的にメンバーサイズを確認しない限り、有効な「クラシック」ZIPアーカイブです(これは、以前のバージョンとの互換性が時々悪い理由を示す良い例です)。


実際に以下があるという点に注目する価値があります。たくさんZIP形式の他の潜在的な非互換性。特に注目すべき点は、ZIPアーカイブで使用できる互換性のない暗号化メカニズムが複数あり、ほぼ12の異なる圧縮アルゴリズムがあることです。このアルゴリズムはすべて、ほとんどの実装ではサポートされていません。 、「Deflate」または「Deflate64」とそのはいほぼすべてがサポートされています。)

答え2

Info-ZIP 3.0は4GBの制限を高め、ZIP64をサポートする最初のバージョンであり、ほぼ15年になったことがわかるように、現在公式にサポートされている最新バージョンです。

答え3

興味深い質問です!

簡単なウェブ検索でこの興味深い文書を見つけることができます。[1];
実際、それは単なるZIPリビジョンではありません。
正直言って専門家ではないので、この情報は今忘れられたり埋められていると推測できます。シンプル:もともとZIPリビジョンは古い(現在の)デバイス/ソフトウェア用に提案され設計されていましたが、現在はコンピュータサイエンス/デバイスの進歩により他の(以前の)リビジョンを処理する必要はありません。

私はこの珍しい情報を見つけるためのツール/コマンドがなければ、バイナリ構造を直接手動でマイニングすることが唯一の(そして最も難しい)方法だと思います。[2]

ツールの存在に戻って私は発見した。zipdetails [サム]perl、これは(直感的に)あなたに役立つ、または少なくともあなたの仕事を容易にすることができるパッケージの一部です!


[1] https://peazip.github.io/rar-zip-file-format-size-limitations.html
[2] https://en.wikipedia.org/wiki/ZIP_(file_format)#構造
[サム] https://perldoc.perl.org/zipdetails

関連情報