Nueva línea

Muchos protocolos de comunicación tienen algún tipo de convención de nueva línea. En particular, los protocolos publicados por el Grupo de Trabajo de Ingeniería de Internet (IETF) suelen utilizar la secuencia ASCII CRLF.

En algunos protocolos más antiguos, la nueva línea puede ir seguida de un carácter de suma de comprobación o de paridad.

El estándar Unicode define una serie de caracteres que las aplicaciones conformes deben reconocer como terminadores de línea: ^{[ 9 ]}

Aunque pueda parecer excesivamente complicado en comparación con un enfoque como convertir todos los terminadores de línea a un solo carácter (por ejemplo, LF ), dado que Unicode está diseñado para preservar toda la información al convertir un archivo de texto de cualquier codificación existente a Unicode y viceversa ( integridad de ida y vuelta ), Unicode necesita hacer las mismas distinciones entre los saltos de línea que hacen otras codificaciones. Por ejemplo, EBCDIC tiene los caracteres NL , CR y LF , por lo que los tres también deben existir en Unicode.

La mayoría de los caracteres y secuencias de salto de línea se encuentran en los controles C0 de ASCII (es decir, tienen puntos de código Unicode hasta 0x1F ). Los tres caracteres de salto de línea que quedan fuera de este rango —NEL , LS y PS— a menudo no son reconocidos como saltos de línea por el software. Por ejemplo:

• JSON reconoce CR y LF como espacios en blanco, pero no ningún otro carácter de salto de línea. ^{[ 10 ]} Los controles C0 no pueden aparecer sin escape dentro de las cadenas, pero cualquier otro carácter de salto de línea sí puede. ^{[ 11 ]}
• ECMAScript solo reconoce CR , LF , LS y PS como terminadores de línea. ^{[ 12 ]} Históricamente, no se permitían terminadores de línea sin escape en literales de cadena, ^{[ 13 ]} pero esto cambió en ES2019 para permitir LS y PS sin escape en cadenas ^{[ 12 ]} para compatibilidad con JSON. ^{[ 14 ]}
• YAML 1.1 reconocía los tres como saltos de línea; YAML 1.2 ya no los reconoce como saltos de línea para ser compatible con JSON . ^{[ 15 ]}
• El Bloc de notas de Windows , el editor de texto predeterminado de Microsoft Windows , no trata los caracteres NEL , LS o PS como saltos de línea.
• gedit , el editor de texto predeterminado del entorno de escritorio GNOME , trata LS y PS como saltos de línea, pero no NEL .

Unicode incluye algunos glifos destinados a presentar un carácter visible para el usuario que lee el documento, y por lo tanto no se reconocen como un salto de línea:

• U+23CE ⏎ SÍMBOLO DE RETORNO
• U+240A ␊ SÍMBOLO DE SALIDA DE LÍNEA
• U+240D ␍ SÍMBOLO DE RETORNO DE CARRO
• U+2424 ␤ SÍMBOLO DE SALTO DE LÍNEA

En HTML , los saltos de línea son espacios en blanco y generalmente se tratan ^{[ a ]} de la misma manera que los espacios. ^{[ 16 ]} Los párrafos se crean utilizando instancias separadas del elemento HTML , y la separación física de los párrafos la controla el motor de renderizado. ^{[ 17 ]}<p>

Los saltos de línea se pueden crear explícitamente usando el elemento HTML . Para facilitar que los lectores de pantalla puedan interpretar las páginas, la documentación HTML recomienda no usar este elemento para párrafos. En cambio, fuentes como MDN Web Docs sugieren usar este elemento para poemas . ^{[ 18 ]}<br>

Para facilitar la creación de programas portátiles , los lenguajes de programación proporcionan algunas abstracciones para manejar los diferentes tipos de secuencias de salto de línea que se utilizan en diferentes entornos.

