DBに保存されているgzipデータを持っています。たとえば、50個の個別のgzip圧縮されたデータを非圧縮可能な1つのgzip圧縮された出力に連結する方法はありますか?結果は、その50個のアイテムを解凍し、連結してからgzipするのと同じになります。
減圧段階は避けたいです。バイト配列全体をgzipする代わりに、すでにgzipされたデータをマージすることによるパフォーマンス上の利点もありますか?
DBに保存されているgzipデータを持っています。たとえば、50個の個別のgzip圧縮されたデータを非圧縮可能な1つのgzip圧縮された出力に連結する方法はありますか?結果は、その50個のアイテムを解凍し、連結してからgzipするのと同じになります。
減圧段階は避けたいです。バイト配列全体をgzipする代わりに、すでにgzipされたデータをマージすることによるパフォーマンス上の利点もありますか?
zipアルゴリズムはファイルごとの特定のコンテンツに対して実行されているため、zip形式のファイルを連結するだけでは悲惨な結果になると思います。すべてを手動で解凍し、連結してから、もう一度圧縮する必要があると思います。
はい、gzipストリームを連結できます。これにより、解凍すると、非圧縮データを連結して一度にgzip圧縮した場合と同じようになります。具体的には:
gzip a
gzip b
cat a.gz b.gz > c.gz
gunzip c.gz
あなたに同じものを与えるでしょうc
:
cat a b > c
ただし、特に50個のピースのそれぞれが小さい場合(たとえば、数十Kバイト未満の場合)、全体を一度に圧縮する場合と比較して、圧縮率は低下します。圧縮された結果は常に異なり、ピースのサイズに応じて少しまたはかなり大きくなります。
GZIPStreamに関する別の回答のコメントに注意する必要があります。また、代わりにDotNetZipを使用することをお勧めします。
GZipにはバグがあり、さらに複数のgzipメンバーを持つgzipファイルの解凍にはバグがあります....net4.5でもすべてのgzipバグが解決されているわけではありません。
さらに、各gzipが作成されたマシン、つまりBGZFの「BlockedGNUZipFormat」を検討してください。これは当面の問題を複雑にします。
さらに、結果のgzipファイルは、圧縮されていない個々のファイルをすべて連結した場合よりも大きくなる可能性があります(gzipは非常に優れた圧縮アルゴリズムセットではありません)。
手遅れでない場合は、代わりにDotNetZipを使用することをお勧めします。
GZipStreamは実際には複数のファイルを処理するように構築されていませんが、System.IO.BinaryWriterとSystem.IO.BinaryReaderを使用して完全な制御を取得できますが、面倒になる可能性があります。DotNetZipはうまく機能します!複数のファイルを処理するように設計されています。
PS GZipStreamは、.Net4で最大8GBのファイルサイズで動作しますが、以前のバージョンには下限があります。たとえば、GZipStreamは.Net3.5で最大4GBのファイルサイズで動作します。