BinaryReaderにはEndOfStreamプロパティがありません。次のコードを使用して、ストリームの終わりに到達したかどうかを確認しても安全ですか?
reader.BaseStream.Length>reader.BaseStream.Position
BinaryReaderにはEndOfStreamプロパティがありません。次のコードを使用して、ストリームの終わりに到達したかどうかを確認しても安全ですか?
reader.BaseStream.Length>reader.BaseStream.Position
私が見つけた最も簡単な方法は、BinaryReaderのPeekChar()メソッドの戻り値を確認することです。-1が返される場合は、ストリームの最後に到達しています。
場合によります。LengthまたはPositionプロパティを実装しないさまざまなストリームタイプがあり、NotSupportedExceptionが発生します。たとえば、NetworkStream。もちろん、そのようなストリームを使用する場合は、BinaryReader.Read()メソッドを呼び出す頻度を事前に知っておく必要があります。だから、はい、それは大丈夫です。
これは、値がプロパティBaseStream
をサポートしていることを前提としているため、一般的な解決策としては機能しません。Length
多くのStream
実装はそうではなく、代わりにをスローしNotSupportedException
ます。特に、HttpRequestStream
およびなどのネットワークベースストリームNetworkStream
基になるBaseStreamがシークをサポートしている場合でも、位置と長さの比較はStreamReaderでは機能しないことに気付きました。StreamReaderはBaseStreamからの先読みをバッファリングしているようです。これが、StreamReaderがEndOfStreamプロパティを提供する理由であるに違いありません。これは良いことであり、BinaryReaderが同じことをしたいと思います。
基になるベースストリームでこれらの値(長さと位置)をチェックすると、BinaryReaderはStreamReaderのように動作しないと見なされます。つまり、BinaryReaderは、ユーザーメソッド呼び出しを実行するために必要なBaseStreamから正確なバイト数のみを取得することに依存します。おそらく、BinaryReaderが実際に内部でこのように動作する場合、EndOfStreamを提供する必要がないのはそのためですが、実装に依存しない方法でファイルの終わりがクライアントに対して正しく処理されていることを確認できるように、提供したいと思います。
もちろん、リーダーはストリームではありませんが、ファイルの終わりの動作に関しては、入出力クラスのクライアントがA.ファイルの終わりが基になるソースの適切な概念であるかどうかを知ることができる共通のインターフェイスがあれば便利です。データ、およびB.Aが適切である場合にファイルの終わりが発生したとき。
StreamsCanSeekプロパティを確認してください。このプロパティがtrueを返す場合は、ストリームの長さとストリームの位置を比較して、ストリームの最後にいるかどうかを確認できます。このプロパティがfalseを返す場合、これは機能しません。
ネットワークストリームの場合、使用可能なバイトの終わり(もう一方の端のクライアントにはまだ書き込みが必要ですが、まだ書き込みが行われていません)と閉じられているストリームを区別する必要がある場合があります。基になるTcp接続のIsConnectedプロパティは、ストリームがいつ閉じられたかを知るために信頼できません。コンピュータが持っている接続を列挙し、使用しているストリームがそれらの中にあるかどうかを確認することができます。これはより信頼性がありますが、より複雑です。何も読めない場合は、IOExceptionを処理する方がよい場合があります