Nueva línea

Caracteres especiales en informática que indican el final de una línea de texto

Nueva línea insertada entre las palabras "Hola" y "mundo"

Una nueva línea (frecuentemente llamada final de línea , fin de línea ( EOL ), siguiente línea ( NEL ) o salto de línea ) es un carácter de control o una secuencia de caracteres de control en las especificaciones de codificación de caracteres como ASCII , EBCDIC , Unicode , etc. Este carácter, o una secuencia de caracteres, se utiliza para indicar el final de una línea de texto y el comienzo de una nueva. ^[1]

Historia

A mediados del siglo XIX, mucho antes de la llegada de los teletipos y las teleimpresoras, los operadores de código Morse o telegrafistas inventaron y utilizaron prosignos de código Morse para codificar el formato de texto con espacios en blanco en mensajes de texto escritos formales. En particular, el prosigno Morse BT (mnemonic break text ), representado por la concatenación de los caracteres textuales de los códigos Morse "B" y "T", enviados sin el espaciado normal entre caracteres, se utiliza en código Morse para codificar e indicar una nueva línea o una nueva sección en un mensaje de texto formal.

Más tarde, en la era de los modernos teletipos , se desarrollaron códigos de control de conjuntos de caracteres estandarizados para ayudar en el formato de texto de espacios en blanco. ASCII fue desarrollado simultáneamente por la Organización Internacional de Normalización (ISO) y la Asociación Estadounidense de Normalización (ASA), siendo esta última la organización predecesora del Instituto Nacional Estadounidense de Normalización (ANSI). Durante el período de 1963 a 1968, los borradores de normas ISO admitían el uso de .mw-parser-output .monospaced{font-family:monospace,monospace}CR+LF o LF solo como nueva línea, mientras que los borradores de la ASA admitían solo CR + LF .

La secuencia CR + LF se utilizaba comúnmente en muchos de los primeros sistemas informáticos que habían adoptado las máquinas de teletipo (normalmente, un Teletype Model 33 ASR) como dispositivo de consola, porque esta secuencia era necesaria para colocar esas impresoras al principio de una nueva línea. La separación de la nueva línea en dos funciones ocultaba el hecho de que el cabezal de impresión no podía volver desde el extremo derecho al principio de la siguiente línea a tiempo para imprimir el siguiente carácter. Cualquier carácter impreso después de un CR se imprimía a menudo como una mancha en el medio de la página mientras el cabezal de impresión todavía estaba moviendo el carro de vuelta a la primera posición. "La solución fue hacer que la nueva línea tuviera dos caracteres: CR para mover el carro a la columna uno y LF para mover el papel hacia arriba". ^[2] De hecho, a menudo era necesario enviar caracteres de relleno adicionales (CR o NUL extraños) que se ignoran pero dan tiempo al cabezal de impresión para moverse al margen izquierdo. Muchas de las primeras pantallas de vídeo también requerían varios caracteres para desplazarse por la pantalla.

En estos sistemas, las aplicaciones tenían que comunicarse directamente con la máquina de teletipo y seguir sus convenciones, ya que el concepto de que los controladores de dispositivos ocultaran esos detalles de hardware a la aplicación aún no estaba bien desarrollado. Por lo tanto, el texto se componía rutinariamente para satisfacer las necesidades de las máquinas de teletipo. La mayoría de los sistemas de minicomputadoras a partir de DEC usaban esta convención. CP/M también la usaba para imprimir en las mismas terminales que usaban las minicomputadoras. A partir de ahí, MS-DOS (1981) adoptó el CR + LF de CP/M para ser compatible, y esta convención fue heredada por el posterior sistema operativo Windows de Microsoft.

