Diferencia entre '\ n' y '\ r \ n'

Sí sí, soy consciente de que '\n'escribe una nueva línea en UNIX, mientras que para Windows se encuentra la secuencia de dos caracteres: '\r\n'. Todo esto es muy bueno en teoría, pero mi pregunta es ¿por qué ? ¿Por qué el carácter de retorno de carro es adicional en Windows? Si UNIX puede hacerlo, \n¿ por qué se necesitan dos caracteres de Windows para hacer esto?

Estoy leyendo el libro de Python de David Beazley y él dice:

Por ejemplo, en Windows, escribir el carácter '\ n' en realidad genera la secuencia de dos caracteres '\ r \ n' (y al leer el archivo nuevamente, '\ r \ n' se traduce nuevamente en un solo '\ n' personaje).

¿Por qué el esfuerzo extra?

Voy a ser sincero. He sabido la diferencia por mucho tiempo pero nunca me he molestado en preguntar POR QUÉ. Espero que se responda hoy.

Gracias por tu tiempo.

Compatibilidad con versiones anteriores.

Windows es retrocompatible con MS-DOS (agresivamente, incluso) y MS-DOS usó la convención CR-LF porque MS-DOS era compatible con CP / M-80 (algo por accidente) que usaba la convención CR-LF porque eso fue cómo manejaste una impresora (porque las impresoras eran originalmente máquinas de escribir controladas por computadora).

Las impresoras tienen un comando separado para mover el papel una línea hacia arriba a una nueva línea, y un comando separado para devolver el carro (donde estaba montado el papel) de regreso al margen izquierdo.

Es por eso. Y sí, es una molestia, pero es parte del paquete que permitió que MS-DOS ganara a CP / M, y Windows 95 ganara a todas las otras GUI sobre DOS, y Windows XP a hacerse cargo. de Windows 98.

(Nota: las impresoras láser modernas todavía tienen estos comandos porque también son compatibles con versiones anteriores de impresoras anteriores, HP en particular lo hace bien)

Para aquellos que no están familiarizados con las máquinas de escribir, aquí hay un video que muestra cómo se escribió: http://www.youtube.com/watch?v=LJvGiU_UyEQ . Observe que el papel primero se mueve hacia arriba y luego se devuelve el carro, incluso si ocurre en un movimiento simple. El ding notificó al mecanógrafo que el final estaba cerca y que se preparara para ello.

Hasta donde sé, esto se remonta a los días de las máquinas de escribir.

\r es el retorno de carro, que es lo que se mueve donde está escribiendo en la página hacia la izquierda (o derecha si esa es su cultura)

\n es una nueva línea, que mueve su papel hacia arriba una línea.

Hacer solo uno de estos en una máquina de escribir lo colocaría en el lugar equivocado para comenzar a escribir una nueva línea de texto.

Cuando surgieron las computadoras, supongo que algunas personas conservaron el modelo anterior, pero otras se dieron cuenta de que no era necesario y encapsularon una nueva línea completa como un solo personaje.

No sé si esto es de conocimiento común, pero debe tenerse en cuenta que los emuladores de terminal modernos todavía entienden la RC:

$ printf "hey world\rsup\n"
sup world

Es útil para indicadores de progreso, p. Ej.

for i in {1..100}
do
    printf "\rLoading... %d%%" $i
    sleep 0.01
done
echo

Históricamente, el avance de línea significaba que la platina, el rodillo en el que escribía, giraba una línea, haciendo que el texto apareciera en la siguiente línea ... pero en la siguiente columna.

El retorno de carro significa "devolver el bit con el que escribe al principio de la línea".

Windows usa CR + LF porque MS-DOS lo hizo, porque CP / M lo hizo, porque tenía sentido para las líneas seriales.

Unix copió su \ n convención porque Multics lo hizo.

¡Sospecho que si profundizas lo suficiente, encontrarás un desacuerdo político entre los implementadores!

(Dejó de lado la parte extra de diversión, donde la convención Mac es (o solía ser) simplemente usar CR para separar líneas. ¡Y ahora Unicode también tiene su propio separador de línea, U + 2028!)

Historia del personaje de Newline (Wikipedia):

ASCII fue desarrollado simultáneamente por ISO y ASA, la organización predecesora de ANSI. Durante el período de 1963-1968, los proyectos de normas ISO respaldaron el uso de CR + LF o LF solo como una nueva línea, mientras que los borradores ASA solo admitieron CR + LF.

La secuencia CR + LF era de uso común en muchos sistemas informáticos tempranos que habían adoptado máquinas de teletipo, típicamente un ASR33, como dispositivo de consola, porque esta secuencia era necesaria para colocar esas impresoras al comienzo de una nueva línea. En estos sistemas, el texto a menudo se componía habitualmente para ser compatible con estas impresoras, ya que el concepto de controladores de dispositivos que ocultaban dichos detalles de hardware de la aplicación aún no estaba bien desarrollado; Las aplicaciones tenían que hablar directamente con la máquina de teletipo y seguir sus convenciones.

La separación de las dos funciones ocultaba el hecho de que el cabezal de impresión no podía regresar desde el extremo derecho al comienzo de la siguiente línea en el tiempo de un carácter. Es por eso que la secuencia siempre se envió primero con el CR. De hecho, a menudo era necesario enviar caracteres adicionales (CR o NUL extraños, que se ignoran) para dar tiempo al cabezal de impresión para moverse al margen izquierdo.

