vim encoding

在 Vim 中，有四個與編碼有關的選項，它們是：fileencodings、fileencoding、encoding 和 termencoding。在實際使用中，任何一個選項出現錯誤，都會致使出現亂碼。所以，每個 Vim 用戶都應該明確這四個選項的含義。下面，咱們詳細介紹一下這四個選項的含義和做用。

1 encoding

encoding 是 Vim 內部使用的字符編碼方式。當咱們設置了 encoding 以後，Vim 內部全部的 buffer、寄存器、腳本中的字符串等，全都使用這個編碼。Vim 在工做的時候，若是編碼方式與它的內部編碼不一致，它會先把編碼轉換成內部編碼。若是工做用的編碼中含有沒法轉換爲內部編碼的字符，在這些字符就會丟失。所以，在選擇 Vim 的內部編碼的時候，必定要使用一種表現能力足夠強的編碼，以避免影響正常工做。

因爲 encoding 選項涉及到 Vim 中全部字符的內部表示，所以只能在 Vim 啓動的時候設置一次。在 Vim 工做過程當中修改encoding 會形成很是多的問題。若是沒有特別的理由，請始終將 encoding 設置爲 utf-8。爲了不在非 UTF-8 的系統如 Windows 下，菜單和系統提示出現亂碼，可同時作這幾項設置：

set encoding=utf-8
set langmenu=zh_CN.UTF-8
language message zh_CN.UTF-8

2 termencoding

termencoding 是 Vim 用於屏幕顯示的編碼，在顯示的時候，Vim 會把內部編碼轉換爲屏幕編碼，再用於輸出。內部編碼中含有沒法轉換爲屏幕編碼的字符時，該字符會變成問號，但不會影響對它的編輯操做。若是 termencoding 沒有設置，則直接使用encoding 不進行轉換。

舉個例子，當你在 Windows 下經過 telnet 登陸 Linux 工做站時，因爲 Windows 的 telnet 是 GBK 編碼的，而 Linux 下使用 UTF-8 編碼，你在 telnet 下的 Vim 中就會亂碼。此時有兩種消除亂碼的方式：一是把 Vim 的 encoding 改成 gbk，另外一種方法是保持 encoding 爲 utf-8，把 termencoding 改成 gbk，讓 Vim 在顯示的時候轉碼。顯然，使用前一種方法時，若是遇到編輯的文件中含有 GBK 沒法表示的字符時，這些字符就會丟失。但若是使用後一種方法，雖然因爲終端所限，這些字符沒法顯示，但在編輯過程當中這些字符是不會丟失的。

對於圖形界面下的 GVim，它的顯示不依賴 TERM，所以 termencoding 對於它沒有意義。在 GTK2 下的 GVim 中，termencoding 永遠是 utf-8，而且不能修改。而 Windows 下的 GVim 則忽略 termencoding 的存在。

3 fileencoding

當 Vim 從磁盤上讀取文件的時候，會對文件的編碼進行探測。若是文件的編碼方式和 Vim 的內部編碼方式不一樣，Vim 就會對編碼進行轉換。轉換完畢後，Vim 會將 fileencoding 選項設置爲文件的編碼。當 Vim 存盤的時候，若是 encoding 和fileencoding 不同，Vim 就會進行編碼轉換。所以，經過打開文件後設置 fileencoding，咱們能夠將文件由一種編碼轉換爲另外一種編碼。可是，由前面的介紹能夠看出，fileencoding 是在打開文件的時候，由 Vim 進行探測後自動設置的。所以，若是出現亂碼，咱們沒法經過在打開文件後從新設置 fileencoding 來糾正亂碼。

4 fileencodings

編碼的自動識別是經過設置 fileencodings 實現的，注意是複數形式。fileencodings 是一個用逗號分隔的列表，列表中的每一項是一種編碼的名稱。當咱們打開文件的時候，VIM 按順序使用 fileencodings 中的編碼進行嘗試解碼，若是成功的話，就使用該編碼方式進行解碼，並將 fileencoding 設置爲這個值，若是失敗的話，就繼續試驗下一個編碼。

所以，咱們在設置 fileencodings 的時候，必定要把要求嚴格的、當文件不是這個編碼的時候更容易出現解碼失敗的編碼方式放在前面，把寬鬆的編碼方式放在後面。

例如，latin1 是一種很是寬鬆的編碼方式，任何一種編碼方式獲得的文本，用 latin1 進行解碼，都不會發生解碼失敗——固然，解碼獲得的結果天然也就是理所固然的「亂碼」。所以，若是你把 latin1 放到了 fileencodings 的第一位的話，打開任何中文文件都是亂碼也就是理所固然的了。

如下是滇狐推薦的一個 fileencodings 設置：

set fileencodings=ucs-bom,utf-8,cp936,gb18030,big5,euc-jp,euc-kr,latin1

其中，ucs-bom 是一種很是嚴格的編碼，非該編碼的文件幾乎沒有可能被誤判爲 ucs-bom，所以放在第一位。

utf-8 也至關嚴格，除了很短的文件外(例如許多人津津樂道的 GBK 編碼的「聯通」被誤判爲 UTF-8 編碼的經典錯誤)，現實生活中通常文件是幾乎不可能被誤判的，所以放在第二位。

接下來是 cp936 和 gb18030，這兩種編碼相對寬鬆，若是放前面的話，會出現大量誤判，因此就讓它們靠後一些。cp936 的編碼空間比 gb18030 小，因此把 cp936 放在 gb18030 前面。

至於 big五、euc-jp 和 euc-kr，它們的嚴格程度和 cp936 差很少，把它們放在後面，在編輯這些編碼的文件的時候必然出現大量誤判，但這是 Vim 內置編碼探測機制沒有辦法解決的事。因爲中國用戶不多有機會編輯這些編碼的文件，所以咱們仍是決定把 cp936 和 gb18030 前提以保證這些編碼的識別。

最後就是 latin1 了。它是一種極其寬鬆的編碼，以致於咱們不得不把它放在最後一位。不過惋惜的是，當你碰到一個真的 latin1 編碼的文件時，絕大部分狀況下，它沒有機會 fall-back 到 latin1，每每在前面的編碼中就被誤判了。不過，正如前面所說的，中國用戶沒有太多機會接觸這樣的文件。

若是編碼被誤判了，解碼後的結果就沒法被人類識別，因而咱們就說，這個文件亂碼了。此時，若是你知道這個文件的正確編碼的話，能夠在打開文件的時候使用 ++enc=encoding 的方式來打開文件，如：

:e ++enc=utf-8 myfile.txt

5 fencview

根據前面的介紹，咱們知道，經過 Vim 內置的編碼識別機制，識別率是很低的，尤爲是對於簡體中文 (GBK/GB18030)、繁體中文 (Big5)、日文 (euc-jp) 和韓文 (euc-kr) 之間的識別。而對於普通用戶而言，肉眼看出一個文件的編碼方式也是很不現實的事情。所以，滇狐強烈推薦水木社區的 mbbill 開發的 fencview 插件。該插件使用詞頻統計的方式識別編碼，正確率很是高。點擊這裏 下載。