前几日项目开发过程中遇到了一个问题，代码中新增了 shell 脚本，但是打包放到服务器上执行时，发生了 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符号。
参考文章1（阮一峰）
参考文章2

不同 OS 中的换行符

Window 中的文本文件换行符是 \r\n ，也就是 CRLR，对应 ASCII 码表中的 0xOD0A；而类 Unix 中换行符则为 \n ，也就是 LF（line feed），ASCII 码为 0x0A；早期 MAC 操作系统则为 \r ，也就是 CR（carriage return）， ASCII 码为 0x0D，后来与 Unix 保持一致了。
这次开发过程中遇到的问题就是，在 windows 写完的 shell 脚本是 CRLF 换行符，结果打包解压到服务器上后，执行脚本时就因为这个 CRLF 换行符问题报了个语法错误。

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

  
  
  

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

Git 中的问题

git 中有换行符转换功能，Windows 下，Git 会将 UNIX 换行符（LF）替换为 Windows 的换行符（CRLF）；而在提交文件时，它又会将 CRLF 替换为 LF，据说有坑，详见 > 参考文章3。Windows 下安装 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

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

git config --global core.autocrlf input
git config --global core.safecrlf true

参考文章4

IDEA 中设置换行符

File > Settings > Editor > Code Style > 通过 Line separator 设置即可，设置完毕新建的文件都会以设置的换行符来换行。单个文件设置如下图（IDEA右下角）：