前言
網上看到一篇關于寬字元的文章,真是醍醐灌頂。對寬字元算是有了一個比較深的了解。
好東西不能獨享。現轉載此篇文章,供大家學習。
==================================
“這個問題比你想象中複雜”
(我也學下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的寬字元被廢掉了)。
寬字元(串)由編譯器翻譯,還是被寫死程序式檔案中。
原文位址:http://www.cppblog.com/lf426/archive/2010/06/25/118707.html