Git 中换行符问题处理

chify2020-05-142022-04-27

项目开发中遇到了一个问题：代码中新增了 shell 脚本，打包放到服务器上执行时，因不同 OS 系统换行符不同而导致执行报错。粗略解决后，写篇博客记录一下。

`\r` 和 `\n` 区别

\r (return)：回车，回到本行的行首
\n (newline)：换行，到下一行的行首

其历史渊源如下：

在计算机还没有出现之前，有一种叫做电传打字机（Teletype Model 33）的玩意，每秒钟可以打 10 个字符。但是它有一个问题，就是打完一行换行的时候，要用去 0.2 秒，正好可以打两个字符。要是在这 0.2 秒里面，又有新的字符传过来，那么这个字符将丢失。
于是，研制人员想了个办法解决这个问题，就是在每行后面加两个表示结束的字符。一个叫做”回车”，告诉打字机把打印头定位在左边界；另一个叫做”换行”，告诉打字机把纸向下移一行。
这就是”换行”和”回车”的来历，从它们的英语名字上也可以看出一二。
后来，计算机发明了，这两个概念也就被搬到了计算机上。那时，存储器很贵，一些科学家认为在每行结尾加两个字符太浪费了，加一个就可以。于是，就出现了分歧。
Unix 系统里，每行结尾只有”<换行>”，即 \n；Windows 系统里面，每行结尾是”<回车><换行>”，即 \r\n；Mac 系统里，每行结尾是”<回车>”。一个直接后果是，Unix/Mac 系统下的文件在 Windows 里打开的话，所有文字会变成一行；而 Windows 里的文件在 Unix/Mac 下打开的话，在每行的结尾可能会多出一个 ^M 符号。

参考文章（阮一峰）

不同 OS 中的换行符

Windows 中的文本文件换行符是 \r\n，也就是 CRLF，对应 ASCII 码表中的 0x0D 0x0A
类 Unix 系统中换行符为 \n，也就是 LF（line feed），ASCII 码为 0x0A
早期 Mac 操作系统则为 \r，也就是 CR（carriage return），ASCII 码为 0x0D，后来与 Unix 保持一致

这次开发中遇到的问题就是：在 Windows 写完的 shell 脚本是 CRLF 换行符，打包解压到服务器上后，执行时因换行符问题报了语法错误。

Notepad++ 解决办法

使用 Notepad++ 编辑打开文件，点击：视图 > 显示符号 > 显示所有符号，显示结果如下：

notepad++ 解决办法

点击：编辑 > 文档格式转换 > 选择相应 OS 的换行符，Notepad++ 会自动替换换行符。

Git 中的问题

Git 中有换行符转换功能：Windows 下，Git 会将 Unix 换行符（LF）替换为 Windows 的换行符（CRLF）；而在提交文件时，它又会将 CRLF 替换为 LF，据说有坑，详见参考文章3。Windows 下安装 Git 客户端时可以直接关掉自动转换功能，如下：

git 中的问题

安装时没有关闭，也可以使用如下命令将换行符转换功能关闭，具体解释如下：

# 提交时转换为 LF，检出时转换为 CRLF
git config --global core.autocrlf true
# 提交时转换为 LF，检出时不转换
git config --global core.autocrlf input
# 提交检出均不转换
git config --global core.autocrlf false

autocrlf 设置为 false 时，提交和检出代码时都不会转换换行符，另一个配置 safecrlf 最好设置为 true，具体作用如下：

# 拒绝提交包含混合换行符的文件
git config --global core.safecrlf true
# 允许提交包含混合换行符的文件
git config --global core.safecrlf false
# 提交包含混合换行符的文件时给出警告
git config --global core.safecrlf warn

个人建议配成下面这个样子：