Los conceptos de retorno de carro (CR) y salto de línea (LF) están estrechamente asociados y pueden considerarse por separado o juntos. En los medios físicos de las máquinas de escribir y las impresoras, se necesitan dos ejes de movimiento, «hacia abajo» y «a través», para crear una nueva línea en la página. Aunque el diseño de una máquina (máquina de escribir o impresora) debe considerarlos por separado, la lógica abstracta del software puede combinarlos en un solo evento. Por eso, una nueva línea en la codificación de caracteres se puede definir como CR y LF combinados en uno (comúnmente llamado CR + LF o CRLF ).

Algunos los juegos de caracteres proporcionan un código de carácter de nueva línea independiente. EBCDIC, por ejemplo, proporciona un código de carácter NL además de los códigos CR y LF. Unicode, además de proporcionar los códigos de control ASCII CR y LF, también proporciona un código de control de «línea siguiente» (NEL), así como códigos de control para marcadores de «separador de línea» y «separador de párrafo».

• Los sistemas EBCDIC, principalmente los sistemas mainframe de IBM, incluidos z / OS (OS / 390) e i5 / OS (OS / 400), utilizan NL (Nueva línea, 0x15) como el carácter que combina las funciones de avance de línea y carro. regreso. El carácter Unicode equivalente ( 0x85 ) se llama NEL (línea siguiente). EBCDIC también tiene caracteres de control llamados CR y LF, pero el valor numérico de LF (0x25) difiere del utilizado por ASCII (0x0A). Además, algunas variantes de EBCDIC también usan NL pero asignan un código numérico diferente al carácter. Sin embargo, esos sistemas operativos utilizan un sistema de archivos basado en registros, que almacena archivos de texto como un registro por línea. En la mayoría de los formatos de archivo, no se almacenan terminadores de línea.
• Los sistemas operativos de la serie CDC 6000 definieron una nueva línea como dos o más caracteres de seis bits con valor cero al final de una palabra de 60 bits. Algunas configuraciones también definieron un carácter de valor cero como un carácter de dos puntos, con el resultado de que varios dos puntos podrían interpretarse como una nueva línea según la posición.
• RSX-11 y OpenVMS también utilizan un sistema de archivos basado en registros , que almacena archivos de texto como un registro por línea. En la mayoría de los formatos de archivo, no se almacenan terminadores de línea, pero la función de Servicios de administración de registros puede agregar de manera transparente un terminador a cada línea cuando es recuperado por una aplicación. Los registros en sí podrían contener los mismos caracteres de terminación de línea, lo que podría considerarse una característica o una molestia según la aplicación. RMS no solo almacenó registros, sino que también almacenó metadatos sobre los separadores de registros en diferentes bits para que el archivo complicara aún más las cosas (dado que los archivos podían tener registros de longitud fija, registros que tenían como prefijo un recuento o registros que terminaban con un carácter específico ). Los bits no eran genéricos, por lo que si bien podían especificar que CRLF o LF o incluso CR era el terminador de línea, no podían sustituir a ningún otro código.
• Algunos de los primeros sistemas operativos de mainframe usaban la longitud de línea fija. sistemas. En tal sistema, se asumió un final de línea implícito cada 72 u 80 caracteres, por ejemplo. No se almacenó ningún carácter de nueva línea. Si se importaba un archivo del mundo exterior, las líneas más cortas que la longitud de la línea tenían que rellenarse con espacios, mientras que las líneas más largas que la línea tenían que ser truncadas. Esto imitaba el uso de tarjetas perforadas, en las que cada línea se almacenaba en una tarjeta separada, generalmente con 80 columnas en cada tarjeta, a menudo con números de secuencia en las columnas 73–80. Muchos de estos sistemas agregaron un carácter de control de carro al comienzo del siguiente registro; esto podría indicar si el siguiente registro era una continuación de la línea iniciada por el registro anterior, o una nueva línea, o debería sobreimprimir la línea anterior (similar a un CR). A menudo, se trataba de un carácter de impresión normal como # que, por tanto, no se podía utilizar como primer carácter de una línea. Algunas impresoras de líneas tempranas interpretaban estos caracteres directamente en los registros que se les enviaban.

UnicodeEdit

El estándar Unicode define una cantidad de caracteres que las aplicaciones compatibles deben reconocer como terminadores de línea:

LF: Line Feed, U + 000A VT: Lengüeta vertical, U + 000B FF: Avance de formulario, U + 000C CR: Retorno del carro, U + 000D CR + LF: CR (U + 000D) seguido de LF (U + 000A) NEL: Siguiente línea, U + 0085 LS: Separador de línea, U + 2028 PS: Separador de párrafo, U + 2029