El sistema operativo Multics comenzó a desarrollarse en 1964 y utilizaba solo LF como su nueva línea. Multics usaba un controlador de dispositivo para traducir este carácter a cualquier secuencia que necesitara una impresora (incluyendo caracteres de relleno adicionales ), y el byte único era más conveniente para la programación. Lo que parece una opción más obvia, CR , no se usó, ya que CR proporcionaba la función útil de sobreimprimir una línea con otra para crear efectos de negrita , subrayado y tachado . Quizás más importante aún, el uso de LF solo como terminador de línea ya se había incorporado en los borradores del eventual estándar ISO/IEC 646. Unix siguió la práctica de Multics, y más tarde los sistemas similares a Unix siguieron a Unix. Esto creó conflictos entre Windows y los sistemas operativos similares a Unix , por lo que los archivos compuestos en un sistema operativo no podían formatearse o interpretarse correctamente por otro sistema operativo (por ejemplo, un script de shell de UNIX escrito en un editor de texto de Windows como el Bloc de notas ^{[3] [4]} ).

Representación

Los conceptos de retorno de carro (CR) y avance de línea (LF) están estrechamente relacionados y pueden considerarse por separado o en conjunto. En los medios físicos de las máquinas de escribir e impresoras , se necesitan dos ejes de movimiento, "hacia abajo" y "hacia el otro lado", 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 como un solo evento. Es por eso que una nueva línea en la codificación de caracteres puede definirse como CRy LFcombinarse en una sola (comúnmente llamada CR+LFo CRLF).

Algunos conjuntos 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 "próxima línea" ( NEL ), así como códigos de control para los 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 IBM i ( OS/400 )) utilizan NL (New Line, 0x15 ) ^[8] como el carácter que combina las funciones de avance de línea y retorno de carro. El carácter Unicode equivalente ( ) se llama NEL (Next Line). 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 utilizan 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, en realidad no se almacenan terminadores de línea.0x85
• Los sistemas operativos de la serie CDC 6000 definían 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 definían un carácter de valor cero como un carácter de dos puntos , con el resultado de que varios dos puntos podí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 los 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 forma transparente un terminador a cada línea cuando una aplicación la recupera. Los registros en sí pueden contener los mismos caracteres de terminación de línea, lo que puede considerarse una característica o una molestia según la aplicación. RMS no solo almacena registros, sino que también almacena metadatos sobre los separadores de registros en diferentes bits para el archivo, lo que complica aún más las cosas (ya que los archivos pueden tener registros de longitud fija, registros que tienen como prefijo un recuento o registros que terminan con un carácter específico). Los bits no son genéricos, por lo que, si bien pueden especificar que CR LF o LF o incluso CR es el terminador de línea, no pueden sustituir a otro código.
• Algunos de los primeros sistemas operativos mainframe utilizaban una longitud de línea fija . En un sistema de este tipo, se asumía un fin de línea implícito cada 72 u 80 caracteres, por ejemplo. No se almacenaba 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 línea debían rellenarse con espacios, mientras que las líneas más largas que la longitud de línea debían truncarse. Esto imitaba el uso de tarjetas perforadas , en las que cada línea se almacenaba en una tarjeta separada, normalmente con 80 columnas en cada tarjeta, a menudo con números de secuencia en las columnas 73-80. Muchos de estos sistemas añadían un carácter de control de carro al comienzo del siguiente registro; esto podí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 debía sobreimprimir la línea anterior (similar a un CR ). A menudo se trataba de un carácter de impresión normal como ese, por lo que no podía utilizarse como primer carácter de una línea. Algunas de las primeras impresoras de línea interpretaban estos caracteres directamente en los registros que se les enviaban.#

Protocolos de comunicación

Muchos protocolos de comunicaciones tienen algún tipo de convención de nueva línea. En particular, los protocolos publicados por Internet Engineering Task Force (IETF) suelen utilizar la secuencia CRLF de ASCII.

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.

Unicode

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

 LF :avance de línea, U+000A   

 VT : Pestaña vertical , U+000B   

 FF : Avance de página , U+000C   

 CR : Retorno de 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árrafos, U+2029   

Si bien 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 ), debido a 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 realizados por otras codificaciones.