El lenguaje C proporciona las secuencias de escape\n (salto de 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 características:

1. Cada una de estas secuencias de escape se corresponde con un número único definido por la implementación, que puede almacenarse en un valor de tipo carácter .
2. Al escribir en un archivo, nodo de dispositivo o socket/fifo en modo texto , \nse traduce de forma transparente a la secuencia de salto de línea nativa utilizada por el sistema, que puede ser más larga que un carácter. Al leer en modo texto, la secuencia de salto de línea nativa se traduce de nuevo a \n. En modo binario , no se realiza ninguna traducción y la representación interna producida por \nse muestra directamente.

En las plataformas de sistemas operativos Unix , donde se originó C, la secuencia nativa de salto de línea es ASCII LF ( 0x0A ), por lo que simplemente se definió con ese valor. Dado que la representación interna y externa son idénticas, la traducción realizada en modo texto no tiene efecto , y Unix no distingue entre modo texto y modo binario. Esto ha provocado que muchos programadores que desarrollaron su software en sistemas Unix simplemente ignoren esta distinción, lo que resulta en código que no es portable a otras plataformas.\n

Se recomienda evitar la función fgets () de la biblioteca estándar de C en modo binario, ya que cualquier archivo que no siga la convención de salto de línea de Unix se interpretará erróneamente. Asimismo, en modo texto, cualquier archivo que no utilice la secuencia de salto de línea nativa del sistema (como un archivo creado en un sistema Unix y copiado a un sistema Windows) también se interpretará erróneamente.

Otro problema común surge al \ncomunicarse mediante un protocolo de Internet que exige el uso de CR + LF para el final de línea en ASCII. Escribir en un flujo de texto funciona correctamente en sistemas Windows, pero produce solo LF en Unix y algo completamente diferente en sistemas más exóticos. Usar en modo binario ofrece una solución ligeramente mejor.\n\r\n

Muchos lenguajes, como C++ , Perl , ^{[ 19 ]} y Haskell, proporcionan la misma interpretación que \nC. C++ tiene un modelo de entrada/salida (E/S) alternativo donde el manipulador std::endl se puede usar para generar un salto de línea (y vacía el búfer de flujo).

Java , PHP [ ^{20 ]} y Python ^{[ 21 ]} proporcionan la secuencia (para ASCII CR + LF ). A ^diferencia de C, se garantiza que estas representen los valores U+000D y U+000A , respectivamente.\r\n

Los métodos de entrada/salida (E/S) de la biblioteca de clases de Java no traducen de forma transparente estas secuencias de salto de línea dependientes de la plataforma en la entrada o salida. En cambio, proporcionan funciones para escribir una línea completa que agregan automáticamente la secuencia de salto de línea nativa, 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 usar para recuperar el separador de línea subyacente. Este también se inserta automáticamente cuando se usa el especificador de formato en .%nSystem.out::printf

Ejemplo:

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

Python tiene una función de "compatibilidad universal con saltos de línea" habilitada por defecto, que traduce las tres convenciones de fin de línea más comunes ( \n, \r, \r\n) a la convención estándar de Python \nal abrir un archivo para lectura, al importar módulos y al ejecutar un archivo. Esta función se puede controlar mediante el newlineargumento en la open()función al abrir el archivo. ^{[ 22 ] [ 23 ]}

Algunos lenguajes han creado variables , constantes y subrutinas especiales para facilitar los saltos de línea durante la ejecución del programa. En algunos lenguajes como PHP y Perl , se requieren comillas dobles\n para realizar la sustitución de escape para todas las secuencias de escape, incluidas y \r. En PHP, para evitar problemas de portabilidad, las secuencias de salto de línea deben emitirse utilizando la constante PHP_EOL. ^{[ 24 ]}

Ejemplo en C# :

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

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

El texto en archivos creados con programas comunes en sistemas tipo Unix o Mac OS clásico , aparece como una sola línea larga en la mayoría de los programas comunes en MS-DOS y Microsoft Windows porque estos no muestran un solo line feedo un solo carriage returncomo salto de línea.

Por el contrario, al visualizar un archivo procedente de un ordenador Windows en un sistema tipo 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, es posible que otros programas que no sean editores de texto no acepten un archivo, por ejemplo, un archivo de configuración, codificado utilizando la convención de salto de línea extranjera, como un archivo válido.

El problema puede ser difícil de detectar porque algunos programas manejan correctamente los saltos de línea extranjeros, mientras que otros no. Por ejemplo, un compilador puede fallar con errores de sintaxis difíciles de detectar, aunque el archivo fuente parezca correcto al visualizarlo en la consola o en un editor . Los editores de texto modernos generalmente reconocen todas las variantes de saltos de línea CR + LF y permiten a los usuarios convertir entre los diferentes estándares. Los navegadores web también suelen ser capaces de mostrar archivos de texto y sitios web que utilizan distintos tipos de saltos de línea.

Aunque un programa admita diferentes convenciones de salto de línea, estas funciones a menudo no están suficientemente etiquetadas, descritas ni documentadas. Normalmente, se muestra un menú o cuadro combinado con las distintas convenciones sin indicar si la selección reinterpretará, convertirá temporalmente o convertirá permanentemente los saltos de línea. Algunos programas realizan la conversión implícitamente al abrir, copiar, pegar o guardar, a menudo de forma inconsistente.

La mayoría de los protocolos de Internet textuales (incluidos HTTP , SMTP , FTP , IRC y muchos otros) exigen el uso de CR + LF ASCII ( , 0x0D 0x0A ) a nivel de protocolo, pero recomiendan que las aplicaciones tolerantes reconozcan también LF solo ( , 0x0A ). A pesar del estándar dictado, muchas aplicaciones utilizan erróneamente la secuencia de escape de nueva línea de C ( LF ) en lugar de la combinación correcta de secuencias de escape de retorno de carro y nueva línea ( CR + LF ) (véase la sección Nueva línea en lenguajes de programación más arriba). 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. Un ejemplo de sistema intolerante es el agente de transferencia de correo qmail , que se niega activamente a aceptar mensajes de sistemas que envían LF solo en lugar de CR + LF requeridos . ^{[ 25 ]}\r\n\n\n\r\n

El formato estándar de mensajes de Internet ^{[ 26 ]} para correo electrónico establece: "CR y LF SOLO DEBEN aparecer juntos como CRLF; NO DEBEN aparecer de forma independiente en el cuerpo". Las diferencias entre las implementaciones de SMTP en la forma en que tratan los caracteres LF y/o CR sin formato han dado lugar a ataques de suplantación de identidad SMTP conocidos como "contrabando SMTP". ^{[ 27 ]}

El protocolo de transferencia de archivos (FTP) puede convertir automáticamente los saltos de línea en archivos que se transfieren entre sistemas con diferentes representaciones de salto de línea cuando la transferencia se realiza en "modo ASCII". Sin embargo, transferir archivos binarios en este modo suele tener resultados desastrosos: cualquier aparición de la secuencia de bytes de salto de línea —que en este contexto no tiene semántica de terminador de línea, sino que es simplemente parte de una secuencia normal de bytes— se traducirá a la representación de salto de línea que utilice el otro sistema, lo que corromperá el archivo. Los clientes FTP suelen emplear algunas heurísticas (por ejemplo, la inspección de las extensiones de los nombres de archivo ) para seleccionar automáticamente el modo binario o ASCII, pero en última instancia, es responsabilidad del usuario asegurarse de que sus archivos se transfieran en el modo correcto. Si existe alguna duda sobre el modo correcto, se debe utilizar el modo binario, ya que así ningún archivo será alterado por FTP, aunque podrían mostrarse incorrectamente. ^{[ 28 ]}

Los editores de texto se utilizan a menudo para convertir un archivo de texto entre diferentes formatos de salto de línea; la mayoría de los editores modernos pueden leer y escribir archivos utilizando 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 Bloc de notas de Windows. Dentro de Vim

: establecer formato de archivo = dos : wq

Los editores pueden no ser adecuados para convertir archivos grandes o para la conversión masiva de muchos archivos. Para archivos grandes (en Windows NT) se suele utilizar el siguiente comando:

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

Los programas de propósito especial para convertir archivos entre diferentes convenciones de salto de línea incluyen unix2dos y dos2unix , mac2unix y unix2mac , mac2dos y dos2mac , y flip . ^{[ 29 ]} El comando tr está disponible en prácticamente todos los sistemas tipo Unix y se puede utilizar para realizar operaciones de reemplazo arbitrarias en caracteres individuales. Un archivo de texto de DOS/Windows se puede convertir al formato Unix simplemente eliminando todos los caracteres CR ASCII con

$ tr -d '\r' < archivo de entrada > archivo de salida

o, si el texto solo tiene saltos de línea CR , convirtiendo todos los saltos de línea CR a LF con

$ tr '\r' '\n' < archivo de entrada > archivo de salida

A veces, las mismas tareas se realizan con awk , sed o en Perl si la plataforma dispone de un intérprete de Perl:

$ awk '{sub("$","\r\n"); printf("%s",$0);}' archivo_entrada > archivo_salida # UNIX a DOS (añadiendo CR en Linux y sistemas operativos basados ​​en BSD que no tienen extensiones GNU) $ awk '{gsub("\r",""); print;}' archivo_entrada > archivo_salida # DOS a UNIX (eliminando CR en sistemas operativos basados ​​en Linux y BSD que no tienen extensiones GNU) $ sed -e 's/$/\r/' archivo_entrada > archivo_salida # UNIX a DOS (añadiendo CR en sistemas operativos basados ​​en Linux que usan extensiones GNU) $ sed -e 's/\r$//' archivo_entrada > archivo_salida # DOS a UNIX (eliminando CR en sistemas operativos basados ​​en Linux que usan extensiones GNU) $ perl -pe 's/\r?\n|\r/\r\n/g' archivo_entrada > archivo_salida # Convertir a DOS $ perl -pe 's/\r?\n|\r/\n/g' archivo_entrada > archivo_salida # Convertir a UNIX $ perl -pe 's/\r?\n|\r/\r/g' archivo_entrada > archivo_salida # Convertir a Mac antiguo

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

$ archivo myfile.txt myfile.txt: texto en inglés ASCII, con terminadores de línea CRLF

El comando Unix egrep (grep extendido) se puede utilizar para imprimir los nombres de archivo de archivos Unix o DOS (suponiendo que solo se trate de archivos de estilo Unix y DOS, no de archivos clásicos de estilo Mac OS):

$ egrep -L '\r\n' myfile.txt # muestra un archivo de estilo UNIX (terminado con LF) $ egrep -l '\r\n' myfile.txt # muestra un archivo de estilo DOS (terminado con CRLF)

Otras herramientas permiten al usuario visualizar los caracteres EOL:

$ od -a miarchivo.txt $ cat -e miarchivo.txt $ cat -v miarchivo.txt $ hexdump -c miarchivo.txt