Incluso después de que los teletipos fueron reemplazados por terminales de computadora con velocidades de transmisión más altas, muchos sistemas operativos aún admitían el envío automático de estos caracteres de relleno, por compatibilidad con terminales más baratos que requerían tiempos de caracteres múltiples para desplazar la pantalla.

MS-DOS (1981) adoptó CR + LF de CP / M; El uso de CP / M de CR + LF tenía sentido para usar terminales de computadora a través de líneas seriales. Esta convención fue heredada por el posterior sistema operativo Windows de Microsoft.

El sistema operativo Multics comenzó a desarrollarse en 1964 y usó LF solo como su nueva línea. Unix siguió la práctica de Multics, y los sistemas posteriores siguieron a Unix.

¿Qué pasa con la gente preguntando "por qué Unix puede hacer \ny no Windows"? Es una pregunta tan extraña.

1. El sistema operativo no tiene casi nada que ver con eso. Es más una cuestión de cómo las aplicaciones, bibliotecas, protocolos y formatos de archivo manejan las cosas. Aparte de donde el sistema operativo lee / escribe la configuración basada en texto o los comandos de línea de comandos, no tiene sentido criticar el sistema operativo.
2. La mayoría de las aplicaciones de Windows pueden leer ambas \ny \r\nmuy bien. También salen \r\npara que todos estén contentos. Un programa no se limita a "hacer", ya sea \no \r\n- se acepta uno, el otro, o ambos, y salidas de uno, el otro o ambos.
3. Como programador, esto casi nunca debería molestarte. Prácticamente todos los idiomas / plataformas tienen facilidades para escribir la línea final correcta y leer con mayor solidez. La única vez que tuve que lidiar con el problema fue cuando escribí un servidor HTTP , y fue porque cierto navegador (pista: el siguiente navegador más popular después de IE) estaba funcionando en \nlugar del correcto \r\n .
4. Una pregunta mucho más pertinente es, ¿por qué tantas aplicaciones modernas de Unix salen solo \nsabiendo que hay algunos protocolos y programas que no les gustan?

La razón por la cual las convenciones se mantienen en sus diversos sistemas (\ n en sistemas de tipo unix, \ r \ n en Windows, etc.) es que una vez que ha elegido una convención, NO PUEDE cambiarla sin romper un montón de archivos de personas. Y eso generalmente está mal visto.

Los sistemas de tipo Unix se desarrollaron (en los primeros días) utilizando varios modelos de teletipo, y en algún momento alguien decidió que el equipo debería devolver el carro cuando realizaba un avance de línea.

Windows vino de DOS, así que para Windows la pregunta realmente es: ¿Por qué DOS usó esta secuencia cr / lf? Supongo que tiene algo que ver con CP / M, donde DOS tiene algunas de sus raíces. Una vez más, los modelos específicos de teletipo pueden haber jugado un papel.

Aquí hay una respuesta de la mejor fuente: Microsoft. ¿Por qué el terminador de línea CR + LF?

Este protocolo se remonta a los días de los teletipos. CR significa "retorno de carro": el carácter de control CR devolvió el cabezal de impresión ("carro") a la columna 0 sin avanzar el papel. LF significa "salto de línea": el carácter de control de LF avanzó el papel una línea sin mover el cabezal de impresión. Entonces, si desea devolver el cabezal de impresión a la columna cero (listo para imprimir la siguiente línea) y avanzar el papel (para que se imprima en papel nuevo), necesita CR y LF.

Si va a varios documentos de protocolo de Internet, como RFC 0821 (SMTP), RFC 1939 (POP), RFC 2060 (IMAP) o RFC 2616 (HTTP), verá que todos especifican CR + LF como secuencia de terminación de línea. Entonces, la verdadera pregunta no es "¿Por qué CP / M, MS-DOS y Win32 usan CR + LF como terminador de línea?" sino "¿Por qué otras personas optaron por diferir de estos documentos estándar y utilizar algún otro terminador de línea?"

Unix adoptó LF simple como la secuencia de terminación de línea. Si observa las opciones stty, verá que la opción onlcr especifica si un LF debe cambiarse a CR + LF. Si se equivoca esta configuración, aparece el texto de la escalera, donde

each
    line
        begins

donde dejó la línea anterior. Entonces, incluso Unix, cuando se deja en modo sin procesar, requiere CR + LF para terminar las líneas. El CR implícito antes de LF es una invención de Unix, probablemente como una economía, ya que ahorra un byte por línea.

La ascendencia de Unix del lenguaje C llevó esta convención al estándar del lenguaje C, que requiere solo "\ n" (que codifica LF) para terminar las líneas, poniendo la carga en las bibliotecas de tiempo de ejecución para convertir datos de archivos sin procesar en líneas lógicas.

El lenguaje C también introdujo el término "nueva línea" para expresar el concepto de "terminador de línea genérico". Me dijeron que el comité ASCII cambió el nombre del personaje 0x0A a "nueva línea" alrededor de 1996, por lo que el nivel de confusión se ha elevado aún más.