Desde las páginas de MSDN para StreamWriter y BinaryWriter , puede ver claramente las diferencias:
Escritor de flujo:
Implementa un TextWriter para escribir caracteres en una secuencia en una codificación particular.
Y:
Escritura binaria:
Escribe tipos primitivos en binario en una secuencia y admite la escritura de cadenas en una codificación específica.
Sé que la característica más importante de BinaryWriter es que puede escribir tipos primitivos en binario, lo que puede ser más compacto y eficiente (considere escribir el número entero 23861398: el escritor binario requeriría 4 bytes, pero el escritor de flujo requeriría 8, 16 , o incluso 32 dependiendo de la codificación).
Pero cuando se trata de escribir cadenas, ¿podemos decir que StreamWriter y BinaryWriter son intercambiables?
De la documentación de BinaryWriter :
Escribe una cadena con prefijo de longitud en esta secuencia en la codificación actual de BinaryWriter y avanza la posición actual de la secuencia de acuerdo con la codificación utilizada y los caracteres específicos que se escriben en la secuencia.
y:
Con prefijo de longitud significa que este método primero escribe la longitud de la cadena, en bytes, cuando se codifica con la codificación actual de la instancia de BinaryWriter en la transmisión. Este valor se escribe como un entero sin signo. Este método luego escribe esa cantidad de bytes en la secuencia.
Por ejemplo, la cadena "A" tiene una longitud de 1, pero cuando se codifica con UTF-16; la longitud es de 2 bytes, por lo que el valor escrito en el prefijo es 2 y se escriben 3 bytes en la secuencia, incluido el prefijo.
La clase StreamWriter no escribe longitudes de cadena en la salida. Simplemente escribe el texto en sí
Ambos respetan la codificación que especificó cuando creó el objeto. El texto real que se escribe usa esa codificación.
Entonces, dependiendo de lo que quiera decir con "intercambiables" , lo son o no lo son. Diría que no lo son , pero si todo lo que está viendo es la secuencia de bytes que representa el texto escrito en sí mismo, uno podría considerar que lo son.
Para abordar su comentario:
Soy nuevo en BinaryWriter, entonces, ¿por qué necesito escribir primero la longitud en la transmisión? ¿Por qué no simplemente escribir "datos reales" directamente?
A diferencia de StreamWriter , que solo escribe un tipo de datos, BinaryWriter puede escribir todo tipo de datos, incluidos bytes sin formato y varios tipos primitivos, en un solo Stream . Al escribir cada uno de estos, necesita una forma de indicar dónde termina esa sección particular de datos. Eso es para que la contraparte de lectura de BinaryWriter , BinaryReader , tenga una forma de saber dónde termina cada sección de datos.
Para algunas cosas, es simple, porque el elemento de datos en sí tiene un tamaño fijo. Un System.Int32 tiene 4 bytes, un System.Int64 tiene 8, y así sucesivamente. Son de longitud fija, por lo que al leer solo lee la cantidad esperada de bytes.
Pero los objetos string son de longitud variable. Hay dos enfoques comunes para manejar esto: prefijar la cadena con un conteo o terminar la cadena con un carácter nulo ( '\0' ). Las cadenas .NET en memoria se cuentan, no terminan en nulo, por lo que los objetos de cadena pueden contener un carácter nulo, por lo que la terminación en nulo de la cadena no funciona para almacenar una cadena en un archivo.
Entonces, en su lugar, se usa el prefijo con el recuento de bytes.
No, absolutamente no son intercambiables. BinaryWriter es una herramienta IO básica obstinada para escribir en salidas binarias; StreamWriter es para escribir salidas de texto. Cada vez que la salida se ve similar es puramente incidental: no deben usarse de manera intercambiable.
Para las cadenas, se verán similares, pero eso es simplemente porque, en última instancia, ambos solo usan una codificación de texto. Sin embargo, el modelo a su alrededor es muy diferente (con el BinaryWriter usando el prefijo de longitud, etc.).
Si estás buscando usar uno como si fuera el otro: probablemente estés haciendo algo muy mal. Si aclara lo que está tratando de hacer, probablemente podamos ofrecerle orientación.