問題タブ [deflatestream]

zlib deflate 圧縮ストリームが必要です。私の実装では、セッション全体で単一のストリームを使用する必要があります。このセッション中に、データの小さなチャンクが圧縮ストリームを介して渡されます。チャンクが渡されるたびに、すぐに圧縮形式で送信する必要があります。

私の最初の試みは DeflateStream を使用していましたが、最初のチャンクを送信すると、ストリームを閉じるまで圧縮データが表示されません。

zlib フラッシュ モードについて読むと、必要なものに対して特定のモードが 1 つあるように見えます。

1. zlib deflate 圧縮に正しいクラス (DeflateStream) を使用していますか?
2. 「同期フラッシュ」動作を有効にするにはどうすればよいですか?

オブジェクトのカスタムのシリアル化/逆シリアル化を行い、シリアル化されたデータを DeflateStreams で圧縮/解凍しようとしています。私は元々、より複雑なオブジェクトに対してこれを行っていましたが、問題を解決するために削減しましたが、まだそこにあるため、より不可解になりました。シリアライズ/デシリアライズするクラスは次のとおりです。

そして、これをシリアル化することになっているコードがあります(動作しているようです):

そして、ここに逆シリアル化があります：

さて、問題に。デシリアライゼーションは、{"オブジェクト '201326592' のマップがありません。"} というメッセージとともに SerializationException をスローします。トラブルシューティングの方法や、問題の原因を正確に突き止める方法がわかりません。BinaryFormatter の Serialize メソッドと Deserialize メソッドを同じ MemoryStream で実行すると、非常に基本的なシリアル化が機能します。

両方のメソッドから DeflateStream のものを削除しようとしましたが、それでも同じ問題です。MSDN や他の場所の例を見ると、私はそれを正しく行っているように見え、例外メッセージをグーグルで調べても意味のある結果が得られません (または、検索が下手なだけかもしれません)。

PS。ご覧のとおり、 src.CopyTo(dest) をまったく機能させることができないため、基本的なストリームコピーである Miscellaneous.CopyStream(src, dest) を使用しているため、そのヒントも歓迎します。

以下は、VS2010 プロジェクト全体へのリンクです。詳しく調べたい場合は、 http ://www.diredumplings.com/SerializationTesting.zip を参照してください。

アップデート：

The_Smallest : シリアライゼーションに投稿した Compress メソッドを使用してみました:

ただし、以前に srcStream.CopyTo(destStream) で発生したのと同じ問題が発生するようです。つまり、ストリームに書き込まれないようです。ディスクに保存しようとすると、結果は 0 kb のファイルになります。何か案は？

Pieter : デシリアライズ メソッドから MemoryStream を削除しましたが、以前と同じ機能を持っているようです。ただし、あなたが提案した方法でシリアル化を実装する方法がわかりません。これはあなたが考えていたことですか？

お二人ともありがとう！

私は WPF アプリを開発しています。このアプリでは、重い DataSet またはオブジェクト (<2MB) を暗号化および圧縮し、ネットワーク経由で送信します。相手はデータを解凍して復号化し、それを消費します。このプロセスは、サーバー (WCF) からクライアントへ、およびクライアントからサーバーへの両側で行われます。

1. 効率的な圧縮クラスが必要です (.Net 圧縮クラスに固執したい)。
   
2. 圧縮と解凍にかかる時間が短縮されます。
   
3. 圧縮率が高く、データの取得は 100% である必要があります。

圧縮クラス (DeflateStream/GzipStream) について教えてください。

ありがとう
VJ

私はデータ（たまたまadCenterレポート）を読んでいますが、これは圧縮されているはずです。通常のストリームでコンテンツを読むと、数千バイトのジブリッシュが発生するので、これは妥当なようです。そこで、ストリームをDeflateStreamにフィードします。

まず、「ブロック長がその補数と一致しない」と報告します。簡単に検索すると、2バイトのプレフィックスがあることがわかります。実際、DeflateStreamを開く前にReadByte（）を2回呼び出すと、例外はなくなります。

ただし、DeflateStreamは何も返さないようになりました。私は午後のほとんどをこれについてリードを追いかけて過ごしましたが、運がありませんでした。私を助けてください、StackOverflow、あなたは私の唯一の希望です！誰かが私が欠けているものを教えてもらえますか？

これがコードです。当然、テスト時に一度に2つのコメント付きブロックのうち1つだけを有効にしました。

最後の行から推測できるように、解凍されたコンテンツはTDTである必要があります。

楽しみのために、GZipStreamで解凍しようとしましたが、マジックナンバーが正しくないことが報告されています。MSのドキュメントには、「ダウンロードしたレポートはzip圧縮を使用して圧縮されています。レポートの内容を使用するには、レポートを解凍する必要があります」と書かれています。

