10

DataInput.skipBytes に関する Sunのドキュメントには、「入力ストリームから n バイトのデータをスキップしようとし、スキップされたバイトを破棄しようとします。しかし、それより少ない数のバイト、おそらくゼロをスキップする可能性があります。これは、次の結果として生じる可能性があります。 n バイトがスキップされる前にファイルの終わりに到達することは、1 つの可能性にすぎません。」

  1. ファイルの終わりに到達する以外にskipBytes()、正しいバイト数をスキップしないのはなぜですか? (DataInputStream私が使用している は、 aFileInputStreamまたは aのいずれかをラップしPipedInputStreamます。)

  2. 間違いなく n バイトをスキップしてEOFException、これによりファイルの最後に移動する場合にスローしたい場合readFully()、結果のバイト配列を使用して無視する必要がありますか? それとももっと良い方法がありますか？

4

5 に答える 5

5

1) 読み取ることができるデータがそれほど多くない可能性があり (パイプのもう一方の端がまだそれほど多くのデータを送信していない可能性があります)、実装クラスが非ブロッキングである可能性があります (つまり、要求を満たすのに十分なデータを待機しています)。

ただし、実際にこのように動作する実装があるかどうかはわかりませんが、インターフェイスはそれを許可するように設計されています。

もう 1 つのオプションは、読み取りの途中でファイルを閉じることです。

2) readFully() (常に十分な入力を待機するか、失敗する) か、ループ内で skipBytes() を呼び出します。配列が本当に広大でない限り、前者の方がおそらく優れていると思います。

于 2008-09-09T08:33:02.903 に答える
3

今日、この問題に遭遇しました。仮想マシン上のネットワーク接続を読み取っていたので、これにはいくつかの理由が考えられると思います. 必要なバイト数をスキップするまで、入力ストリームにバイトをスキップさせるだけで解決しました。

int byteOffsetX = someNumber; //n bytes to skip
int nSkipped = 0;

nSkipped = in.skipBytes(byteOffsetX);
while (nSkipped < byteOffsetX) {
    nSkipped = nSkipped + in.skipBytes(byteOffsetX - nSkipped);
}
于 2010-10-20T12:41:28.303 に答える
2

readFully() は、私が我慢した以上のパフォーマンス オーバーヘッドを追加することがわかりました。

最終的に妥協しました。skipBytes() を 1 回呼び出し、それが適切なバイト数よりも少ない数を返した場合は、残りのバイトに対して readFully() を呼び出します。

于 2008-09-09T13:08:43.990 に答える
1

Josh Bloch は最近これを公表しました。InputStream.read が可能な限り多くのバイトを読み取ることが保証されていないという点で一貫しています。しかし、API メソッドとしてはまったく意味がありません。InputStream にはおそらく readFully もあるはずです。

于 2008-09-09T11:08:00.397 に答える