`^ M` al final de cada línea de archivos de texto generados en Windows

10

Me preguntaba por qué si abres un archivo de texto hecho en el bloc de notas de Windows en Unix, ¿encontrarás que tiene ^Mdonde debería haber una nueva línea?

Entiendo que en Windows, cada línea termina con \r\n, es decir, 0x0D0Aen ASCII, mientras que ^Mtiene un valor ASCII 0x5E4D. No puedo relacionar estos dos de uno a otro.

character-encoding Tim
fuente
En Windows puede usar un mejor editor como Notepad ++. Le permitirá guardar los archivos con terminaciones de línea UNIX pero verlo en Windows como si tuviera terminaciones de línea de Windows. Entonces puedes verlo en ambos SO bien.
Kevin
Ver también la opinión de Jeff Atwood
nico

Respuestas:

19

Tienes razón acerca de que los finales de línea son importantes; ambos sistemas operativos esperan que la línea termine con "\ n", pero Windows también agrega un "\ r" antes de que unix no espere, por lo que los programas de Unix generarán "\ r" a su manera.

El archivo en realidad no termina con los dos caracteres "^" y "M", esa es solo una forma común de representar caracteres no imprimibles. Los programas mostrarán "^" y una letra correspondiente al valor del byte, comenzando con A para 1. M es la letra 13 y '\ r' es el código ASCII 13 (o 0xD, como usted dijo), así que verá "^ METRO"

Michael Mrozek
fuente
2
Eso también es una abreviatura de Ctrl-M, que es cómo obtienes ese personaje con el teclado.
Steven Pritchard
77
Puede utilizar las utilidades de línea de comandos dos2unixy unix2dosconvertir archivos de texto entre formatos.
Chris Nava
1
@Chris Es cierto, pero realmente no tiene nada que ver con la pregunta
Michael Mrozek
¡Gracias! (1) Me preguntaba qué programas generarán caracteres no imprimibles de esa manera. Por ejemplo, ¿todos los editores / visores de texto funcionan de esa manera? (2) ¿qué tipos de caracteres no imprimibles se tratan de esa manera y qué tipos no? Por ejemplo, ¿por qué no hacen el texto de salida de los espectadores ^Jpara \n?
Tim
1
La representación ^ M es anterior a los editores de texto GUI por años, si no décadas.
Chris Nava