これが最終的に機能したコードです。コンテンツをファイルに保存して読み直す必要がありました。これは合理的ではないようですが、使用している少量のデータについては、許容範囲内です。

組み込みの .net 4.0 Gzip および Deflate クラスを使用して、プログラムで 3GB (7GB 非圧縮) の gzip ファイルを解凍するのに問題があります。

私の理解では、どちらも 4GB を超えるファイルをサポートする必要がありますが、機能していないようです。問題のファイルを WinRAR で手動で解凍し、基になる csv ファイルをストリーム リーダーでストリーミングし、行数をカウントすると、約 7500 万行という期待される結果が得られます。ただし、GzipStream または DeflateStream を使用してこれを行うと、ストリーム リーダーは途中で停止し (4GB マーク付近)、「ストリームの終わり」を報告し、エラーなしで終了します。これらのリーダーを使用すると、ストリームが終了するまでに約 3,400 万行に到達するだけです。

次に、.net zip http://dotnetzip.codeplex.com/の最新のバイナリを試してみました が、途中でエラーが発生しました。「宛先配列の長さが不十分です。destIndex と長さ、および配列の下限を確認してください。」

私はこのファイルを作成しませんでしたが、同じソースからの小さなファイルで問題が発生したことはありません。そのため、サイズに関する何かが問題の原因であると思われます。このファイルの作成に使用されたツールが 64 ビットに準拠していない可能性がありますが、作成者にバグを報告する前に、バグが gzip 抽出ロジックで私たちの側にないことを確認したいと思います。

どんな考えでも大歓迎です。以下の抽出コードとテスト方法の例:

抽出できない大きな (重要な) ファイルを含む Zip アーカイブがあります。壊れた Zip アーカイブを回復/修正すると主張するものを含め、私が試したすべての Zip ユーティリティは、破損した zlib 圧縮データを含むファイルを抽出できません。スキップされる破損したエントリを除いて、アーカイブ内のすべてのファイルを取得します。

Zip アーカイブを解析し、各エントリを識別してフィールドを解析し、データ セクションを復号化し、(zlib の .Net 実装から) DeflateStream を使用してそれらを解凍する小さなユーティリティ アプリを C# で作成しました。破損したエントリに到達するまで、すべてが正常に機能します。破損したエントリは (CTR モードで AES を使用して) 正常かつ完全に復号化されますが、DeflateStream リーダーは、「Bad state (oversubscribed dynamic bit lengths tree)」をスローする前に、復号化されたデータに約 40MB しか到達できません。

どうにかして破損したセクションを「シーク」し、データの解凍を続けることは可能ですか? いくつかの穴があっても、できるだけ多くのファイルを回復したいと考えています。DeflateStream は Seek メソッドを実装していません。基になる FileStream を最後の読み取り位置に配置して新しい DeflateStream を作成しようとすると、同じ「Bad State」例外がスローされます。

DeflateStreamで問題が発生しました。一部のデータは、最後まで繰り返し書き込まれています。

コードは次のとおりです。

これをどのように説明できますか？

http://i.stack.imgur.com/d2ffF.png

アップデート

Ionic.Zlib.ZlibStreamとIonic.Zlib.DeflateStreamを試してみましたが、同じ奇妙な結果が得られました。

まず、オブジェクトを圧縮するには、オブジェクトを純粋にバイナリ形式で表現するよりも多くのバイトが必要であることに気付きました。(228 対 166)。

第二に、私はそれを解凍できないようです。

また、バージョン 4 の .NET フレームワークを持っていないため、便利な CopyTo 機能を使用できません。

ブロックを使用して最後の DeflateStream に何を入れる必要がありますか?

私は DeflateStream の内部に精通していませんが、バイナリ添付ファイルで DeflateStream を使用するベンダーの DB システムにファイルを保存する必要があります。私が最初に気付いたのは、すべてのファイルが圧縮後に 10 ～ 50% 大きくなったことですが、これは、高度に圧縮されたファイル (この場合はすべて PDF) に加えて、あまり洗練されていない圧縮アルゴリズムが原因であると考えています。ただし、私の質問は、元のファイルを BLOB に書き込んだときに、ベンダーのアプリケーションで問題なく開くことができたという事実に関連しています (deflate で圧縮した添付ファイルも開きました)。データが圧縮されていないことを DeflateStream に伝え、基本的にそのまま渡すヘッダーが圧縮データにありますか? これ仕様です。それに精通している人は、これが定義されている場所を指摘できますか?それとも、私がベースから外れていて、ベンダーが舞台裏で魔法をかけているのでしょうか?

画像ファイルを圧縮してネットワーク経由で送信しようとしています。これが私のテスト圧縮方法です。

結果は

375531

354450

少なくとも圧縮するときは、6桁ではなく5桁にする必要があると思いましたが、これは正常ですか？私はそれを正しくやっていますか？

前もって感謝します