C編譯器實際上本身並不識別和處理UTF-8、GBK等編碼，它只認ASCII字元，通過ASCII字元解析程式碼，至於多位元組字元，比如註釋、字串中的中文字元，C編譯器根本不管，它只當位元組序列看待，反正ASCII字元已經能正確定界了。因此，實際上字串中的中文字元，就是按照原始碼中的位元組序列直接儲存的。

真正識別字符編碼的地方是終端，終端收到標準輸出流中的位元組序列，然後按設定的字元編碼方式（如UTF-8、GBK）解析這些位元組序列，解析成一個個字元（此時就是真正的字元了，比如中文字元），然後繪製到介面中。

因此，要使得中文正常顯示，就要保證原始檔用的字元編碼和終端顯示用的字元編碼是一樣的。

類Unix作業系統現在已經基本將各方面的字元編碼都統一成了UTF-8，所以基本不會出問題。問題主要在Windows上。

Windows上，終端（cmd和Powershell）的預設編碼是GBK（內碼表936），因此，一般將原始檔編碼方式設定為GBK，則中文字元就能在終端中正常顯示。但是，GBK畢竟不是全球通行的字元編碼，最好還是用UTF-8，那麼就必須將終端的編碼方式設定為UTF-8。如果是互動式終端，可以通過執行chcp 65001來，然後./程式.exe就能看到UTF-8原始檔編譯來的程式中文正常了。互動式使用終端時，還可以用Git for Windows自帶的終端，是預設UTF-8編碼的，但是不支援互動式輸入。

但是，如果是直接雙擊執行程式，Windows會使用cmd來顯示控制檯程式的輸出，此時預設內碼表是936，字元編碼為GBK，那麼UTF-8原始檔編譯來的程式就會亂碼。此時可以通過在原始碼中加入system("chcp 65001");

Visual Studio中，原始碼檔案的編碼格式是UTF-8 with BOM，之所以加BOM是VS為了確定地識別UTF-8。編譯時，VS通BOM檢測到原始檔的編碼是UTF-8，會先將原始碼轉成本地的字元編碼GBK（原來的檔案不變），然後編譯得到GBK的程式。如果把原始檔的編碼改成UTF-8 without BOM，就不會做這樣的轉換。同理，UTF-16 LE、UTF-16 BE都有這樣的轉換機制。

CodeBlocks不會做任何轉換。

CLion預設原始檔是UTF-8，但是自帶輸出視窗本地編碼GBK。不過有幾個地方可以設定編碼，如檔案的編碼、專案的編碼、控制檯的編碼等。注意，普通執行的視窗始終都是用的本地編碼GBK，但是除錯執行的視窗編碼可以設定成UTF-8。