Por ejemplo: NL es parte de EBCDIC , que utiliza el código 0x15 ; normalmente se asigna a Unicode NEL , 0x85 , que es un carácter de control en el conjunto de control C1 . ^[10] Como tal, está definido por ECMA 48, ^[11] y reconocido por codificaciones compatibles con ISO/IEC 2022 (que es equivalente a ECMA 35). ^[12] El conjunto de control C1 también es compatible con ISO-8859-1 . ^{[ cita requerida ]} El enfoque adoptado en el estándar Unicode permite que la transformación de ida y vuelta preserve la información y al mismo tiempo permita que las aplicaciones reconozcan todos los tipos posibles de terminadores de línea.

No es habitual reconocer y utilizar los códigos de nueva línea mayores que 0x7F ( NEL , LS y PS ). Son varios bytes en UTF-8 y el código para NEL se ha utilizado como el carácter de puntos suspensivos ( ) en Windows-1252 . Por ejemplo:…

• ECMAScript acepta LS y PS como saltos de línea, ^[13] pero considera espacios en blanco U+0085 ( NEL ) en lugar de un salto de línea. ^[14]
• JSON ^[15] permite caracteres LS y PS dentro de cadenas, mientras que ECMAScript anterior a ES2019 ^{[16] [17]} los trataba como nuevas líneas y, por lo tanto, una sintaxis ilegal. ^[18]
• YAML ^[19] ya no los reconoce como saltos de línea a partir de la versión 1.2, para ser compatible con JSON .
• El Bloc de notas de Windows , el editor de texto predeterminado de Microsoft Windows , no trata NEL , LS o PS como saltos de línea.
• gedit , el editor de texto predeterminado del entorno de escritorio GNOME , trata a LS y PS , pero no a NEL , como saltos de línea.

Los caracteres especiales Unicode U+2424 ( SÍMBOLO DE NUEVA LÍNEA , ), U+23CE ( SÍMBOLO DE RETORNO , ), U+240D ( SÍMBOLO DE RETORNO DE CARRO , ) y U+240A ( SÍMBOLO DE SALTO DE LÍNEA , ) son glifos destinados a presentar un carácter visible para el lector del documento y, por lo tanto, no se reconocen como una nueva línea.␤⏎␍␊

En lenguajes de programación

Para facilitar la creación de programas portables , 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 en un archivo, nodo de dispositivo o socket/fifo en modo de 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 de texto, la secuencia de nueva línea nativa se traduce nuevamente a '\n' . En modo binario , no se realiza ninguna traducción y la representación interna producida por '\n' se emite directamente.

En las 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. Como la representación interna y externa son idénticas, la traducción realizada en modo texto no es una operación 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 da como resultado un código que no es portable a diferentes plataformas.

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

Otro 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 finalizar las líneas. Escribir '\n' 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. El uso de "\r\n" en modo binario es ligeramente mejor.

Muchos lenguajes, como C++ , Perl , ^[20] y Haskell proporcionan la misma interpretación de '\n' que C++. C++ tiene un modelo de E/S alternativo donde el manipulador std::endl se puede utilizar para generar una nueva línea (y vacía el búfer de flujo).

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

Las bibliotecas de E/S de Java no traducen de forma transparente estas secuencias de nueva línea dependientes de la plataforma en la entrada o la salida. En cambio, proporcionan funciones para escribir una línea completa que agrega automáticamente la secuencia de nueva línea nativa y funciones para leer líneas que aceptan 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:

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

Python permite "soporte universal de nueva línea" al abrir un archivo para lectura, al importar módulos y al ejecutar un archivo. ^[23]

Algunos lenguajes han creado variables , constantes y subrutinas especiales para facilitar las 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 se deben emitir utilizando la constante PHP_EOL. ^[24]

Ejemplo en C# :

 cadena eol = Environment . NewLine ; cadena lineColor = "Color: Rojo" + eol ; cadena eol2 = "\n" ; cadena lineColor2 = "Color: Azul" + eol2 ;                    

Problemas con diferentes formatos de nueva línea

Un archivo de texto creado con gedit y visualizado con un editor hexadecimal . Además de los objetos de texto, solo hay marcadores de fin de línea con el valor hexadecimal 0A.

