Diferencia entre E / S binario y de texto en python en Windows

Sé que debo abrir un archivo binario usando "rb" lugar de "r" porque Windows se comporta de manera diferente para archivos binarios y no binarios.

Pero no entiendo qué sucede exactamente si abro un archivo de forma incorrecta y por qué esta distinción es necesaria. Otros sistemas operativos parecen funcionar bien tratando ambos tipos de archivos de la misma manera.

Este modo es sobre la conversión de finales de línea.

Al leer en modo de texto, los finales de línea nativos de la plataforma ( \r\n en Windows) se convierten a finales de línea \n estilo de Unix de Python. Al escribir en modo texto, sucede lo contrario.

En modo binario, no se realiza tal conversión.

Otras plataformas normalmente funcionan bien sin la conversión, porque almacenan los finales de línea de forma nativa como \n . (Una excepción es Mac OS, que solía usar \r en los viejos tiempos). Sin embargo, el código que confía en esto no es portátil.

Bueno, esto es por razones históricas (o como me gusta decirlo, histéricas ). Los modos de apertura de archivos se heredan de la biblioteca C stdio y, por lo tanto, los seguimos.

Para Windows, no hay diferencia entre los archivos de texto y binarios, como en cualquiera de los clones de Unix. No, lo digo en serio! – hay (eran) sistemas de archivos / sistemas operativos en los que el archivo de texto es una bestia completamente diferente del archivo de objetos y así sucesivamente. En algunos, tenía que especificar la longitud máxima de líneas por adelantado y se utilizaron registros de tamaño fijo … fósiles de los tiempos de las tarjetas de perforación de papel de 80 columnas y similares. Por suerte, no es así en Unices, Windows y Mac.

Sin embargo, todas las demás cosas son iguales: Unix, Windows y Mac difieren históricamente en qué caracteres utilizan en el flujo de salida para marcar el final de una línea (o, lo mismo, como separador entre líneas). En Unix, se usa \ x0A (\ n). En Windows, se utiliza la secuencia de dos caracteres \ x0D \ x0A (\ r \ n); en Mac – sólo \ xOD (\ r). Aquí hay algunas pistas sobre el origen del uso de esos dos símbolos: el código ASCII 10 se llama Avance de línea (LF) y cuando se envía a teletipo, haría que se moviera hacia abajo una línea (Y ++), sin cambiar su posición horizontal (X) . Retorno de carro (CR) – ASCII 13 – por otro lado, causaría que el carro de impresión regrese al principio de la línea (X = 0) sin desplazarse una línea hacia abajo. Por lo tanto, al enviar la salida a la impresora, tanto \ r como \ n tuvieron que enviarse, de modo que el carro se moverá al comienzo de una nueva línea. Ahora, al escribir en el teclado del terminal, se espera que los operadores presionen una tecla y no dos para el final de la línea. Que en Apple] [fue la clave ‘Retorno’ (\ r).

En cualquier caso, así es como se arreglaron las cosas. Los creadores de C estaban preocupados por la portabilidad: gran parte de Unix estaba escrita en C, a diferencia de antes, cuando los sistemas operativos estaban escritos en ensamblador. Así que no querían lidiar con las peculiaridades de cada plataforma sobre la representación de texto, así que agregaron este truco malvado a su biblioteca de E / S según la plataforma, la entrada y salida de ese archivo se “parcharán” sobre la marcha para que la El progtwig verá las nuevas líneas de forma justa , de Unix, como ‘\ n’ – no importa si era ‘\ r \ n’ de Windows o ‘\ r’ de Mac. Por lo tanto, el desarrollador no debe preocuparse por el sistema operativo que ejecutó el progtwig, aún podría leer y escribir archivos de texto en formato nativo.

Sin embargo, hubo un problema: no todos los archivos son de texto, existen otros formatos y son muy sensibles para reemplazar un carácter por otro. Entonces, sin embargo, llamaremos a esos “archivos binarios” e indicaremos eso a fopen() al incluir ‘b’ en el modo, y esto marcará la biblioteca para que no realice ninguna conversión entre bambalinas. Y así es como llegó a ser como es 🙂

Entonces, para resumir, si el archivo está abierto con ‘b’ en modo binario, no se realizarán conversiones. Si estaba abierto en modo de texto, dependiendo de la plataforma, pueden ocurrir algunas conversiones de los nuevos caracteres de línea, hacia el punto de vista de Unix. Naturalmente, en la plataforma Unix no hay diferencia entre leer / escribir en “texto” o “binario”.

En Windows, el modo de texto convertirá la nueva línea \n en un retorno de carro seguido de una nueva línea \r\n .

Si lees texto en modo binario, no hay problemas. Si lee datos binarios en modo de texto, es probable que esté dañado.

Para leer archivos no debe haber diferencia. Al escribir en archivos de texto, Windows desordenará automáticamente sus saltos de línea (agregará los \r ‘s antes que los \n ‘ s). Por eso debes usar "wb" .