問題タブ [gzipinputstream]

gzip されたデータをチャンクごとにダウンロードして、ファイルに追加する必要があります。問題は、HTTP conn から読み取るときに、圧縮されたバイト配列の合計を一度に送信していないことです (ストリーム)。私のアプリケーションは、以前に送信されたバイト配列の残りのバイトで Gzip ヘッダーを探しています。http にバイト配列の圧縮されたインスタンスを一度に送信させるにはどうすればよいですか。これは、データを圧縮してファイルに追加するコード スニペットです。

解凍機能：-

GZIP には 4GB のサイズ制限があります。http: //www.gzip.org/#faq10 から入手 できます。上記のリンクには、4GB を超えるファイルを読み取れるようにするためのパッチがいくつか記載されています。

GZIPInputStream を使用して .gz ファイルを読み込んでいます。

また、4GBを超えるサイズも読み取ることができます。Java の入力ストリームと実際の gzip 実行可能ファイルを混同していることはわかっています。

しかし、それが問題になる可能性があるかどうかを知りたいですか？

たとえば、Java で 6Gb の .gz ファイルを読み取れない場合はありますか? 今まで試してみましたが、問題はありませんでした。

つまり、gzip ファイルのサイズ制限と Java の gzipinputstream の間に関係はありますか?

バッファの一部をGzipInputStreamゼロで埋める奇妙なプログラムがあります。ストリーム内のバイトがどのように表示されるかを知ることができ、バッファが8つの正しいバイトと12のゼロ（ゼロであってはならない）で満たされていることがわかります。

バイトはこのように見える必要があります---->020 82 22 -91 27 -96 65 66 65 88 32 32 32 32 81 32 0 0 0100 78

BYTESは実際にこのように見えます--->020 82 22 -91 27 -96 65 66 65 0 0 0 0 0 0 0 0 0 0 0 0

最初の2バイトは、最初の2バイトの後の可変長（バイト単位）ペイロードのサイズを決定する整数を表します。したがって、この例では、最初のバイトは0 20であり、BIG_ENDIANでは、これにより、後続のペイロードサイズが20バイトになります。

これが私の読むためのコードです

したがって、最初の2バイトはペイロード配列のバイトであり、次の20バイトはmessageBytesのバイトです。理解できない

NPEのおかげで変更されたコード

次の Java コードを使用して、文字列を圧縮および圧縮解除しようとしています。しかし、新しい ByteArrayInputStream オブジェクトから新しい GZipInputStream オブジェクトを作成する行は、「java.util.zip.ZipException: Not in GZIP format」例外をスローします。これを解決する方法を知っている人はいますか？

次のjsonをtcp経由でgraylogサーバーに書き込もうとしています:

以下は、実際に gzip で圧縮され、ネットワーク経由で転送されるバイトです。

そして、graylog サーバーは次の例外をスローします。

UDP ポートに書き込まれたときとまったく同じメッセージが通過します。

ワイヤ上にバイトを書き込む C# コード スニペット:

ヒント/提案は本当に感謝しています。

Graylog ジラリンク. Github の問題リンク。

コードで

、解凍されたファイルの長さを知ることで、ディスク容量の使用を最適化し、大きなバイト[]を作成しないようにするにはどうすればよいですか?

この回答によると、そのような方法はありません。

アイデアは、このバイト[]を呼び出しに使用することです

このため、すべてのコンテンツを含み、余分なゼロがない bytye[] が必要です。

ほとんどの場合、うまく機能するアプリがあります。

特に、レンダリングのためにデータを送信するときにサーバーとクライアント間の圧縮 (gzip) をオフにすると、常に機能します。

gzip をオン (優先モード) にすると、次のようにストリームの圧縮解除に失敗することがあります。

double>> を取得する最後に注意してください。

いくつかのクエリ応答で動作を再現できますが、すべてではなく、すべての環境で再現できるわけではありません。

Firefox と Java の両方が同じ方法でストリームを復号化しているため、ストリームを圧縮しているサーバー側に問題が絞り込まれたとGZIPInputStream考えています (Firefox は を使用していないと思いますGZIPInputStream) 。

これをさらにデバッグする方法に関するヒントはありますか? の既知のバグはありGZIPますか?

何かありがとう。

URL から gzip 圧縮された XML ファイルを取得しようとしています。私の問題は、本番環境で解凍すると、GZipInputStream取得したコンテンツが切り捨てられているように見えることです。xml の比較的小さな部分までしか読み取ることができません。

このコードは、常に xml のごく一部のみを読み取ります。複数回実行すると、まったく同じ結果が表示されます。配列のサイズは、ダウンロードByteArrayOutputStream.したファイルとまったく同じです。ただし、GZipInputStreamバイト配列を解凍するために使用すると、同じ切り捨てられた文字列が得られます。

ちなみに、すべてがローカルで正常に動作するので、GZipInputStream何らかの理由でGAE. これを回避する方法を知っている人はいますか?

公開の匿名 FTP からファイルを読み込もうとしていますが、問題が発生しています。プレーン テキスト ファイルは問題なく読み取ることができますが、gzip ファイルを読み取ろうとすると、次の例外が発生します。

ファイルをダウンロードしてFileInputStreamラップされたを使用してみましたGZIPInputStreamが、まったく同じ問題が発生したため、FTP クライアント (Apache) の問題ではないと思います。

問題を再現するテスト コードを次に示します。標準出力に出力しようとしているだけです：

なぜこれが起こるのかについてのドキュメントを見つけることができず、デバッガーでコードをたどってもどこにも行きません。明らかな何かが欠けているように感じます。

編集: ファイルを手動でダウンロードし、GZIPInputStream で読み込んで、問題なく印刷できました。2つの異なるJava FTPクライアントでこれを試しました

私は、一部のシステム間のやり取りのために GZIP 圧縮を実装する作業を行っています。システムは Java と C# の両方で記述されているため、標準ライブラリがサポートされているため、両方で GZIP ストリームが使用されました。

C# 側では、最大のテスト ファイル (圧縮されていない 70 MB) まですべてが機能しますが、Java でヒープ スペースが不足するという問題が発生します。IDE の容量までヒープ サイズを増やしてみましたが、問題はまだ解決されていません。

Java コードを最適化するためにいくつかの手順を実行しましたが、データがヒープに積み重なるのを防ぐ方法はないようです。これを処理する良い方法はありますか？以下は、現在の (より小さなストリームで作業している) ソリューションのサブセットです。

編集: @MarkoTopolnik からの推奨事項で変更された次のコード。変更により、クラッシュする前に 1,700 万文字が読み取られます。

で 760 万文字を少し超えるとコードが停止しArrayList、スタック トレースはArrayList.add()呼び出しが原因であることを示します (内部配列の展開をトリガーした後に失敗します)。

上記の編集されたコードでは、 への呼び出しがAbstractStringBuilder.expandCapacity()プログラムを強制終了します。

圧縮解除されたストリームから文字列を取得するために使用できる動的配列またはまったく異なるアプローチを実装するためのメモリ消費量の少ない方法はありますか? どんな提案でも大歓迎です！