Esto puede parecer demasiado complicado en comparación con un enfoque como convertir todos los terminadores de línea en un solo carácter, por ejemplo LF. Sin embargo, Unicode fue diseñado para preservar toda la información al convertir un archivo de texto de cualquier codificación existente a Unicode y viceversa. Por lo tanto, Unicode debe contener caracteres incluidos en codificaciones existentes.NL se incluye en EBCDIC con el código 0x15 y, a menudo, se asigna a NEL, que es un carácter de control en el conjunto de control C1. Como tal, está definido por ECMA 48 y reconocido por codificaciones que cumplen con ISO / IEC 2022 (que es equivalente a ECMA 35). El conjunto de control C1 también es compatible con ISO-8859-1. El enfoque adoptado en el estándar Unicode permite que la transformación de ida y vuelta conserve la información al mismo tiempo que permite que las aplicaciones reconozcan todos los tipos posibles de terminadores de línea.

Reconocer y usar los códigos de nueva línea mayores que 0x7F (NEL, LS y PS) no se hace a menudo. Son varios bytes en UTF-8, y el código para NEL se ha utilizado como elipse (… ) en Windows-1252. Por ejemplo:

• ECMAScript acepta LS y PS como saltos de línea, pero considera espacios en blanco U + 0085 (NEL) en lugar de un salto de línea.
• Windows 10 no trata ninguno de NEL, LS o PS como saltos de línea en su editor de texto predeterminado, el Bloc de notas.
• gedit, el editor de texto predeterminado del entorno de escritorio GNOME , trata LS y PS como líneas nuevas, pero no para NEL.
• JSON permite caracteres LS y PS dentro de cadenas, mientras que ECMAScript antes de ES2019 los trataba como líneas nuevas y, por lo tanto, sintaxis ilegal.
• YAML ya no los reconoce como especiales a partir de la versión 1.2, para que sean compatibles con JSON.

Los caracteres Unicode U + 2424 (SYMBOL FOR NEWLINE, ␤ ), U + 23CE (SÍMBOLO DE DEVOLUCIÓN, ⏎ ), U + 240D (SÍMBOLO PARA CARRIAGE RETURN, ␍ ) y U + 240A (SÍMBOLO DE SALTO DE LÍNEA, ␊ ) son destinados a presentar un carácter visible para el usuario al lector del documento y, por lo tanto, no se reconocen como una nueva línea.

Secuencias de escapeEditar

Una secuencia de escape es una combinación de caracteres que no representa texto; en lugar de mostrarse (como texto), se supone que debe ser interceptado por el programa y se supone que debe realizarse una función especial. Las secuencias de escape también se utilizan para manejar (establecer, buscar, reemplazar, etc.) caracteres especiales.

En lenguajes de programación Editar

Para facilitar la creación de programas portátiles, los lenguajes de programación proporcionan algunas abstracciones para tratar los diferentes tipos de secuencias de nueva línea utilizadas en diferentes entornos.

El lenguaje de programación C proporciona las secuencias de escape «\ n» (nueva línea) y «\ r» (retorno de carro). Sin embargo, no es necesario que sean equivalentes a los caracteres de control ASCII LF y CR. El estándar C solo garantiza dos cosas:

1. Cada una de estas secuencias de escape se asigna a un número único definido por la implementación que se puede almacenar en un solo valor de carácter.
2. Al escribir a un archivo, nodo de dispositivo o socket / FIFO en modo texto, «\ n» se traduce de forma transparente a la secuencia de nueva línea nativa utilizada por el sistema, que puede tener más de un carácter. Al leer en modo texto, la secuencia nativa de nueva línea se traduce de nuevo a «\ n». En modo binario, no se realiza ninguna traducción y la representación interna producida por «\ n» se genera directamente.

En plataformas Unix, donde se originó C, la secuencia de nueva línea nativa es ASCII LF ( 0x0A), por lo que «\ n» simplemente se definió como ese valor. Dado que la representación interna y externa son idénticas, la traducción realizada en modo texto es una operación no operativa, y Unix no tiene noción de modo texto o modo binario. Esto ha provocado que muchos programadores que desarrollaron su software en sistemas Unix simplemente ignoren la distinción por completo, lo que resulta en un código que no es portátil a diferentes plataformas.

