En informática, nueva línea es un carácter especial, o secuencia de caracteres, que indica el final de una línea de texto y el paso a la siguiente. Se le llama así porque el carácter a la derecha del nueva línea aparecerá en la línea de debajo de los caracteres que había a la izquierda, por tanto en una línea nueva.

La codificación del carácter nueva línea no es la misma en todas las arquitecturas ni sistemas operativos, cosa que puede dar problemas cuando se intercambian datos entre ordenadores.

Aún se discute si el carácter de nueva línea debería terminar o separar las líneas.

Si se usa como separador, un texto con las líneas A, B, y C quedaría grabado así (representando el carácter de nueva línea con \n):

A \n B \n C

Entonces, la última línea (C) no tiene el código de nueva línea al final. Este comportamiento está poco recomendado, y algunos programas tienen problemas procesando la última línea de un fichero si no acaba con una nueva línea, así que la convención general es tratar \n como terminador:

A \n B \n C \n

Este cambio puede afectar en el recuento de líneas de un fichero, pero no da problemas mayores.

Las aplicaciones y los sistemas operativos normalmente representan el carácter nueva línea con uno o con dos códigos de control:

• Los sistemas basados en ASCII o en una codificación de caracteres compatible usan LF (salto de línea), CR (retorno de carro), o CRLF (CR seguido de LF):
  • LF:     Unix y sistemas tipo Unix, Linux, AIX, Xenix, Mac OS X, BeOS, Amiga, RISC OS y otros
  • CR+LF: CP/M, MP/M, DOS, Microsoft Windows
  • CR:     familia Apple II y Mac OS hasta la versión 9
  • LF+CR: Las antiguas máquinas de escribir (por establecer la analogía con las computadoras)
• Los sistemas EBCDIC, principalmente mainframes de IBM incluyendo a z/OS (OS/390), i5/OS (OS/400), usan NEL (siguiente línea) como carácter de nueva línea. EBCDIC también tiene caracteres llamados CR y LF, pero el valor numérico del LF es distinto al que se usa en ASCII. Otras variantes de EBCDIC también usan NEL pero con otro valor numérico asignado al carácter.
• OpenVMS usa un sistema de ficheros basado en registros, y guarda los ficheros de texto con un registro por línea. Por tanto, no se almacena ningún terminador de línea, aunque el sistema puede añadir terminadores a cada línea de forma transparente cuando una aplicación accede a los datos.

Los valores numéricos usados normalmente son:

• CR: decimal 13, hexadecimal 0D
• LF: decimal 10, hexadecimal 0A
• NEL: decimal 21, hexadecimal 15

El CRLF no es más que uno detrás de otro, por tanto 0D 0A en hexadecimal.

Muchos protocolos de Internet son textuales, o sea, que envían líneas de texto para hacer las peticiones (además de usar código binario). Por eso, han de controlar cómo se tiene que marcar el final de cada línea.

Por tradición, la mayoría han funcionado usando el CRLF en el nivel de protocolo. Por ejemplo, HTTP, SMTP, FTP e IRC, entre otros. Sin embargo, algunos recomiendan que las aplicaciones también reconozcan un LF suelto.

En la práctica, hay muchas aplicaciones que acaban usando (incorrectamente) el código de nueva línea del lenguaje de programación C, que es \n pero tiene un valor que depende de la plataforma (ver sección N.l. en lenguajes de programación, más abajo).

Esto causa problemas al comunicarse con sistemas que siguen más firmemente el estándar. Por ejemplo, el agente de correo qmail no acepta mensajes de sistemas que envíen solo LF en vez del CRLF requerido. Detalles, en inglés.

El estándar Unicode trata el problema definiendo un gran número de caracteres que las aplicaciones han de reconocer como terminadores de línea. Según [1]:

 LF:    Salto de línea, u000A
 CR:    Retorno de carro, u000D
 CR+LF: CR seguido por LF
 NEL:   Next Line, u0085
 FF:    Form Feed, u000C
 LS:    Line Separator, u2028
 PS:    Paragraph Separator, u2029

Parece demasiado complicado frente a otras posibles soluciones, como por ejemplo convertir todos los terminadores a un solo carácter como el LF, pero se ha hecho así para que la conversión pueda ser bidireccional.

Si transformamos un texto EBCDIC cambiando todos los NEL por LF, y luego lo queremos devolver a EBCDIC, no sabríamos si los LF de nuestra codificación corresponden a NEL o al propio LF de EBCDIC.

En Unicode, se puede hacer la transformación sin perder información, de forma que los programas siguen pudiendo reconocer todos los tipos posibles de terminadores de línea.

ASCII se desarrolló simultáneamente por el ISO y el ASA, la organización predecesora de ANSI. Durante el período 1963-1968, los borradores (preestándar) de ISO permitían usar tanto CRLF como LF para marcar una nueva línea, mientras que los borradores de ASA permitían solo CRLF.

El sistema operativo Multics empezó a desarrollarse en 1964 y usaba solo LF. Unix siguió la práctica de Multics, y sistemas posteriores siguieron a Unix.

La secuencia CR LF era común en los primeros ordenadores que tenían máquinas de teletipo (como el ASR33) como dispositivo de terminal. Esta secuencia era necesaria para posicionar el cabezal de la impresora al principio de una nueva línea. Como esta operación no se podía hacer en tiempo "1 carácter", había que dividirla en dos caracteres. A veces era necesario enviar CR LF NUL (siendo NUL el carácter de control que le manda "no hacer nada"), para asegurarse de que el cabezal de impresión parara de moverse. Después de que estos sistemas mecánicos desaparecieran, la secuencia CR LF dejó de tener sentido, pero aun así se ha seguido usando.

