【随笔】不同系统间以及git软件仓库的行尾坑（LF和CRLF）

不同操作系统间的文本行尾差异

首先要明确CR和LF的概念：

CR= Carriage Return= 回车= \r
LF= Line Feed= 换行= \n
Windows=CRLF=\n\r
Unix系=LF=\n——包括linux&mac

Windows操作系统与Unix系操作系统的默认行尾符是不一样的，这直接影响到所有能够以文本形式读写的文件。

比如在Windows下新建一个文本文件（各种语言的源代码、脚本、html、json、纯文本等本质上都是文本文件），会默认每一行的结束符为/n/r，如果把这个文件复制到Linux下用vim打开，则会显示每一行有一个未知字符^M，即Linux只能识别\n字符，而无法识别\r字符。如果这个文件是一个shell脚本，那么必然执行失败。

github的行尾转换（可能导致项目崩溃的bug）

github为了解决这个问题，添加了自动转换行尾符的功能，在提交到远程仓库时，会根据git的设置自动静默修改文件内容，然而这个功能又创造了另一个大坑。

非代码文本文件（如字体、矢量图等）

这类文件有着特定的内容规范，独立于系统，内部选择CRLF/LF完全由自己决定，用不着外部插手，一旦被外部修改则文件损坏。github的坑就在这里，如果没有设置好，那么就会篡改项目里的字体、矢量图等文件，导致文件崩坏。我不知道版本回退能否恢复，但版本回退只是亡羊补牢而已，并不能否认这个问题的严重性。已经有很多人中招