Es mejor evitar la función de biblioteca C fgets () en modo binario porque cualquier archivo que no esté escrito con la convención de nueva línea de Unix será mal leído. Además, en el modo de texto, cualquier archivo que no se haya escrito con la secuencia de nueva línea nativa del sistema (como un archivo creado en un sistema Unix y luego copiado en un sistema Windows) también se leerá mal.

Otro Un problema común es el uso de «\ n» cuando se comunica mediante un protocolo de Internet que exige el uso de ASCII CR + LF para las líneas finales. Escribir «\ n» en una secuencia en modo texto funciona correctamente en sistemas Windows, pero solo produce LF Unix, y algo completamente diferente en sistemas más exóticos. Usar «\ r \ n» en modo binario es un poco mejor.

Las bibliotecas de E / S de Java no los traducen de manera transparente en secuencias de nueva línea dependientes de la plataforma en entrada o salida. En su lugar, proporcionan funciones para escribir una línea completa que agrega automáticamente la secuencia nativa de nueva línea y funciones para leer líneas que aceptan cualquiera de CR, LF o CR + LF como terminador de línea (consulte BufferedReader.readLine () El método System.lineSeparator () se puede utilizar para recuperar el separador de línea subyacente.

Ejemplo:

 String eol = System.lineSeparator(); String lineColor = "Color: Red" + eol;

Python permite «Universal Newline Support» al abrir un archivo para lectura, cuando importar módulos y al ejecutar un archivo.

Algunos lenguajes han creado variables especiales, constantes y subrutinas para facilitar nuevas líneas durante la ejecución del programa. En algunos lenguajes como PHP y Perl, se requieren comillas dobles para realizar la sustitución de escape para todas las secuencias de escape, incluidas «\ n» y «\ r». En PHP, para evitar problemas de portabilidad, las secuencias de nueva línea deben emitirse utilizando la constante PHP_EOL.

Ejemplo en C #:

 string eol = Environment.NewLine; string lineColor = "Color: Red" + eol; string eol2 = "\n"; string lineColor2 = "Color: Blue" + eol2;

Problemas con diferentes formatos de nueva línea Editar

Aunque los caracteres de control están definidos de forma inequívoca en la tabla de codificación de caracteres correspondiente utilizada por un archivo de texto , todavía hay un problema: existen diferentes convenciones para establecer y mostrar un salto de línea.

Para indicar un solo salto de línea, los programas Unix usan salto de línea , cuyo valor hexadecimal en ASCII es 0a , mientras que la mayoría de los programas comunes a MS-DOS y Microsoft Windows usan retorno de carro + salto de línea , cuyo valor hexadecimal en ASCII es 0d 0a código>. En ASCII, el retorno de carro es un carácter de control distinto.

Las diferentes convenciones de nueva línea hacen que los archivos de texto que se han transferido entre sistemas de diferentes tipos se muestren incorrectamente.

Texto en archivos creados con programas que son comunes en Mac OS clásico o similar a Unix, aparecen como una sola línea larga en la mayoría de los programas comunes a MS-DOS y Microsoft Windows porque estos no muestran un solo salto de línea o un solo retorno de carro como un salto de línea.

Por el contrario, al ver un archivo que se origina en una computadora con Windows en un sistema similar a Unix, el CR adicional puede mostrarse como un segundo salto de línea, como ^ M, o como < cr > al final de cada línea.

Además, los programas que no sean editores de texto pueden no aceptar un archivo, por ejemplo algún archivo de configuración, codificado usando la convención de nueva línea foránea, como un archivo válido.

El problema puede ser difícil de detectar porque algunos programas manejan las líneas foráneas correctamente mientras que otros no. Por ejemplo, un compilador puede fallar con errores de sintaxis oscuros aunque el archivo fuente parezca correcto cuando se muestra en la consola o en un editor. En un sistema similar a Unix, el comando cat -v myfile.txt enviará el archivo a stdout (normalmente la terminal) y hará que ^ M sea visible, lo que puede ser útil para depurar. Los editores de texto modernos generalmente reconocen todos los tipos de líneas nuevas CR + LF y permiten a los usuarios realizar conversiones entre los diferentes estándares. Los navegadores web también suelen ser capaces de mostrar archivos de texto y sitios web que utilizan diferentes tipos de nuevas líneas.

Incluso si un programa admite diferentes convenciones de nuevas líneas, estas funciones no suelen estar suficientemente etiquetadas, descritas o documentadas. Por lo general, se mostrará a los usuarios un menú o cuadro combinado que enumera diferentes convenciones de nuevas líneas sin una indicación de si la selección reinterpretará, convertirá temporalmente o convertirá permanentemente las nuevas líneas. Algunos programas convertirán implícitamente al abrir, copiar, pegar o guardar, a menudo de manera inconsistente.

La mayoría de los protocolos textuales de Internet (incluidos HTTP, SMTP, FTP, IRC y muchos otros) exigen el uso de ASCII CR + LF («\ r \ n», 0x0D 0x0A) en el nivel de protocolo, pero se recomienda que las aplicaciones tolerantes reconozcan el LF solitario («\ n», 0x0A) también. A pesar del estándar dictado, muchas aplicaciones utilizan erróneamente la secuencia de escape de nueva línea de C «\ n» (LF) en lugar de la combinación correcta de las secuencias de escape de retorno de carro y de escape de nueva línea «\ r \ n» (CR + LF) (consulte la sección Nueva línea en lenguajes de programación anteriores). Este uso accidental de secuencias de escape incorrectas genera problemas al intentar comunicarse con sistemas que se adhieren a la interpretación más estricta de los estándares en lugar de la interpretación tolerante sugerida. Uno de esos sistemas intolerantes es el agente de transferencia de correo qmail que se niega activamente a aceptar mensajes de sistemas que envían LF simple en lugar del CR + LF requerido.

El formato de mensaje de Internet estándar para correo electrónico establece: CR y LF DEBEN solo aparecen juntos como CRLF; NO DEBEN aparecer de forma independiente en el cuerpo.

El Protocolo de transferencia de archivos puede convertir automáticamente nuevas líneas en archivos que se transfieren entre sistemas con diferentes representaciones de nuevas líneas cuando la transferencia se realiza en «modo ASCII».Sin embargo, transferir archivos binarios en este modo generalmente tiene resultados desastrosos: cualquier ocurrencia de la secuencia de bytes de nueva línea, que no tiene semántica de terminador de línea en este contexto, pero es solo parte de una secuencia normal de bytes, se traducirá a cualquier representación de nueva línea el otro sistema usa, corrompiendo efectivamente el archivo. Los clientes FTP a menudo emplean algunas heurísticas (por ejemplo, inspección de extensiones de nombre de archivo) para seleccionar automáticamente el modo binario o ASCII, pero al final depende de los usuarios asegurarse de que sus archivos se transfieran en el modo correcto. Si hay alguna duda sobre el modo correcto, se debe usar el modo binario, ya que FTP no modificará archivos, aunque pueden mostrarse incorrectamente.

Conversión entre formatos de nueva líneaEditar

Los editores de texto se utilizan a menudo para convertir un archivo de texto entre diferentes formatos de nueva línea; la mayoría de los editores modernos pueden leer y escribir archivos usando al menos las diferentes convenciones ASCII CR / LF. Por ejemplo, el editor Vim puede hacer que un archivo sea compatible con el editor de texto del Bloc de notas de Windows. Dentro de vim

 :set fileformat=dos :wq

Los editores pueden no ser adecuados para convertir archivos más grandes o conversión masiva de muchos archivos. Para archivos más grandes (en Windows NT / 2000 / XP), a menudo se usa el siguiente comando:

D:\>TYPE unix_file | FIND /V "" > dos_file

Programas de propósito especial para convertir Los archivos entre diferentes convenciones de nueva línea incluyen unix2dos y dos2unix, mac2unix y unix2mac, mac2dos y dos2mac, y flip. El comando tr está disponible en prácticamente todos los sistemas similares a Unix y se puede usar para realizar operaciones de reemplazo arbitrarias en caracteres individuales. Un archivo de texto DOS / Windows se puede convertir a formato Unix simplemente eliminando todos los caracteres ASCII CR con

$ tr -d "\r" < inputfile > outputfile

o, si el texto solo tiene nuevas líneas CR, convertir todas las líneas nuevas de CR a LF con

$ tr "\r" "\n" < inputfile > outputfile

Las mismas tareas a veces se realizan con awk, sed o en Perl si la plataforma tiene un intérprete de Perl:

El comando de archivo puede identificar el tipo de terminaciones de línea:

 $ file myfile.txt myfile.txt: ASCII English text, with CRLF line terminators

El comando de Unix egrep (grep extendido) se puede usar para imprimir nombres de archivos de Unix o archivos DOS (asumiendo solo archivos de estilo Unix y DOS, no Mac OS):

$ egrep -L "\r\n" myfile.txt # show UNIX style file (LF terminated)$ egrep -l "\r\n" myfile.txt # show DOS style file (CRLF terminated)

Otras herramientas permiten al usuario visualizar los caracteres EOL:

$ od -a myfile.txt$ cat -e myfile.txt$ hexdump -c myfile.txt