换行符\n和回车符\r

问题始于社区的一个帖子，楼主的问题如下：

“在c语言中，对一个不知道大小的文件进行读操作，我用fread（）将文件的内容先放到一个缓存区，然后将缓存区中的内容打印出来，

缓存区中的内容和文件中的内容不一样，好像是因为缓存区的空间比存储文件内容所需要的空间大了，不知道应该怎么解决”

这个问题我之前也碰到过，翻了一些C语言文件操作方面的资料，发现对于换行的处理，其实是一个从打字机时代就有的历史遗留问题：

“在计算机还没有出现之前，有一种叫做电传打字机（Teletype Model 33）的玩意，每秒钟可以打10个字符。但是它有一个问题，就是打

完一行换行的时候，要用去0.2秒，正好可以打两个字符。要是在这0.2秒里面，又有新的字符传过来，那么这个字符将丢失。 于是，研制人员

想了个办法解决这个问题，就是在每行后面加两个表示结束的字符。一个叫做“回车”，告诉打字机把打印头定位在左边界；另一个叫做“换行”，

告诉打字机把纸向下移一行。 ”

在计算机出现之后，这种概念又被移植到了计算机操作系统上。当然，对于是否移植这一点也是有争议的，Windows和Unix/Mac系统在这一点

上就分道扬镳了。

下面首先讨论在Windows平台下的情况。

Windows平台采用了历史的概念，在文件中，换行被处理为“\r\n”两个字符，也就是说，虽然用户只敲了一次回车键，但其实系统

会认为收到了“\r\n”两个字符，并同时存储了这两个字符。

因此，在Windows平台下，文件为了存储一次换行会写入两个字符。当程序员试图从文件中读取文件内容时，C语言提供了两种方式：文本方

式和二进制方式，这两种方式又有什么区别呢？

在Windows平台下，采用文本方式打开一个文件时，会自动将一次换行，即“\r\n”两个字符转换成一个“\n”字符，即会去掉一个“\r”

字符，这种转换的结果就是：实际读取的数据长度会比文件的真实长度短，两者之差等于文件中的换行次数。而当采用二进制方式打开

一个文件时，由于二进制方式打开的特点是有什么读什么，因此，“\r\n”两个字符会原封不动，均被读取，因而实际读取的数据长度与

原文件长度相同。

由于这种区别的存在，推荐大家在读取文件时采用二进制方式，文件中是什么内容，读取到的就是什么内容。

那么，在Unix平台下呢？

Unix/Mac平台并没有采用Windows平台的方式，在Unix/Mac中，每一行的结尾只有一个换行符，即“\n”，因此，Unix/Mac平台下两种读取方式

是不会有区别的。

一个直接后果是，Unix/Mac系统下的文件在Windows里打开的话，所有文字会变成一行；而Windows里的文件在Unix/Mac下打开的话，

某些文本编辑器可能在每行的结尾会多出一个^M符号。