Las diferentes convenciones de nueva 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 operativos 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 una sola línea line feedo una sola carriage returncomo salto de línea.

Por el contrario, al visualizar un archivo originado en una computadora 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 programas que no sean editores de texto no acepten un archivo (por ejemplo, un archivo de configuración) codificado mediante la convención de nueva línea extranjera como un archivo válido.

El problema puede ser difícil de detectar porque algunos programas manejan las nuevas líneas extranjeras correctamente mientras que otros no. Por ejemplo, un compilador puede fallar con errores de sintaxis poco claros aunque el archivo fuente parezca correcto cuando se muestra en la consola o en un editor . Los editores de texto modernos generalmente reconocen todos los tipos de nuevas líneas 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 diferentes tipos de nuevas líneas.

Incluso si un programa admite distintas convenciones de nueva línea, estas características no suelen estar suficientemente etiquetadas, descritas o documentadas. Normalmente, se mostrará a los usuarios un menú o cuadro combinado que enumera distintas convenciones de nueva línea sin indicar si la selección reinterpretará, convertirá temporalmente o convertirá permanentemente las nuevas líneas. Algunos programas convertirán implícitamente las líneas nuevas al abrirlas, copiarlas, pegarlas o guardarlas, a menudo de forma 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 recomiendan que las aplicaciones tolerantes reconozcan también LF solo ( '\n' , 0x0A ). 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 secuencias de escape de retorno de carro y de nueva línea '\r\n' ( CR + LF ) (consulte la sección Nueva línea en lenguajes de programación más arriba). Este uso accidental de las secuencias de escape incorrectas conduce a 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 estos 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 . ^[25]

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 cuanto a cómo tratan los caracteres LF y/o CR simples han dado lugar a ataques de suplantación de SMTP conocidos como "contrabando de SMTP". ^[27]

El Protocolo de Transferencia de Archivos puede convertir automáticamente las nuevas líneas en archivos que se transfieren entre sistemas con diferentes representaciones de nueva línea cuando la transferencia se realiza en "modo ASCII". Sin embargo, la transferencia de archivos binarios en este modo suele tener resultados desastrosos: cualquier aparición de la secuencia de bytes de nueva línea (que no tiene semántica de terminador de línea en este contexto, sino que es simplemente parte de una secuencia normal de bytes) se traducirá a cualquier representación de nueva línea que utilice el otro sistema, lo que dañará 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 es responsabilidad de los usuarios asegurarse de que sus archivos se transfieren en el modo correcto. Si existe alguna duda sobre el modo correcto, se debe utilizar el modo binario, ya que entonces el FTP no alterará los archivos, aunque es posible que se muestren incorrectamente. ^[28]

Conversión entre formatos de nueva línea

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 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 del Bloc de notas de Windows. Dentro de vim

 : establecer  formato de archivo = dos : que

Los editores pueden resultar inadecuados para convertir archivos de gran tamaño o para realizar conversiones masivas de muchos archivos. Para archivos de gran tamaño (en Windows NT), se suele utilizar el siguiente comando:

D:\> TIPO archivo_unix | BUSCAR /V ""  > archivo_dos

Los programas de propósito especial para convertir archivos entre diferentes convenciones de nueva 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 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 nuevas líneas CR , convirtiendo todas las nuevas líneas CR a LF con

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

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

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

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

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

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

$ egrep  -L '\r\n' myfile.txt # muestra el archivo de estilo UNIX (terminado en LF) $ egrep -l '\r\n' myfile.txt # muestra el archivo de estilo DOS (terminado en 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

Interpretación

Dos formas de ver las nuevas líneas, ambas autoconsistentes , son que las nuevas líneas separan líneas o que terminan líneas. Si una nueva línea se considera un separador, no habrá ninguna nueva línea después de la última línea de un archivo. Algunos programas tienen problemas para procesar la última línea de un archivo si no está terminada por una nueva línea. Por otro lado, los programas que esperan que se use una nueva línea como separador interpretarán una nueva línea final como el inicio de una nueva línea (vacía). Por el contrario, si una nueva línea se considera un terminador, se espera que todas las líneas de texto, incluida la última, terminen con una nueva línea. Si la secuencia de caracteres final en un archivo de texto no es una nueva línea, la línea final del archivo puede considerarse una línea de texto incorrecta o incompleta, o puede considerarse que el archivo está truncado incorrectamente.

