Caracteres de salto de línea
Mix entre un artículo de Xavier Noria sobre el famoso\ny datos de Wikipedia.
¿Qué es \n?
Por razones históricas no existe un único código para representar inequívocamente una nueva línea. El código ASCII 10 (0×0A) se conoce técnicamente como “new line”, pero la actual representación de newlines depende del sistema operativo o de la aplicación corriendo sobre éste.
Los códigos usados para representar newlines en sistemas basados en ASCII son:
- LF: Line Feed,
"\cJ", Unicode000A, ASCII0x0A,012,10. - CR: Carriage Return,
"\cM", Unicode000D, ASCII0x0D,015,13. - CRLF: Ambos códigos juntos y en este orden.
Entonces, tenemos que existen tres tipos distintos de newlines, dependiendo del SO que se trate:
- LF: Unix y sistemas tipo Unix como Linux, Mac OS X, AIX, Xenix, BeOS, Amiga, RISC OS y otros.
- CR: Familia Apple II y Mac OS hasta la versión 9.
- CRLF: Microsoft Windows, WinCE, DOS, OS/2, CP/M, MP/M, y otros.
Si abrimos un editor de texto, en tres computadoras distintas corriendo un SO de cada una de estas tres familias, y escribimos “x + Return + y" en cada una y guardamos el archivo, el resultado en disco es distinto. De acuerdo con la nomenclatura explicada arriba, veríamos estos bytes:
- Ubuntu GNU/Linux:
120.10.121 - Mac OS 9:
120.13.121 - Windows NT:
120.13.10.121
¿De dónde viene CRLF?
La secuenciaCR LFera 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 enviarCR LF NUL(siendoNULel 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 secuenciaCR LFdejó de tener sentido, pero aún así se ha seguido usando.
Problemas comunes
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 con Windows se verán extraños con algunos editores, ya que elCRextra que Unix no necesita se mostrará como un ^M al final de cada línea. Caso típico cuando editamos en VI un archivo proveniente de Windows.
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 aún 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 sólo 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. Si el modo es binario, el fichero llegará corrupto. Los programas suelen usar heurísticos para detectar si un fichero es binario o no, pero pueden equivocarse.
Utilidades de conversión
En muchos sistemas Unix se encuentran las utilidadesdos2unixyunix2dos, que transforman entre las codificacionesCRLF(DOS/Windows) yLF(Unix). Hay varias versiones de estos programas, con sintaxis algo distintas.
Se puede usar también el programatr, 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:
Y en la otra dirección: se puede convertir de Unix a DOS con sed:
En sistemas Unix está el comandofile, que permite identificar el tipo de terminadores de línea que usa un fichero.
