vim中文亂碼 vim字符集設定
阿新 • • 發佈：2021-01-01
vim中文亂碼 vim字符集設定
vim的設定一般放在/etc/vimrc檔案中，不過，建議不要修改它。可以修改~/.vimrc檔案（預設不存在，可以自己新建一個），寫入所希望的設定。
set fileencodings=utf-8,ucs-bom,gb18030,gbk,gb2312,cp936
set termencoding=utf-8
set encoding=utf-8
vim編碼方面的基礎知識：
- 存在3個變數：
encoding—-該選項使用於緩衝的文字(你正在編輯的檔案)，暫存器，Vim 指令碼檔案等等。你可以把 'encoding' 選項當作是對 Vim 內部執行機制的設定。
fileencoding—-該選項是vim寫入檔案時採用的編碼型別。
termencoding—-該選項代表輸出到客戶終端（Term）採用的編碼型別。 - 此3個變數的預設值：
encoding—與系統當前locale相同，所以編輯檔案的時候要考慮當前locale，否則要設定的東西就比較多了。
fileencoding—vim開啟檔案時自動辨認其編碼，fileencoding就為辨認的值。如果fileencoding為空則儲存檔案時採用encoding的編碼，如果沒有修改encoding，那值就是系統當前locale了。
termencoding—預設空值，也就是輸出到終端時不進行編碼轉換。
由此可見，編輯不同編碼檔案需要注意的地方不僅僅是這3個變數，還有系統當前locale和檔案本身編碼以及自動編碼識別、客戶執行vim的終端所使用的編碼型別3個關鍵點，這3個關鍵點影響著3個變數的設定。
如果有人問：為什麼我用vim開啟中文文件的時候出現亂碼？
答案是不確定的，原因上面已經講了，不搞清楚這3個關鍵點和這3個變數的設定值，出現亂碼是正常的，若不出現亂碼那反倒是湊巧的。
再來看一下常見情況下這三個關鍵點的值以及在這種情況下這3個變數的值： - locale—目前大部分Linux系統已經將utf-8作為預設locale了，不過也有可能不是，例如有些系統使用中文locale zh_CN.GB18030。在locale為utf-8的情況下，啟動vim後encoding將會設定為utf-8，這是相容性最好的方式，因為內部處理使用utf-8的話，無論外部儲存編碼為何都可以進行無缺損轉換。locale決定了vim內部處理資料的編碼，也就是encoding。
- 檔案的編碼以及自動編碼識別—這方面牽扯到各種編碼的規則，就不一一細講了。但需要明白的是，檔案編碼型別並不是儲存在檔案內的，也就是說沒有任何描述性的欄位來記錄文件是何種編碼型別的。因此我們在編輯文件的時候，要麼必須知道文件儲存時是以什麼編碼儲存的，要麼通過另外的一些手段來斷定編碼型別，這另外的手段，就是通過某些編碼的碼錶特徵來斷定，例如每個字元佔用的位元組數，每個字元的ascii值是否都大於某個欄位來斷定這個檔案屬於何種編碼，這種方式vim也使用了，這就是vim的自動編碼識別機制了，但這種機制由於編碼各式各樣，不可能每種編碼都有顯著的特徵來辨別，所以是不可能 100%準確的。對於GB2312編碼，由於中文是使用了2個ASCII值高於127的字元組成漢字字元的，因此不可能把gb2312編碼的檔案與 latin1編碼區分開來，因此自動識別編碼的機制對於gb2312是失敗的，它只會將檔案辨識為latin1編碼。此問題同樣出現在gbk，big5上等，因此我們在編輯此類文件時，需要手工設定encoding和fileencoding。如果文件編碼為utf-8時，一般vim都能自動識別正確的編碼。
- 客戶執行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。