徹底解密C++寬字元：1、從char到wchar_t
阿新 • • 發佈：2019-01-05
<本文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的寬字元被廢掉了）。
寬字元（串）由編譯器翻譯，還是被硬編碼程序序檔案中。
“這個問題比你想象中複雜”
（我也學下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的寬字元被廢掉了）。
寬字元（串）由編譯器翻譯，還是被硬編碼程序序檔案中。