理解 CRLF，LF

CRLF, LF 是用來表示文字換行的方式。CR(Carriage Return) 代表回車，對應字元 '\r'；LF(Line Feed) 代表換行，對應字元 '\n'。由於歷史原因，不同的作業系統文字使用的換行符各不相同。主流的作業系統一般使用CRLF或者LF作為其文字的換行符。其中，Windows 系統使用的是 CRLF, Unix系統(包括Linux, MacOS近些年的版本) 使用的是LF。

系統間的這個差異給跨平臺協作開發和跨平臺執行帶來很多不方便的地方。最近寫的程式碼就遇到了這個問題。下面是一段按行讀取配置檔案的 Golang 程式碼，在讀取一行字元之後，去掉開頭結尾的換行符與空格。我是這樣寫的：

fun InterpretQueryLine(data []byte) {
    str_line := strings.Trim(string(data), " \n")
    // ...
}

本來在自己的 Ubuntu 系統上跑的很好，覺得沒bug就提交了。然而，同事使用的是Windows系統，他編譯之後怎麼跑都不正常。由於我對 Golang 不熟悉，除錯了很久才發現是換行符的問題。在Windows系統上換行符是CRLF, \r\n兩個字元，只刪除\n是不夠的。所以在讀取檔案的時候一定要小心跨平臺。

除了上面的問題，我們平常受到換行符問題的困擾更多來自協作開發工具，比如Git。有時候我們只改了原始碼中的一行，但提交的時候發現整個檔案都被修改了。有時候拉取最新的分支，明明改動不大，但是在與本地合併的時候整個檔案都是衝突。這些問題不會導致嚴重的錯誤，但是會給開發帶來非常大的不方便。

下面介紹兩個 Git 中換行符相關的處理方式：

這裡先指定兩個非官方的概念，方便後面解釋與描述：(重要，否則後面看不懂)

1. 標準化 指在提交程式碼到git資料庫(本地庫) 中將文字檔案中的換行符CRLF轉為LF的過程
2. 轉換 指在檢出Git資料庫程式碼過程中將文字檔案中的換行符LF轉換為CRLF的過程

core.autocrlf & core.safecrlf

Git 提供了一個名為 core.autocrlf 的配置，可以自動完成標準化與轉換。它的設定方式如下：

git config --global core.autocrlf  [true | input | false]  # 全域性設定
git config --local core.autocrlf  [true | input | false] # 針對本專案設定

• true 自動完成標準化與轉換
• input 只做標準化操作，不做轉換操作
• false 提交與檢出的程式碼都保持檔案原有的換行符不變

1. CRLF 與 LF 混合的文字檔案不受此配置控制。
2. Git 安裝後預設為 false

所以，一種規範換行符的方式是這樣的：
使用 Windows 系統的開發者設定：

git config --global core.aurocrlf true

使用 Linux/MacOS 的開發者設定：

git config --global core.autocrlf input

由於沒有一個絕對有效的演算法來判斷一個檔案是否為文字，所以Git 提供了一項禁止/警告不可逆轉換的配置來防止錯誤的標準化與轉換。它主要是影響到多種換行符混合的檔案，我們可以手動將其轉換為同一種換行符：

git config --global core.safecrlf [true | false | warn]

• true 禁止提交混合換行符的文字檔案(git add 的時候會被攔截，提示異常)
• warn 提交混合換行符的文字檔案的時候發出警告，但是不會阻止 git add 操作
• false 不禁止提交混合換行符的文字檔案（預設配置）

.gitattributes 檔案

core.autocrlf 的配置依賴於每一位參與專案的開發機器上的配置，這很難確保每個人都能正確配置。於是在規範專案中的換行符方面，還有一套新增配置檔案的方案。在專案的根目錄下可以新增一個.gitattributes 檔案。它的優先順序高於core.autocrlf的設定，可以覆蓋core.autocrlf的。它類似於 .gitignore 檔案，隨提交修改生效，一個專案中可以維持一份相同的配置。所以，它能夠避免每個開發人員配置不同的問題。

.gitattributes檔案的功能不只有配置換行符，所以它的配置相對複雜一下。詳細的說明文件可以參考 地址。這裡只針對換行符的配置做一下簡單的介紹：

每行基本形式：

filter attr1 attr2 ....

filter 代表匹配檔案的萬用字元，在它後面跟著相應的屬性，用空格間隔。

filter 的選項比較簡單，常見的：

* 匹配所有檔案
*.txt  匹配檔名以txt結尾的檔案

attr的選擇比較多，其中與換行符相關的屬性只有幾條：

• text
  • text 自動完成標準化與轉換
  • -text 不執行標準化與轉換
  • text=auto 根據 Git 決定是否需要執行標準化與轉化
  • 不設定 使用core.autocrlf配置決定是否執行標準化與轉換
• eol
  • eol=lf 強制完成標準化，不執行轉換（相當於指定轉換為LF格式）
  • eol=crlf 強制完成標準化，指定轉換為CRLF格式
• binary
  • binary 二進位制檔案不參與標準化與轉換
  • 不設定 由 Git 決定是否為二進位制檔案

text 設定的時候，轉換自動轉換到對應平臺的換行符
行號高的設定會覆蓋行號低的設定

這裡給出一個簡單的例子來說明一下：

*         text=auto
# These files are text and should be normalized (convert crlf => lf)
*.cs      text
*.xaml    text
*.csproj  text
*.sln     text
*.tt      text
*.ps1     text
*.cmd     text
*.msbuild text
*.md      text

# Images should be treated as binary
# (binary is a macro for -text -diff)
*.png     binary
*.jepg    binary

*.sdf     binary

除了下面匹配到的檔案，剩下的依賴Git 決定是否參與標準化與轉換。上面一段是參與標準化與轉換的檔案；下面一段是不參與標準化與轉換的檔案；

其實，在檔案裡只有下面這行配置的時候，就相當於根據作業系統自動填入 core.autocrlf 的設定。

* text=auto

所以，這裡推薦使用.gitattributes來規範專案中換行符。簡單，方便，靈活。

參考文章：

• [1] Mind the End of Your Line
• [2] gitattributes(5) Manual Page

我的部落格即將搬運同步至騰訊雲+社群，邀請大家一同入駐：https://cloud.tencent.com/developer/support-plan?invite_code=3ld8ip2y3rsw8