用于BinaryReader的EndOfStream
BinaryReader没有EndOfStream属性。 使用以下代码检查是否到达流的末尾是否安全？
reader.BaseStream.Length>reader.BaseStream.Position
这取决于。 有各种流类型没有实现Length或Position属性，你会得到一个NotSupportedException。 例如NetworkStream。 当然，如果你使用这样的流，那么你真的必须事先知道调用BinaryReader.Read（）方法的频率。 所以，是的，没关系。
我找到的最简单的方法是检查BinaryReader的PeekChar（）方法的返回值。 如果它返回-1，那么您到达了流的末尾。
这不能作为一般解决方案，因为它假定BaseStream值支持Length属性。 许多Stream实现不会抛出NotSupportedException 。 特别是任何网络基本流，例如HttpRequestStream和NetworkStream
我注意到，即使底层BaseStream支持搜索，比较Position和Length也不适用于StreamReader。 似乎StreamReader缓冲了从BaseStream的预读。 这必须是StreamReader提供EndOfStream属性的原因，这是一件好事，我希望BinaryReader做同样的事情。
在底层基本流上检查这些值（长度和位置）会使BinaryReader计算为不像StreamReader那样，即依赖于BinaryReader仅从BaseStream中获取完成用户方法调用所需的确切字节数。 假设BinaryReader实际上在内部以这种方式运行，这就是为什么它不需要提供EndOfStream，但我确实希望它提供一个，以便我知道以独立于实现的方式为客户端正确处理文件末尾。
当然读者不是Streams，但是对于文件结束行为，如果有一个通用接口使输入/输出类的客户端能够知道文件的末尾是否是一个明智的概念，那将是很好的。如果A是合理的，则在文件结束时发生数据和B.
查看Streams CanSeek属性。 如果此属性返回true，则可以将流Length与流的位置进行比较，以判断您是否位于流的末尾。 如果此属性返回false，则此操作无效。
对于网络流，您可能需要区分可用字节的结尾（另一端的客户端仍有更多要写但尚未写入）并且流被关闭。 基础Tcp连接的IsConnected属性对于知道流何时关闭是不可靠的。 可以枚举计算机具有的连接，并查看您使用的流是否在其中。 这更可靠，但更复杂。 当你无法阅读任何内容时，最好只处理IOExceptions
这就是我过去一直在做的事情，我从来没有看到它的问题。 使用它的代码已经在生产环境中使用了2年多。