更改vim編碼

在Linux下咱們常常會遇到編碼不一致致使顯示亂碼的問題,其實Vim給咱們提供了至關強大的編碼轉換命令,包括文檔編碼和顯示編碼. 



        在Vim中輸入:set fenc=編碼  便可將文檔的編碼轉換爲相應的編碼格式,這是隻須要保存文檔,文檔的編碼就變了. 



        若是在Vim中輸入:set enc=編碼  便可改變Vim的顯示編碼,這是就能夠看到文檔中的亂碼了,不過這是即便對文檔作了修改並保存,文檔仍舊以以前的文檔編碼保存. 



        其實使用中咱們常常用到的編碼有:gbk utf-8 big5 cp936.若是須要轉換其餘編碼能夠本身變動. 

set fenc=utf-8 

set enc=gb2312 

此文講解的是vim編輯多字節編碼文檔（中文）所要了解的一些基礎知識，注意其沒有涉及gvim，純指字符終端下的vim。 
vim編碼方面的基礎知識： 
1，存在3個變量： 
encoding—-該選項使用於緩衝的文本(你正在編輯的文件)，寄存器，Vim 腳本文件等等。你能夠把 ‘encoding’ 選項看成是對 Vim 內部運行機制的設定。 
fileencoding—-該選項是vim寫入文件時採用的編碼類型。 
termencoding—-該選項表明輸出到客戶終端（Term）採用的編碼類型。 
2，此3個變量的默認值： 
encoding—-與系統當前locale相同，因此編輯文件的時候要考慮當前locale，不然要設置的東西就比較多了。 
fileencoding—-vim打開文件時自動辨認其編碼，fileencoding就爲辨認的值。爲空則保存文件時採用encoding的編碼，如 果沒有修改encoding，那值就是系統當前locale了。 
termencoding—-默認空值，也就是輸出到終端不進行編碼轉換。 
因而可知，編輯不一樣編碼文件須要注意的地方不只僅是這3個變量，還有系統當前locale和、文件自己編碼以及自動編碼識別、客 戶運行vim的終端所使用的編碼類型3個關鍵點，這3個關鍵點影響着3個變量的設定。 
若是有人問：爲何我用vim打開中文文檔的時候出現亂碼？ 
答案是不肯定的，緣由上面已經講了，不搞清楚這3個關鍵點和這3個變量的設定值，出現亂碼是正常的，卻是不出現亂碼那反卻是湊巧的。 
再來看一下常見狀況下這三個關鍵點的值以及在這種狀況下這3個變量的值： 
1，locale—-目前大部分Linux系統已經將utf-8做爲默認locale了，不過也有可能不是，例若有些系統使用中文locale zh_CN.GB18030。在locale爲utf-8的狀況下，啓動vim後encoding將會設置爲utf-8，這是兼容性最好的方式，由於內部處理使用utf-8的話，不管外部存儲編碼爲什麼均可以進行完好損轉換。locale決定了vim內部處理數據的編碼，也就是encoding。 
2，文件的編碼以及自動編碼識別—-這方面牽扯到各類編碼的規則，就不一一細講了。但須要明白的是，文件編碼類型並非保存在文件內的，也就是說沒有任何 
描述性的字段來記錄文檔是何種編碼類型的。所以咱們在編輯文檔的時候，要麼必須知道這文檔保存時是以什麼編碼保存的，要麼經過另外的一些手段來判定編碼類 
型，這另外的手段，就是經過某些編碼的碼錶特徵來判定，例如每一個字符佔用的字節數，每一個字符的ascii值是否都大於某個字段來判定這個文件屬於何種編碼。這種方式vim也使用了，這就是vim的自動編碼識別機制了。但這種機制因爲編碼各式各樣，不可能每種編碼都有顯著的特徵來辨別，因此是不可能 
100%準確的。對於咱們GB2312編碼，因爲其中文是使用了2個acsii值高於127的字符組成漢字字符的，所以不可能把gb2312編碼的文件與latin1編碼區分開來，所以自動識別編碼的機制對於gb2312是不成功的，它只會將文件辨識爲latin1編碼。此問題一樣出如今gbk，big5等。所以咱們在編輯此類文檔時，須要手工設定encoding和fileencoding。若是文檔編碼爲utf-8時，通常vim都能自動識別正確的編碼。 
3，客戶運行vim的終端所使用的編碼類型—-同第二條同樣，這也是一個比較難以判定的關鍵點。第二個關鍵點決定着從文件讀取內容和寫入內容到文件 
時使用的編碼，而此關鍵點則決定vim輸出內容到終端時使用的編碼，若是此編碼類型和終端認爲它收到的數據的編碼類型不一樣，則又會產生亂碼問題。在linux本地X環境下，通常終端都認爲其接收的數據的編碼類型和系統locale類型相符，所以不需關心此方面是否存在問題。但若是牽涉到遠程終端，例如ssh登陸服務器，則問題就有可能出現了。例如從1臺locale爲GB2310的系統（稱做客戶機）ssh到locale爲utf-8的系統（稱做服務器）並開啓vim編輯文檔，在不加任何改動的狀況下，服務器返回的數據爲utf-8的，但客戶機認爲服務器返回的數據是gb2312的，按照gb2312來解釋數據，則確定就是亂碼了，這時就須要設置termencoding爲gb2312來解決這個問題。此問題更多出如今咱們的windows desktop機遠程ssh登陸服務器的狀況下，這裏牽扯到不一樣系統的編碼轉換問題。因此又與windows自己以及ssh客戶端有很大相關性。在 
windows下存在兩種編碼類型的軟件，一種是自己就爲unicode編碼方式編寫的軟件，一種是ansi軟件，也就是程序處理數據直接採用字節流，不關心編碼。前一種程序能夠在任何語言的windows上正確顯示多國語言，然後一種則編寫在何種語言的系統上則只能在何種語言的系統上顯示正確的文字。對於這兩種類型的程序，咱們須要區別對待。以ssh客戶端爲例，咱們使用的putty是unicode軟件，而secure CRT則是ansi 
軟件。對於前者，咱們要正確處理中文，只要保證vim輸出到終端的編碼爲utf-8便可，就是termencoding=utf-8。但對於後者，一方面咱們要確認咱們的windows系統默認代碼頁爲cp936（中文windows默認值），另外一方面要確認vim設置的termencoding=cp936。 
最後來看看處理中文文檔最典型的幾種狀況和設置方式： 
1，系統locale是utf-8（不少linux系統默認的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環境，方法是以LANG=zh_CN vim abc.txt的方式來啓動vim，則此時encoding=euc-cn（locale決定的），fileencoding=空（此locale下文件編碼自動判別功能不啓用，因此fileencoding爲文件自己編碼方式不變，也就是euc-cn），termencoding=空（默認值，爲空則等於encoding）此時仍是亂碼的，由於咱們的ssh終端認爲接受的數據爲utf-8，但vim發送數據爲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，在其餘須要編碼轉換的環境 裏，均可以應用相似的思路來處理問題解決問題。 
最後推薦一款功能強大的windows下的ssh客戶端—-xshell，它具備相似secure CRT同樣的多tab 
的ssh窗口的能力，但最爲方便的是這款工具還有改變Term編碼的功能，這樣咱們就能夠不用頻繁調整termencoding，只需在ssh軟件裏切換編碼便可，這是我用過的最爲方便的ssh工具。它是商業軟件，但非註冊用戶使用沒有任何限制，只是30天試用期超出後會每次啓動都提示註冊，對於功能沒有絲毫影響