以下討論都基於C++的定義
在C++的標準定義中
Type wchar_t is a distinct type whose values can represent distinct
codes for all members of the largest extended character set specified
among the supported locales. Type wchar_t shall have the same
size, signedness, and alignment requirements as one of the other
integral types, called its underlying type.
...
A character literal that begins with the letter L, such as L'x', is a
wide-character literal. A wide-character literal has type wchar_t.
The value of a wide-character literal containing a single c-char has
value equal to the numerical value of the encoding of the c-char in
the execution wide-character set. The value of a wide-character lit-
eral containing multiple c-chars is implementation-defined.
按照我的理解,這意味著:
1. 編譯器需要保證wchar_t與某種整數類型擁有相同的大小,符號,對齊要求.這個"某種整數類型"是由編譯器定義的.這意味著 wchar_t(0x8000 > 1)的結果是取決於編譯器的. 在VC裡面,如果設定了編譯選項"/Zc:wchar_t-",那麼wchar_t會被預設定義為無符號的"unsigned short".另外"signed wchar_t"或"unsigned wchar_t"在C++是不存在的
2.與C不同,wchar_t必須是一個內建(build-in)類型,我猜這是為了重載和模板特化的需要,看看iostream重載的類型大概就明白了.這裡可以引申出另外一個話題: char 既不是 "signed char", 也不是"unsigned char"
3.C++的標準文本沒有將wchar_t 和 unicode關聯起來,標準僅僅要求,wchar_t 能夠用唯一的編碼錶示該編譯器所有locale的字元全集中的任何一個字元即可,雖然從需求上來講,wchar_t 也是一種unique-code,但是,一個特立獨行的編譯器,完全有權利定義一套完全不同於unicode的hexie-code,不過,這個hexie-code至少需要保證在數值上,能夠相容 char 類型的表數範圍,通常意味著 hexie-code的 0-255必須是和char的0-255表示相同的字元
4.眾所周知的,windows的wchar_t是16位,linux的wchar_t是32位
5.截至到VC8, VC的C運行庫是不支援UTF-8的,也就是說setlocale(LC_CTYPE, "zh_CN.UTF-8")是無效的,setlocale(LC_CTYPE, "zh_CN.65001")也不行.單步跟蹤後,發現在getqloc.c中,有以下代碼
// verify codepage validity
if (!iCodePage || iCodePage == CP_UTF7 || iCodePage == CP_UTF8 ||
!IsValidCodePage((WORD)iCodePage))
return FALSE;
這段代碼是VC8中新加的,VC7中沒有,表現出來的不同是, VC8在setlocale的時候就失敗了,而VC7直到真的使用mbstowcs這些函數的時候才會失敗
http://hi.baidu.com/bbcallen/blog/item/e2e37b1b5add59d3ac6e7549.html