<本文PDF文檔下載>

“這個問題比你想象中復雜”
（我也學下BS的風格，雖然這句話是我自己臨時想說的。^^）

從字符到整數

char是一種整數類型，這句話的含義是，char所能表示的字符在C/C++中都是整數類型。好，接下來，很多文章就會舉出一個典型例子，比如，'a'的數值就是0x61。這種說法對嗎？如果你細心的讀過K&R和BS對于C和C++描述的原著，你就會馬上反駁道，0x61只是'a'的ASCII值，并沒有任何規定C/C++的char值必須對應ASCII。C/C++甚至沒有規定char占幾位，只是規定了sizeof(char)等于1。
當然，目前大部分情況下，char是8位的，并且，在ASCII范圍內的值，與ASCII對應。

本地化策略集（locale）

“將'a'翻譯成0x61的整數值”，“將ASCII范圍內的編碼與char的整數值對應起來”，類似這樣的規定，是特定系統和特定編譯器制定的，C/C++中有個特定的名詞來描述這種規定的集合：本地化策略集（locale。也有翻譯成“現場”）。而翻譯——也就是代碼轉換（codecvt）只是這個集合中的一個，C++中定義為策略（facet。也有翻譯為“刻面”）

C/C++的編譯策略

“本地化策略集”是個很好的概念，可惜在字符和字符串這個層面上，C/C++并不使用（C++的locale通常只是影響流（stream）），C/C++使用更直接簡單的策略：硬編碼。
簡單的說，字符（串）在程序文件（可執行文件，非源文件）中的表示，與在程序執行中在內存中的表示一致?？紤]兩種情況：
A、char c = 0x61;
B、char c = 'a';
情況A下，編譯器可以直接認識作為整數的c，但是在情況B下，編譯器必須將'a'翻譯成整數。編譯器的策略也很簡單，就是直接讀取字符（串）在源文件中的編碼數值。比如：
const char* s = "中文abc";
這段字符串在GB2312（Windows 936），也就是我們的windows默認中文系統源文件中的編碼為：
0xD6   0xD0   0xCE 0xC4 0x61 0x62 0x63
在UTF-8，也就是Linux默認系統源文件中的編碼為：
0xE4   0xB8   0xAD   0xE6   0x96   0x87   0x61   0x62   0x63
一般情況下，編譯器會忠實于源文件的編碼為s賦值，例外的情況比如VC會自作聰明的把大部分其他類型編碼的字符串轉換成GB2312（除了像UTF-8 without signature這樣的幸存者）。
程序在執行的時候，s也就保持是這樣的編碼，不會再做其他的轉換。

寬字符 wchar_t
正如char沒有規定大小，wchar_t同樣沒有標準限定，標準只是要求一個wchar_t可以表示任何系統所能認識的字符，在win32中，wchar_t為16位；Linux中是32位。wchar_t同樣沒有規定編碼，因為Unicode的概念我們后面才解釋，所以這里只是提一下，在win32中，wchar_t的編碼是UCS-2BE；而Linux中是UTF-32BE（等價于UCS-4BE），不過簡單的說，在16位以內，一個字符的這3種編碼值是一樣的。因此：
const wchar_t* ws = L"中文abc";
的編碼分別為：
0x4E2D   0x6587    0x0061   0x0062   0x0063                                                //win32，16位
0x00004E2D   0x00006587    0x00000061   0x00000062   0x00000063        //Linux，32位
大寫的L是告訴編譯器：這是寬字符串。所以，這時候是需要編譯器根據locale來進行翻譯的。
比如，在Windows環境中，編譯器的翻譯策略是GB2312到UCS-2BE；Linux環境中的策略是UTF-8到UTF-32BE。
這時候就要求源文件的編碼與編譯器的本地化策略集中代碼翻譯的策略一致，例如VC只能讀取GB2312的源代碼（這里還是例外，VC太自作聰明了 ，會將很多其他代碼在編譯時自動轉換成GB2312），而gcc只能讀取UTF-8的源代碼（這里就有個尷尬，MinGW運行win32下，所以只有GB2312系統才認；而MinGW卻用gcc編寫，所以自己只認UTF-8，所以結果就是，MinGW的寬字符被廢掉了）。
寬字符（串）由編譯器翻譯，還是被硬編碼進程序文件中。