Se especula que QDOS (que Microsoft compró y renombró a MS-DOS) adoptó CRLF para copiar la implementación usada por CP/M. También se dice que CP/M eligió CR+LF para introducir una clara incompatibilidad con Unix, y así intentar evitar una posible denuncia de AT&T/Bell, que decía que CP/M violaba el copyright de Unix porque estaba basado en Unix (según esta teoría).

Otros creen que CP/M se parece más a los sistemas de DEC (como el RSTS/E) que a Unix. En cualquier caso, esta convención de QDOS pasó al siguiente sistema operativo comercializado por Microsoft, el Windows, y sigue igual en la actualidad (2006).

Para que sea más fácil crear programas portátiles, los lenguajes de programación ofrecen abstracciones para no tener que tratar con las pequeñas diferencias entre sistemas.

El lenguaje de programación C permite usar las secuencias de escape \n (nueva línea) y \r (retorno de carro). Sin embargo, éstas no son equivalentes a LF y CR en general. El estándar C solo garantiza dos cosas:

1. Cada una de estas secuencias se traduce a un número que cabe en un solo valor char, y que depende de la implementación.
2. Cuando se escribe a un fichero de tipo texto (en contraposición a un archivo binario), el \n se traduce de forma transparente al código de nueva línea nativo del sistema, que puede ser de más de un carácter. Cuando se lee en modo texto, la secuencia de nueva línea nativa se vuelve a traducir a \n. En modo binario no se hacen estas traducciones.

En las plataformas Unix, donde nació C, la secuencia que indica nueva línea es el código ASCII LF (0x0A), así que al principio se hizo que \n tuviera ese valor. Entonces, como la representación interna y la externa son idénticas, la traducción que hay que hacer en modo texto es nula, y modo texto y binario se comportan de la misma manera. Esto ha hecho que muchos programadores ignoren por completo la distinción, cosa que afecta al software desarrollado, que deja de ser portable.

Otro problema común es usar \n al comunicarse mediante un protocolo de red que requiere CRLF como terminador. En Windows funcionará, ya que \n se traduce a la representación nativa, que es precisament CR+LF, pero en Unix produce solo LF (la representación nativa del carácter nueva línea). Usar \r\n en modo binario es algo mejor, pero tampoco funciona en el caso general. Lo correcto es especificar los valores concretos, en modo binario; por ejemplo, \x0D\x0A

Perl y C++ ofrecen la misma interpretación de '\n' que C. C++ también tiene std::endl, que es la representación de una nueva línea en el sistema subyacente y vacía el stream después de emitirlo. Perl tiene un 'binmode' para las traducciones literales a la hora de leer y escribir en ficheros.

Java también proporciona las secuencias de escape \n y \r, que sí que garantizan que su valor será 0x0A y 0x0D respectivamente. Para que un programa hecho en Java se vea correctamente en el notepad, es necesario poner \r\n. Esto cobra vital importancia si se trata de comunicar nuestro programa en Java con un programa hecho en C mediando un archivo txt.

Las bibliotecas de entrada/salida de Java no traducen estas secuencias automáticamente, como en C. En cambio, ofrecen funciones para escribir una línea completa añadiendo el código nativo de nueva línea, y funciones para leer líneas que aceptan cualquier secuencia como terminador (CR, LF, CRLF).

Las diferentes representaciones de la nueva línea en los sistemas operativos a veces causan que al transferir un fichero entre dos ordenadores, se muestre incorrectamente. Por ejemplo, en condiciones normales, los ficheros creados en sistemas Unix o Apple Macintosh se verán como una línea larga en Windows. Y a la inversa: los ficheros creados en un ordenador con Windows se verán extraños con algunos editores, ya que el CR extra que Unix no necesita se mostrará como un ^M al final de cada línea.

El problema puede ser difícil de detectar si algunos programas manejan bien los terminadores de línea ajenos pero otros no. Por ejemplo, un compilador puede fallar con extraños mensajes de error aun cuando el fichero fuente se muestra correcto en la línea de comandos o un editor de texto.

Los navegadores web suelen poder trabajar con páginas codificadas en cualquier sistema, y los editores de texto modernos permiten no solo abrir ficheros de cualquier codificación, sino convertir entre ellas (ver siguiente sección).

Al transferir ficheros por FTP, el cliente puede convertir automáticamente entre diferentes codificaciones si está activado el modo de texto. Sin embargo, si se usa este modo para transferir un archivo binario, el fichero llegará corrupto. Los programas suelen usar heurísticos para detectar si un fichero es binario o no, pero pueden equivocarse.

En general, un editor de textos es el programa más conveniente para trabajar con ficheros que usan distintos terminadores de línea. La mayoría de editores modernos permiten cualquier combinación con los códigos de control ASCII CR y LF. Por desgracia, el editor predeterminado de Windows (Notepad) no lo permite, aunque Wordpad sí.

El programa de MS-DOS llamado EDIT también se puede usar para convertir un fichero que use los terminadores de línea de tipo Unix. Solo hay que abrir el archivo y volverlo a grabar.

En muchos sistemas Unix se encuentran las utilidades dos2unix y unix2dos, que transforman entre las codificaciones CRLF (DOS/Windows) y LF (Unix). Hay varias versiones de estos programas, con sintaxis algo distintas.

Se puede usar también el programa tr, que sí que está en cualquier sistema tipo Unix, y que permite hacer cualquier tipo de transformación de caracteres. Para pasar de DOS/Windows a Unix, eliminar todos los CR:

tr -d '\r' < fichero_entrada > fichero_salida

Y en la otra dirección: se puede convertir de Unix a DOS con sed:

sed -e 's/$/\r/' fichero_entrada > fichero_salida

En sistemas Unix está el comando file, que permite identificar el tipo de terminadores de línea que usa un fichero.

• Retorno de carro
• Salto de línea
• CRLF