一、回车与换行的来历
关于“回车”（carriage return）和“换行”（line feed）这两个概念的来历和区别。
在计算机还没有出现之前，有一种叫做电传打字机（Teletype Model 33）的玩意，每秒钟可以打10个字符。但是它有一个问题，就是打完一行换行的时候，要用去0.2秒，正好可以打两个字符。要是在这0.2秒里面，又有新的字符传过来，那么这个字符将丢失。
于是，研制人员想了个办法解决这个问题，就是在每行后面加两个表示结束的字符。一个叫做“回车”，告诉打字机把打印头定位在左边界；另一个叫做“换行”，告诉打字机把纸向下移一行。
这就是“换行”和“回车”的来历，从它们的英语名字上也可以看出一二。
后来，计算机发明了，这两个概念也就被般到了计算机上。那时，存储器很贵，一些科学家认为在每行结尾加两个字符太浪费了，加一个就可以。于是，就出现了分歧。
Unix系统里，每行结尾只有“<换行>”（LF），即“
”，对应十六进制数是0x0A；Windows系统里面，每行结尾是“ <回车><换行>”，即“
”；Mac系统里，每行结尾是“<回车>”（CR），对应十六进制数是0x0D。一个直接后果是，Unix/Mac系统下的文件在Windows里打开的话，所有文字会变成一行；而Windows里的文件在Unix/Mac下打开的话，在每行的结尾可能会多出一个^M符号。
windows创建的文件是 结束的， 而linux，mac这种unix类系统是 结束的。
所以unix的文本到windows会出现换行丢失（ultraedit这种软件可以正确识别）； 而反过来就会出现^M的符号了
Windows等操作系统用的文本换行符和UNIX/Linux操作系统用的不同，Windows系统下输入的换行符在UNIX/Linux下不会显示为“换行”，而是显示为 ^M 这个符号（这是Linux等系统下规定的特殊标记，占一个字符大小，不是 ^ 和 M 的组合，打印不出来的）。Linux下很多文本编辑器（命令行）会在显示这个标记之后，补上一个自己的换行符，以避免内容混乱（只是用于显示，补充的换行符不会写入文件，有专门的命令将Windows换行符替换为Linux换行符）。 UNIX/Linux系统下的换行符在Windows系统的文本编辑器中会被忽略，整个文本会乱成一团。
所以在linux保存的文件在windows上用记事本看的话会出现黑点，我们可以在LINUX下用命令把linux的文件格式转换成win格式的。
二、C语言中的处理
毕竟是源自Unix系统，C语言中使用
表示换行，而在实际的文件中换行符号需要同操作系统一致，所以当我们在C中使用fopen打开一个文本文件时流实现了实际换行符与C中
之间的转换。在windows中当我们用fopen打开文本文件，然后从中读到
时流会转换为
，而当我们往文件中写入
时流会转换为
。以二进制模式打开流不会做任何处理。
当我们使用标准输入输出函数时有这种情况吗？
C的控制台程序在加载进内存成为进程运行前C运行时库自动打开三个设备并关联到三个流：标准输入流stdin，标准输出流stdout，标准出错流stderr。
通常在通用计算机中，没有重定向前这三个流对应的设备是：键盘，显示器，显示器。这三个都是字符设备，所以是以文本文件的模式打开的，在windows下当我们在键盘上敲入回车键时产生字符
，但是在OS内核把键盘驱动中读到的字符发送给流的缓冲区时流会将之转换为
，当我们向控制台输出
时流将之转换为
再传递至内核，当我们绕过标准输入输出直接调用windows中coredll.lib进行控制台输入输出时就必须面对这一现实，程序员负责实现这一转换。
文本文件的行结束符一律变成一个符号LF,也就是换行符,也就是new line符, 也就是' '。“回车和换行符转换成一个换行符”-- 对PC机而言,文本文件行结束符,CRLF读入后,丢掉CR,留 LF。例如fgets() 读入一行,行尾只有LF,没有CR.
三、编码建议
以下是Quantum Leaps公司给出的编码规范中关于EOL的一段，摘录如下，
All source code should consistently use only one end-of-line convention. For improved portability,
this Standard recommends consistent use of the Unix™ end-of-line convention, with only one LF
character (0x0A) terminating each line. The DOS/Windows end-of-line convention with CR, LF
character pair (0x0D, 0x0A) terminating each line is not recommended because it causes compilation
problems on Unix™-like systems, such as Linux™. (Specifically, the C preprocessor doesn’t correctly
parse the multi-line macros.) On the other hand, most DOS/Windows compilers seem to tolerate the
Unix™ EOL convention without problems.