知无涯之回车换行的故事
不知各位有没有过这样的经历：
- Linux上创建的文件在Windows上打开时，结果所有内容会挤成一行。而Windows上创建的文件在Linux上打开时，每一行的结尾又多了一个奇怪字符
^M。 - 在安装Windows版的git时，安装向导在某一步会提示你选择”Configuring the line ending conversions”，里面提到了Windows-style和unix-style的line endings，为什么会有这些呢？
- 调用C语言的API
fopen时，会有text mode和binary mode，这两者有什么区别？
其实这一切都和我们常说的回车换行有关，但你有没有很奇怪，什么是回车？直接用换行不就好了，为什么要分开两个词？我们使用的键盘上的键明明起得是换行的作用，为什么叫回车？千万别被绕晕了，本文将和大家讨论有关回车换行的一段有趣的历史，随后将回答这些问题。
目录
历史
我们通常所说的回车换行其实只相当于一个概念，即一行结束，开始下一行，英文叫做End-of-Line，简写为EOL。你也可以将这理解为一个逻辑上的换行，但为了与回车换行中的换行区分开来，我们后面还是称呼它为EOL。
打字机
回车换行严格说起来是两个独立的概念，即回车和换行，它们的出现要追溯到计算机出现之前，那时有一种电传打字机：Teletype Model 33 ASR，如下图：
在打字机上，有一个部件叫Carriage，它是打字头，相当于打字机的光标。每输入一个字符，Carriage就前进一格。当输满一行后，想要切换到下一行时，需要Carriage在两个方向上的运动：水平和竖直。水平方向上需要将Carriage移到一行的起始位置，竖直方向上需要纸张向上移动一行，此时也就是相当于Carriage下移了一行。（这在很多影视作品里面可以看到，打字者们打完一行之后，通常会用手拨动一个滑块，然后听到“咔”的一声，接着输入下一行。只是在这款打字机中不再需要人为的去拨动。）而这两个动作分别对应着：
- Carriage Return(CR)，也即回车，它在ASCII表中的值为0x0D，可以用转义符
\r表示 - Line Feed(LF)，也即换行，它在ASCII表中的值为0x0A，可以用转义符
\n表示
因为打字机是机械的结构，所以虽然从逻辑上只表示为EOF，但从设计上它需要分为两个独立的操作，这也正是我们习惯连起来说回车换行的原因。可以参照下图看看其键盘的布局：
键盘的右方有一个Line Feed和Return，从名字可以看出，这分别对应着前面提到的两个操作。然而，通常一个回车操作不能够在一个字符打印的时间内完成，所以可以利用Carriage移动的时间，去完成另外一个完全独立的操作Line Feed，这也是通常Carriage Return会被放在Line Feed前面的原因。你可以想象，如果在在Carriage和纸移动的过程中按下了其它的字符键，打印的内容将变得十分混乱。所以在Carriage Return和Line Feed之后，有时会有1~3个NUL字符(即相当于汇编语言中的空指令，仅起占位作用)，以等待前两个操作的完成。所以实际上打字机的EOL为：EOL = CR + LF + 1~3NUL。
分歧出现
等到早期的计算机发明时，很自然的这两个概念被拿了过来。但是由于那时的存储设备非常昂贵，一些人认为在每行的结尾加两个字符用于换行，实在是极大的浪费，于是各个厂商在这一点上便出现了分歧。
由于一些早期的微型计算机还没有用于隐藏底层硬件细节的设备驱动，所以它们直接沿用了打字机的惯例，使用不带NUL的CRLF作为一个EOL。而CP/M为了和这些微型计算机使用同一个终端，也采用了这种设计。所以它的克隆MS-DOS也同样使用CRLF，由于Windows又是基于MS-DOS，为保持兼容性，所以就导致了如今的Windows是采用CRLF作为EOL，即\r\n(或0x0D 0x0A)。
而Multics在被设计之时就非常认真的考虑了这一问题，设计者们觉得只需一个字符便完全足够来表示EOL，这样更加合理。那么选择CR还是LF呢？本来由于那时的键盘上都有一个Return键，所以可能更好的选择是CR。但当时考虑到CR可以用来重写一行，以完成如粗体和删除线等效果，所以他们选择了稍稍难以理解的LF。然后自己设计了一个设备驱动程序来将LF转换为各种打字机所需要的EOL，这个方案非常完美，当然除了LF稍微奇怪一些。随后一脉相承的Unix和Linux们都继承了这个选择，于是你在这些操作系统上可以发现每一行的结尾是一个LF，即\n(或0x0A)。
Mac系统的选择就更加复杂一些。Apple在设计Mac OS时，他们采用了一个最容易理解的选择：CR，即\r(或0x0D)。但这只维持到Mac OS 9，后一个版本的Mac OSX基于Mach-BSD内核，所以此后版本的Mac OSX在每行的结尾存储了与Linux一样的LF，即\n(或0x0A)。
混乱的状况
还有很多其它的操作系统采用更加不同的方案，这也导致了混乱的产生，文章开始提出的几个问题便由该混乱引起。因为Linux和Mac OSX上使用的是LF，而Windows上使用的是CRLF，那么Linux和Mac OSX上创建的文件在Windows上打开时，由于每一行的结尾只有一个LF，但Windows只认识CRLF，所以便不会有逻辑上的换行处理，故所有的文字被挤到了一行。反过来，如果Windows上的文件在Linux和Mac OSX上打开时，仅需LF便可换行，那么每一行的结尾便多了一个CR，对应的ASCII码为^M。
而git的安装向导会特意有一个这样的提醒页面也出于此，因为一个项目可能有多个开发者，每个开发者可能使用的是不同的系统，那么开发者checkout代码时，如果不做换行符的转换，有可能就会出现只有一行或者行尾多了^M的情况。当然，如果你有一个可以识别多种EOL的现代文本编辑器，那么不做转换也无妨(notepad不行)。
如果出现了上面的转换问题时，也别着急，可以...
剩余内容已隐藏