En un texto destinado principalmente a ser leído por humanos mediante software que implementa la función de ajuste de línea , un carácter de nueva línea normalmente solo necesita almacenarse si se requiere un salto de línea independientemente de si la siguiente palabra encajaría en la misma línea, como entre párrafos y en listas verticales. Por lo tanto, en la lógica del procesamiento de textos y la mayoría de los editores de texto , el carácter de nueva línea se utiliza como un salto de párrafo y se conoce como "retorno duro", en contraste con los "retornos suaves" que se crean dinámicamente para implementar el ajuste de línea y se pueden cambiar con cada instancia de visualización. En muchas aplicaciones existe un carácter de control independiente llamado "salto de línea manual" para forzar saltos de línea dentro de un solo párrafo. El glifo para el carácter de control para un retorno duro suele ser un pilcrow (¶), y para el salto de línea manual suele ser una flecha de retorno de carro (↵).

Avances de línea inversos y parciales

RI ( U +008D REVERSE LINE FEED , ^[30] ISO/IEC 6429 8D, decimal 141) se utiliza para mover la posición de impresión una línea hacia atrás (haciendo retroceder el papel o moviendo el cursor de la pantalla una línea hacia arriba) de modo que se puedan imprimir otros caracteres sobre el texto existente. Esto se puede hacer para que aparezcan más resaltados o para agregar subrayados, tachados u otros caracteres como diacríticos .

De manera similar, PLD ( U +008B LINEA PARCIAL HACIA ADELANTE, decimal 139) y PLU ( U +008C LINEA PARCIAL HACIA ATRÁS, decimal 140) se pueden utilizar para avanzar o invertir la posición de impresión del texto en una fracción del espaciado de línea vertical (normalmente, la mitad). Se pueden utilizar en combinación para subíndices (avanzando y luego invirtiendo) y superíndices (invirtiendo y luego avanzando), y también pueden ser útiles para imprimir diacríticos.

Véase también

• Fin del archivo
• Tecla Enter
• Salto de página

Referencias

