此文講解的是vim編輯多字節(jié)編碼文檔（中文）所要了解的一些基礎知識，注意其沒有涉及gvim,，純指字符終端下的vim,。
vim編碼方面的基礎知識：

1，存在3個變量：
encoding—-該選項使用于緩沖的文本(你正在編輯的文件),，寄存器,，Vim 腳本文件等等,。你可以把 ‘encoding’ 選項當作是對 Vim 內部運行機制的設定。
fileencoding—-該選項是vim寫入文件時采用的編碼類型,。
termencoding—-該選項代表輸出到客戶終端（Term）采用的編碼類型,。
2，此3個變量的默認值：
encoding—-與系統(tǒng)當前l(fā)ocale相同,，所以編輯文件的時候要考慮當前l(fā)ocale,，否則要設置的東西就比較多了。
fileencoding—-vim打開文件時自動辨認其編碼,，fileencoding就為辨認的值,。為空則保存文件時采用encoding的編碼，如果沒有修改encoding,，那值就是系統(tǒng)當前l(fā)ocale了,。
termencoding—-默認空值，也就是輸出到終端不進行編碼轉換,。

由此可見,，編輯不同編碼文件需要注意的地方不僅僅是這3個變量，還有系統(tǒng)當前l(fā)ocale和,、文件本身編碼以及自動編碼識別,、客戶運行vim的終端所使用的編碼類型3個關鍵點，這3個關鍵點影響著3個變量的設定,。
如果有人問：為什么我用vim打開中文文檔的時候出現亂碼,？
答案是不確定的，原因上面已經講了,，不搞清楚這3個關鍵點和這3個變量的設定值,，出現亂碼是正常的，倒是不出現亂碼那反倒是湊巧的,。

再來看一下常見情況下這三個關鍵點的值以及在這種情況下這3個變量的值：
1,，locale—-目前大部分Linux系統(tǒng)已經將utf-8作為默認locale了，不過也有可能不是,，例如有些系統(tǒng)使用中文locale zh_CN.GB18030,。在locale為utf-8的情況下，啟動vim后encoding將會設置為utf-8,，這是兼容性最好的方式,，因為內部 處理使用utf-8的話，無論外部存儲編碼為何都可以進行無缺損轉換,。locale決定了vim內部處理數據的編碼,，也就是encoding。
2,，文件的編碼以及自動編碼識別—-這方面牽扯到各種編碼的規(guī)則,，就不一一細講了,。但需要明白的是，文件編碼類型并不是保存在文件內的,，也就是說沒有任何 描述性的字段來記錄文檔是何種編碼類型的,。因此我們在編輯文檔的時候,，要么必須知道這文檔保存時是以什么編碼保存的,，要么通過另外的一些手段來斷定編碼類 型，這另外的手段,，就是通過某些編碼的碼表特征來斷定,，例如每個字符占用的字節(jié)數，每個字符的ascii值是否都大于某個字段來斷定這個文件屬于何種編 碼,。這種方式vim也使用了,，這就是vim的自動編碼識別機制了。但這種機制由于編碼各式各樣,，不可能每種編碼都有顯著的特征來辨別,，所以是不可能 100%準確的。對于我們GB2312編碼,，由于其中文是使用了2個acsii值高于127的字符組成漢字字符的,，因此不可能把gb2312編碼的文件與 latin1編碼區(qū)分開來，因此自動識別編碼的機制對于gb2312是不成功的,，它只會將文件辨識為latin1編碼,。此問題同樣出現在gbk，big5 上等,。因此我們在編輯此類文檔時,，需要手工設定encoding和fileencoding。如果文檔編碼為utf-8時,，一般vim都能自動識別正確的 編碼,。

