首先，我們應該了解字符和字節的區別。字符用於顯示，而字節用於存儲和傳輸。網絡傳輸是字節流，文件也存儲在字節流中。如果壹個編輯器想要顯示壹個文件的內容，它需要被轉換成字符來顯示。字符和字節之間的關系可以定義如下
可以看出編碼和解碼是壹對相反的操作，它們都需要指定編碼方案。如果編碼方案不壹致，操作將失敗。
通過終端操作遠程vim時，其數據流方向可表示如下。
在這個流程方向上，只有終端和vim需要顯示字符，其他進程或服務只做數據傳輸。如果只傳輸二進制數據，則不需要編碼和解碼，只有在顯示字符時才需要解碼。因此，只有終端和vim需要配置編碼，而終端需要處理本地shell，遠程vim也需要處理shell。外殼的編碼也非常重要。
終端本身就是壹個進程，最終的字符顯示需要終端來完成。我們在終端上輸入的字符在傳輸之前也會被它編碼。簡單地說，它是
這裏的編解碼器方案是終端需要配置的。
locale命令還可以查看shell編碼設置。以LC_開頭的編碼方案代表系統的不同類別，這些類別分為以下幾類。
至於最終方案，其優先順序如下
也就是說，壹切都基於LC_ALL。如果未設置，請查找與LC_*對應的設置項目。如果仍未設置，請使用LANG的設置，將顯示LC_CTYPE項目。為方便描述，後續所有對shell編碼的引用均指LC_ALL item，shell編碼方法設置如下。
假設我們的本地終端編碼設置為UTF-8，外殼編碼設置為GBK。當我們在終端上輸入漢字時，它會顯示為亂碼或不顯示。
我們來分析壹下終端輸入shell命令時的數據交互。
終端和shell被視為兩個服務，需要進行數據交互，發送數據時進行編碼，接收數據時進行解碼。如果編碼方案和解碼方案不壹致，將導致亂碼或失敗，這意味著當在終端上輸入中文命令時，將顯示異常，執行結果將達不到預期。
如果使用ssh登錄遠程shell，遠程shell的編碼配置與本地shell的壹致。現在您可以通過ssh -v V打印ssh在登錄過程中做了什麽。
所以我們的第壹點是
Vim有四個與編碼相關的設置。
可以看出，vim的編碼設置相當復雜，因此我們仍然結合具體示例來分析這些編碼設置的功能。
無論是打開本地vim還是遠程vim，我們都應該首先確保本地shell的編碼設置與終端壹致，這樣涉及編碼和解碼的數據流可以簡化如下
Vim打開文件並最終在終端上顯示出來。這個過程與編碼設置有關。
可以看到vim在打開文件並顯示文件的過程中有大量的編碼轉換操作。將二進制從編碼A轉換為編碼B的步驟如下
最終輸出仍然是字節流。如果A和B不同，則輸出字節流不同於輸入字節流（ascii字節流除外，它對所有編碼方案中的ascii字符都相同）。轉換成功的前提是decode采用的編碼方案必須與輸入字節流的編碼方案壹致，也就是說，如果輸入字節流是用C編碼方案生成的，那麽用A編碼方案解碼就會失敗。
如果vim的某些編碼項目未設置，將使用其依賴項的設置或默認設置。依賴關系如下。
在vim的這些編碼設置中，我們通常只設置文件編碼和編碼。如果只在中英文環境下使用，可以設置如下。
編碼必須設置utf8，因為utf8可以表示所有字符。
假設終端編碼設置為gbk，vim的編碼為utf8。此時，我們打開壹個文件，無論該文件是utf8還是gbk編碼，都無法正常顯示。
如前所述，vim的$ termencoding將默認繼承編碼設置，打開文件的相應步驟如下。
如果要正常顯示，只需臨時修改vim的$ termencoding代碼，使其與終端編碼代碼保持壹致。$ termencoding只涉及顯示，不涉及文件內容的更改。不要修改編碼項。準確地說，不要試圖在任何時候修改編碼設置。
所以我們的第二點是
如果打開文件的數據流是從vim到終端，那麽修改文件就是從終端到vim再到終端的往返過程。
與編碼相關的步驟如下。前面已經描述了打開文件顯示的過程，這裏只提到修改和保存的過程。
文件編碼有兩種情況。
從上面可以看出，編碼方案編碼的數據是vim中的中轉點。接收數據（從文件讀取或從終端輸入）時，必須將其轉換為編碼方案，然後在保存文件時將編碼方案轉換為fileencoding方案。因此，編碼必須設置為可以表示所有字符的編碼方案，通常我們將其設置為utf8。
假設終端和shell的編碼設置都是gbk，vim的編碼設置是utf8，如果要正常輸入和顯示字符，則必須將$ termencoding設置設置為與終端編碼壹致，這意味著顯示字符和保存帶有輸入字符的文件都可以正常工作。
我們可以設置編碼不壹致只是為了演示編碼的影響。在實際環境中，我們必須確保這些編碼設置是壹致的，所以最終的要點是