2012-09-12 2 views
5

zipファイル形式は中央ディレクトリセクションで終わり、ファイル内の個々のzipエントリを指します。これにより、zipファイル内のどこにでもzipエントリが存在するように見えます。実際には、自己解凍式zipファイルが良い例です:実行可能ファイルから始まり、すべてのzipエントリは実行可能バイトの後に発生します。zipファイルをスパース/非連続にすることはできますか?

質問があります:ZIPファイル形式では実際には疎または非連続のZIPエントリが許可されますか?例えば、。 zipエントリ間に空白または別の理由がないバイトがある場合決定的なPKノートとウィキペディアの両方の記事がこれを可能にしているようです。すべての/最も典型的なzipユーティリティは、そのようなスパースなzipファイルで動作しますか?

このユースケースは次のとおりです。zipファイルのzipエントリを削除または置き換えたいと思っています。これを行うには、典型的なミニクリップなどのライブラリでは、削除または置換されたzipエントリをコピーしないでzipファイル全体をコピーする必要があります。

エントリの記憶域を1.5倍と言った場合、エントリを削除または置換するときに、割り当てられていないバイトがどこにあったかを把握して直接使用する方が良いでしょうか? 1.5倍を使用すると、ジップ入力が直線的に増加した場合、再割り当ても直線的に償却される必要があります。おそらく高度ではないが、ファイルシステムのブロック割り当てに似ているだろう。

これは、多くのZIPベースのファイル形式に役立ちます。一時的に解凍されたファイルを一時的に解凍したファイルを一時ディレクトリに置いて(あるいはメモリ内に)編集してからファイル形式に戻す必要はなく、ジップの部分を再圧縮して書き直す必要はありませんファイル。

これを行うC/C++ライブラリはありますか?

+1

圧縮の目的を敗北させるような全体的なストレージの種類はありませんか? –

+0

zipファイルは、動的ストレージ管理に最適なメディアではありません。それはアーカイブです。あなたのデータを一緒に圧縮してください。 –

+0

英語のテキストまたはXMLは、最大10倍まで圧縮できます。全体のzipファイルを書き直すことができない場合は、余分なスペースを0.5倍に過度に割り当てるだけで十分です。この過剰配分はAPIレベルで決定することができます。サイズが増加しそうにないことが分かっているエントリには、十分なスペースを割り当てることができます。 –

答えて

4

いいえ、中央ディレクトリの読み取りはオプションです。 zipデコーダは、ローカルヘッダとエントリデータを連続して見ることを期待して、最初から順番にzipファイルを読み込むことができます。彼らはデコードの仕事を完了することができ、決して中央のディレクトリを見ることさえありません。

あなたが望むことをするためには、そのスペースを保持するために有用なエントリの間にダミーのジップエントリを入れる必要があります。少なくとも、あなたはzipの世界の残りの部分と互換性を持ちたいと思っています。

+0

非連続的なzipファイル上でそのようなzipデコーダを実行すると、何が行われますか(ダミーのzipエントリがないと仮定します)?デコーダがzipファイルのマジックナンバーを順次スキャンしている場合、そのデータをデコードしてデータの実際の長さを判断すると、連続していないzipファイルはまだ互換性があるように見えます。唯一の注意点は、迷子なマジックナンバーがデコーダを混乱させるのを防ぐために、空きスペースをゼロにする必要があるということです。 –

+0

デコーダがマジックナンバーを検索していません。次に見られるのは、ローカルヘッダー、セントラルディレクトリヘッダー、またはエンドヘッダーのいずれかを示すマジックナンバーです。ゼロが表示されている場合は、無効なフォーマットエラーが発生してすぐに停止します。 –

+0

最後に、このrezippingを行うために私自身のObjective-Cライブラリを書きました。 zipエントリをスパースエントリとして扱いませんが、変更されていないzipエントリの書き込みはスキップします。したがって、最後のいくつかのエントリを常に変更している場合は、最初からすべてのエントリを書き換える必要はありません。 https://github.com/pixelglow/zipzap –

関連する問題