1. "¿Qué es una nueva línea?". www.computerhope.com . Consultado el 10 de mayo de 2021 .
2. Qualline, Steve (2001). Vi Improved - Vim (PDF) . Sams Publishing . pág. 120. ISBN. 9780735710016Archivado desde el original (PDF) el 8 de abril de 2022 . Consultado el 4 de enero de 2023 .
3. Duckett, Chris. "El Bloc de notas de Windows finalmente entiende los caracteres de final de línea de todos los demás". ZDNet . Archivado desde el original el 13 de mayo de 2018 . Consultado el 4 de enero de 2023 . [D]espués de décadas de frustración y de tener que descargar un editor de texto real para cambiar una sola línea en un archivo de configuración desde una máquina Linux, Microsoft ha actualizado el Bloc de notas para que pueda manejar los caracteres de final de línea utilizados en entornos Unix, Linux y macOS.
4. Lopez, Michel (8 de mayo de 2018). "Introducción de la compatibilidad con finales de línea extendidos en el Bloc de notas". Línea de comandos de Windows . Archivado desde el original el 6 de abril de 2019 . Consultado el 4 de enero de 2023 . Como ocurre con cualquier cambio en una herramienta de larga data, existe la posibilidad de que este nuevo comportamiento no funcione en sus escenarios, o puede que prefiera deshabilitar este nuevo comportamiento y volver al comportamiento original del Bloc de notas. Para ello, puede cambiar [...claves de registro...] para ajustar la forma en que el Bloc de notas maneja el pegado de texto y qué carácter de fin de línea usar cuando se presiona Enter/Return
5. Kahn-Greene, Will Guaraldi. "Gráfico ASCII". bluesock.org .
6. Bray, Andrew C.; Dickens, Adrian C.; Holmes, Mark A. (1983). Guía avanzada del usuario de la microcomputadora BBC (PDF) . Cambridge Microcomputer Centre. pp. 103, 104. ISBN. 978-0946827008. Recuperado el 30 de enero de 2019 .
7. "Character Output". Manual de referencia del programador de RISC OS 3. 3QD Developments Ltd. 3 de noviembre de 2015. Consultado el 18 de julio de 2018 .
8. Tarjeta de datos de referencia del IBM System/360, publicación GX20-1703, IBM Data Processing Division, White Plains, NY
9. Heninger, Andy (20 de septiembre de 2013). "UAX #14: Algoritmo de salto de línea Unicode". El Consorcio Unicode.
10. "Conjunto de caracteres de control C1 de la norma ISO 6429" (PDF) . ITSCJ. IPSJ. 1 de octubre de 1983 . Consultado el 3 de marzo de 2022 .
11. Funciones de control para conjuntos de caracteres codificados (PDF) (Informe). ECMA International. Junio ​​de 1991.
12. Estructura del código de caracteres y técnicas de extensión (PDF) (Informe) (6.ª ed.). ECMA International. Diciembre de 1994.
13. "Especificación del lenguaje ECMAScript 2019". ECMA International. Junio ​​de 2019. 11.3 Terminadores de línea.
14. "Especificación del lenguaje ECMAScript 2019". ECMA International. Junio ​​de 2019. 11.2 Espacio en blanco.
15. Bray, Tim (marzo de 2014). "Cadenas". Formato de intercambio de datos de notación de objetos JavaScript (JSON). sec. 7. doi : 10.17487/RFC7159 . RFC 7159.
16. "Subsume JSON (también conocido como JSON ⊂ ECMAScript)". GitHub . 22 de mayo de 2018.
17. "Especificación del lenguaje ECMAScript 2019". ECMA International. Junio ​​de 2019. 11.8.4 Literales de cadena.
18. "Especificación del lenguaje ECMAScript 2018". ECMA International. Junio ​​de 2018. 11.8.4 Literales de cadena.
19. "5.4. Caracteres de salto de línea". YAML Ain't Markup Language, revisión 1.2.2 . 1 de octubre de 2021.
20. "binmode". Documentación de Perl . Portadores de Perl 5.
21. "PHP: Cadenas - Manual". Manual de PHP . The PHP Group.
22. "2. Análisis léxico". Referencia del lenguaje Python . La Fundación Python.
23. "Novedades en Python 2.3". Fundación de software Python.
24. "PHP: Constantes predefinidas - Manual". Manual de PHP . The PHP Group.
25. Bernstein, DJ "LF desnudos en SMTP".
26. Resnick, Pete (abril de 2001). Formato de mensajes de Internet. doi : 10.17487/RFC2822 . RFC 2822.
27. Longin, Timo (18 de diciembre de 2023). "Contrabando de SMTP: suplantación de correos electrónicos en todo el mundo". SEC Consult .
28. Zeil, Steven (19 de enero de 2015). "Transferencia de archivos". Universidad Old Dominion. Archivado desde el original el 14 de mayo de 2016. En caso de duda, realice la transferencia en modo binario.
29. Sapp, Craig Stuart. "Conversión de texto ASCII entre UNIX, Macintosh y MS-DOS". Centro de investigación informática en música y acústica. Archivado desde el original el 9 de febrero de 2009.
30. "Controles C1 y suplemento Latin-1" (PDF) . unicode.org . Consultado el 13 de febrero de 2016 .

Enlaces externos

• La referencia Unicode; consulte el párrafo 5.8 del Capítulo 5 del estándar Unicode 4.0 (PDF)
• "El carácter de nueva línea [NEL]".
• El rompecabezas del final de la línea
• Comprensión de las nuevas líneas en Wayback Machine (archivado el 20 de agosto de 2006)
• "La historia del fin de la línea"