EndOfStream for BinaryReader

Question

BinaryReader no tiene la propiedad EndOfStream. ¿Es seguro usar el siguiente código para verificar si se llega al final del flujo?

reader.BaseStream.Length>reader.BaseStream.Position

Answer 1

Depende. Hay varios tipos de flujo que no implementan la propiedad Longitud o Posición, obtendría una NotSupportedException. NetworkStream por ejemplo. Por supuesto, si usa una secuencia de este tipo, realmente debe saber con anticipación la frecuencia con la que llama al método BinaryReader.Read(). Entonces, sí, está bien.

Answer 2

Eso es lo que siempre he hecho en el pasado y nunca he visto un problema con él. El código que lo usa ha estado en un entorno de producción por más de 2 años.

Answer 3

Esto no funcionará como una solución general porque asume que el valor BaseStream admite la propiedad Length. La implementación de muchos Stream no lo hace y en su lugar arrojar un NotSupportedException. En particular, cualquier flujo base de red como HttpRequestStream y NetworkStream

Answer 4

La manera más fácil que encontré es verificar el valor devuelto del método PeekChar() del BinaryReader. Si devuelve -1, llegaste al final de la transmisión.

Answer 5

Me he dado cuenta de que la comparación de la posición con la longitud NO funciona en StreamReader, incluso si el BaseStream subyacente admite la búsqueda. Parece que StreamReader almacena la lectura anticipada de BaseStream. Este debe ser el motivo por el que StreamReader proporciona una propiedad EndOfStream, lo cual es algo bueno, y desearía que BinaryReader hiciera lo mismo.

Comprobación de estos valores (longitud y posición) sobre los recuentos de subyacentes flujo base en BinaryReader a no comportarse como lo hace StreamReader, es decir, se basa en BinaryReader solamente agarrando el número exacto de bytes de BaseStream necesario para cumplir con una llamada de método usuario. Es de suponer que si BinaryReader funciona de esta manera internamente, es por eso que no necesita suministrar un EndOfStream, pero ciertamente desearía que fuera uno para que supiera que el final del archivo se manejaba correctamente para los clientes de una manera independiente de la implementación.

Por supuesto, los lectores no son flujos, pero con respecto al comportamiento del final del archivo sería bueno si hubiera una interfaz común que permitiera a los clientes de clases de entrada/salida saber si A. fin de archivo es un concepto sensato para la fuente de datos subyacente, y B. cuando finaliza el archivo si A es sensato.

Answer 6

Compruebe la propiedad Streams CanSeek. Si esta propiedad devuelve verdadero, puede comparar la Longitud de las secuencias con la Posición de la secuencia para saber si se encuentra al final de la secuencia. Si esta propiedad devuelve falso, esto no funcionará.

Para las transmisiones de red puede necesitar distinguir entre el final de los bytes disponibles (el cliente en el otro extremo tiene aún más por escribir pero aún no) y la secuencia se está cerrando. La propiedad IsConnected para una conexión Tcp subyacente no es confiable para saber cuándo se cerró la transmisión. Es posible enumerar las conexiones que tiene la computadora y ver si la transmisión que está utilizando está entre ellas. Esto es más confiable, pero más complejo. Puede ser mejor manejar IOExceptions cuando no puede leer