3，客戶運行vim的終端所使用的編碼類型—-同第二條一樣,，這也是一個比較難以斷定的關鍵點,。第二個關鍵點決定著從文件讀取內容和寫入內容到文件 時使用的編碼，而此關鍵點則決定vim輸出內容到終端時使用的編碼,，如果此編碼類型和終端認為它收到的數據的編碼類型不同,，則又會產生亂碼問題。在 linux本地X環(huán)境下,，一般終端都認為其接收的數據的編碼類型和系統(tǒng)locale類型相符,，因此不需關心此方面是否存在問題。但如果牽涉到遠程終端,，例 如ssh登錄服務器,，則問題就有可能出現了,。例如從1臺locale為GB2310的系統(tǒng)（稱作客戶機）ssh到locale為utf-8的系統(tǒng)（稱作服 務器）并開啟vim編輯文檔，在不加任何改動的情況下,，服務器返回的數據為utf-8的,，但客戶機認為服務器返回的數據是gb2312的，按照 gb2312來解釋數據,，則肯定就是亂碼了,，這時就需要設置termencoding為gb2312來解決這個問題。此問題更多出現在我們的 windows desktop機遠程ssh登錄服務器的情況下,，這里牽扯到不同系統(tǒng)的編碼轉換問題,。所以又與windows本身以及ssh客戶端有很大相關性。在 windows下存在兩種編碼類型的軟件,，一種是本身就為unicode編碼方式編寫的軟件,，一種是ansi軟件，也就是程序處理數據直接采用字節(jié)流,，不 關心編碼,。前一種程序可以在任何語言的windows上正確顯示多國語言，而后一種則編寫在何種語言的系統(tǒng)上則只能在何種語言的系統(tǒng)上顯示正確的文字,。對 于這兩種類型的程序,，我們需要區(qū)別對待。以ssh客戶端為例,，我們使用的putty是unicode軟件,，而secure CRT則是ansi 軟件。對于前者,，我們要正確處理中文,，只要保證vim輸出到終端的編碼為utf-8即可，就是termencoding=utf-8,。但對于后者,，一方面 我們要確認我們的windows系統(tǒng)默認代碼頁為cp936（中文windows默認值），另一方面要確認vim設置的termencoding= cp936,。

最后來看看處理中文文檔最典型的幾種情況和設置方式：

1,，系統(tǒng)locale是utf-8（很多l(xiāng)inux系統(tǒng)默認的locale形式），編輯的文檔是GB2312或GBK形式的（Windows記事本 默認保存形式,，大部分編輯器也默認保存為這個形式,，所以最常見），終端類型utf-8（也就是假定客戶端是putty類的unicode軟件）
則vim打開文檔后,，encoding=utf-8（locale決定的）,，fileencoding=latin1（自動編碼判斷機制不準導致的），termencoding=空（默認無需轉換term編碼），顯示文件為亂碼,。
解決方案1：首先要修正fileencoding為cp936或者euc-cn（二者一樣的,，只不過叫法不同），注意修正的方法不是:set fileencoding=cp936,，這只是將文件保存為cp936,，正確的方法是重新以cp936的編碼方式加載文件為:edit ++enc=cp936，可以簡寫為:e ++enc=cp936,。
解決方案2：臨時改變vim運行的locale環(huán)境,，方法是以LANG=zh_CN vim abc.txt的方式來啟動vim，則此時encoding=euc-cn（locale決定的）,，fileencoding=空（此locale下文件 編碼自動判別功能不啟用,，所以fileencoding為文件本身編碼方式不變,，也就是euc-cn）,，termencoding=空（默認值，為空則等 于encoding）此時還是亂碼的,，因為我們的ssh終端認為接受的數據為utf-8,，但vim發(fā)送數據為euc-cn，所以還是不對,。此時再用命令: set termencoding=utf-8將終端數據輸出為utf-8,，則顯示正常。

2,，情況與1基本相同,，只是使用的ssh軟件為secure CRT類ansi類軟件。

vim打開文檔后,，encoding=utf-8（locale決定的）,，fileencoding=latin1（自動編碼判斷機制不準導致的），termencoding=空（默認無需轉換term編碼）,，顯示文件為亂碼,。

解決方案1：首先要保證運行secure CRT的windows機器的默認代碼頁為CP936，這一點中文windows已經是默認設置了,。其他的與上面方案1相同,，只是要增加一步，:set termencoding=cp936

解決方案2：與上面方案2類似,，不過最后一步修改termencoding省略即可,，在此情況下需要的修改最少，只要以locale為zh_CN開 啟vim,，則encoding=euc-cn,，fileencoding和termencoding都為空即為encoding的值，是最理想的一種情 況。

可見理解這3個關鍵點和3個參數的意義,，對于編碼問題有很大助力,，以后就可以隨心所欲的處理文檔了，同時不僅僅是應用于vim,，在其他需要編碼轉換的環(huán)境里,，都可以應用類似的思路來處理問題解決問題。

最后推薦一款功能強大的windows下的ssh客戶端—-xshell,，它具有類似secure CRT一樣的多tab 的ssh窗口的能力,，但最為方便的是這款工具還有改變Term編碼的功能，這樣我們就可以不用頻繁調整termencoding,，只需在ssh軟件里切換 編碼即可,，這是我用過的最為方便的ssh工具。它是商業(yè)軟件,，但非注冊用戶使用沒有任何限制,，只是30天試用期超出后會每次啟動都提示注冊，對于功能沒有 絲毫影響,。