C++ 编译器对字符编码的要求和处理方式

旧城等待， 2022-09-08 14:00 6阅读 0赞

[http://blog.csdn.net/dbzhang800/article/details/7540905][http_blog.csdn.net_dbzhang800_article_details_7540905]

*  长期以来，很多人都清楚，一旦C++源码中直接使用了中文，这样的源码想要跨平台(I18N)会非常困难。

随着：

*  Windows下：MSVC2010成为主流
 *  Linux下：GCC升级到4.6

C++中的中文问题 才算有了一个比较优雅的、跨平台的Workaround。

(本文讨论编译器范围：GCC4.6+, MSVC2010sp1+ 。本文属于QString系列，但暂不涉及QString)

## C++ 中文问题 ##

要在C++中正确使用中文，必须要了解下面两个概念：

<table> 
 <tbody> 
  <tr> 
   <td> <p>源码字符集(the source character set)</p> </td> 
   <td> <p>源码文件是使用何种编码保存的</p> </td> 
  </tr> 
  <tr> 
   <td> <p>执行字符集(the execution character set)</p> </td> 
   <td> <p>可执行程序内保存的是何种编码(程序执行时内存中字符串编码)</p> </td> 
  </tr> 
 </tbody> 
</table>

C++98的问题： **既没有规定源码字符集，也没有规定执行字符集**

这个... 如何理解？不妨看个例子

### 例子 ###

这个要求高么？

*  一个简单的C++程序，只是希望它能在简体中文Windows、正体中文Windows、英文版Windows、Linux、MAC OS...下的结果一致。

//main.cpp
    int main()
    {
        char mystr[] = "老老实实的学问，来不得半点马虎";
        return sizeof mystr;
    }

可以试着反问自己两个问题

*  这个源码文件是何种编码保存的？(有确定答案么？)
 *  mystr中是什么内容？(有确定答案么？)

对C++来说，这两个都不确定。

*  固定平台的话，还能忍忍
 *  要跨平台的话，这种东西...

### GCC ###

在GCC下，这两个都可以使用你自己喜好的编码(如果不指定，默认都是UTF8)

-finput-charset=charset
    -fexec-charset=charset

除了前两个选项外，还有一个：

-fwide-exec-charset=charset

wide? 不妨先猜一下它是干嘛的

### MSVC ###

MSVC没有类似前面的选项。

<table> 
 <tbody> 
  <tr> 
   <td> <p>源码字符集如何解决？</p> </td> 
   <td> <p>有BOM么，有则按BOM解释，无则使用本地Locale字符集(随系统设置而变)</p> </td> 
  </tr> 
  <tr> 
   <td> <p>执行字符集如何解决?</p> </td> 
   <td> <p>使用本地Locale字符集(随系统设置而变)</p> </td> 
  </tr> 
 </tbody> 
</table>

挺霸道哈（当然，源码中可以使用\#pragma setlocale("...")，但功能很有限，比如Windows没有utf8的locale，所以...）。

另外，和GCC对应的wide-exec-charset呢？

<table> 
 <tbody> 
  <tr> 
   <td> <p>宽执行字符集如何解决?</p> </td> 
   <td> <p>不妨先考虑一下</p> </td> 
  </tr> 
 </tbody> 
</table>

### 怎么办? ###

这才两个编译器，看起来就这么复杂了。而C++编译器的数目远大于2.

要想跨平台，必须确保这两个字符集都是“确定”的，而能胜任该任务的字符集，似乎理想的也只能是...

## UTF-8方案 ##

*  如果我们将源码保存成utf8，执行字符集也选为utf8，那么天下将太平了。使用非ASCII字符的源码文件也就可以在不同国家的用户间无障碍流通了 ;-).

源码保存成UTF-8没有什么困难，但是，**执行字符集需要是UTF-8**。没那么简单

对GCC来说，这个问题很简单(默认的编码选项足够了)：

*  只要源码文件保存成utf8即可(带或不带BOM均可)
 *  早期的gcc不接收带BOM的utf8源码文件，现在，至少在GCC4.6中，这一限制不再存在。

对MSVC来说，这个问题异常复杂：

*  对MSVC2003来说，只要源码保存成不带BOM的utf8即可
 *  对MSVC2005、(没在SP1基础上装热补丁的)MSVC2008来说。完全没办法
 *  直到MSVC2010sp1，才算提供了一个解决方案。源码保存成带BOM的utf8，utf16，...，然后添加

#pragma execution_character_set("utf-8")

要想跨GCC4.6+和MSVC2010sp1+，我们需要取它们的交集：也就是

*  源码保存成带BOM的utf8
 *  为MSVC添加\#pragma

//main.cpp
    
    #if _MSC_VER >= 1600
    #pragma execution_character_set("utf-8")
    #endif
    
    int main()
    {
        char mystr[] = "老老实实的学问，来不得半点马虎";
        return sizeof mystr;
    }

### C++11 ###

等到MSVC支持C++11的String Literals之时，我们就没必要用那个蹩脚的pragma了，直接

char mystr[] = u8"老老实实的学问，来不得半点马虎";

即可(尽管现在在GCC下没问题，但要跨平台，估计要等到Visual C++ 12了)。

## 有个问题？ ##

C++98中不是有个wchar\_t么，它不是用来表示unicode字符的么？

Unicode 4.0标准的5.2节是如何说的：

The width of wchar_t is compiler-specific and can be as small as 8 bits. Consequently, programs that need to be portable across any C or C++ compilershould not use wchar_t for storing Unicode text. The wchar_t type is intended forstoring compiler-defined wide characters, which may be Unicode characters in some compilers.

在回头看看GCC的选项

-fwide-exec-charset=charset

尽管GCC为其提供的默认编码是UTF16或UTF32(取决于wchar\_t的宽度)，但该编码是可以随意设置的。

尽管这个东西不保证跨平台，也很不好玩， 但是，由于在windows下面wchar\_t用来表示utf16字符，而且直接对应系统API接口，所以在类型char16\_t普及之前，还是很重要的。

## C++11执行字符集 ##

前面提到的u8就是C++11为“执行字符集”所做的努力之一。

新明确规定了utf8、utf16和utf32这3种执行字符集。

可是C++11并没有规定源码字符集

const char* mystr=u8"中文";

C++标准对编译器说，我不管这个文件的具体编码是什么，但你必须给我生成对应utf8编码的字节流。

编译器似乎有点傻了吧？不知道源文件的编码，我如何转换

于是：

MSVC说：源码文件必须有BOM，不然我就认为你是本地locale的编码

GCC说：我认为你就是utf8编码，除非通过命令行通知我其他编码

在C++11标准下，对源码编码 简单的处理办法还是，使用带BOM的UTF8保存。

**UTF—8与UTF—8（无bom）格式相比有什么不同**

BOM——Byte Order Mark，就是字节序标记  
  
  
在UCS 编码中有一个叫做"ZERO WIDTH NO-BREAK SPACE"的字符，它的编码是FEFF。而FFFE在UCS中是不存在的字符，所以不应该出现在实际传输中。UCS规范建议我们在传输字节流前，先传输字符"ZERO WIDTH NO-BREAK SPACE"。这样如果接收者收到FEFF，就表明这个字节流是Big-Endian的；如果收到FFFE，就表明这个字节流是Little-Endian的。因此字符"ZERO WIDTH NO-BREAK SPACE"又被称作BOM。  
  
  
UTF-8不需要BOM来表明字节顺序，但可以用BOM来表明编码方式。字符"ZERO WIDTH NO-BREAK SPACE"的UTF-8编码是EF BB BF。所以如果接收者收到以EF BB BF开头的字节流，就知道这是UTF-8编码了。  
  
  
UTF-8编码的文件中，BOM占三个字节。如果用记事本把一个文本文件另存为UTF-8编码方式的话，用UE打开这个文件，切换到十六进制编辑状态就可以看到开头的FFFE了。这是个标识UTF-8编码文件的好办法，软件通过BOM来识别这个文件是否是UTF-8编码，很多软件还要求读入的文件必须带BOM。可是，还是有很多软件不能识别BOM。

## 参考 ##

*  [http://gcc.gnu.org/onlinedocs/cpp/Character-sets.html\#Character-sets][http_gcc.gnu.org_onlinedocs_cpp_Character-sets.html_Character-sets]
 *  [http://support.microsoft.com/kb/980263][http_support.microsoft.com_kb_980263]

#  #

# \[C/C++\] 各类C/C++编译器对UTF-8源码文件的兼容性测试（VC、GCC、BCB） #

Admin  
2012年7月27日

名人名言：迎着阳光开放的花朵才美丽，伴着革命理想的爱情才甜蜜。——莫贵英

作者：zyl910

在不合平台上开辟C/C++法度时，为了避免源码文件乱码，得采取UTF-8编码来存储源码文件。然则很多编译器对UTF-8源码文件兼容性不佳，于是我做了一些测试，解析了最佳保存规划。

# 一、测试法度 #

为了测试编译器对UTF-8源码文件兼容性，我编写了如许的一个测试法度——

//＃if _MSC_VER >= 1600    // VC2010
    
    //＃pragma execution_character_set（"utf-8"）
    
    //＃endif
    
    
    
    ＃include <stdio.h>
    
    ＃include <locale.h>
    
    ＃include <string.h>
    
    ＃include <wchar.h>
    
    
    
    char* psa = "\u4e00字A";
    
    wchar_t* pdw = L"\u4e00字W";
    
    
    
    int main（int argc， char* argv[]）
    
    {
    
        char* pa;
    
        wchar_t* pw;
    
    
    
        setlocale（LC_ALL， ""）;    // 应用体系当前代码页.
    
    
    
        // char
    
        printf（"len<％d>=％d，str=％s\t//"， sizeof（char）， strlen（psa）， psa）;
    
        for（pa=psa; *pa!=0; ++pa）    printf（" ％.2X"， （unsigned char）*pa）;
    
        printf（"\n"）;
    
        
    
        // wchar_t
    
        printf（"len<％d>=％d，str=％ls\t//"， sizeof（wchar_t）， wcslen（pdw）， pdw）;
    
        for（pw=pdw; *pw!=0; ++pw）    printf（" ％.4X"， （unsigned int）*pw）;
    
        printf（"\n"）;
    
    
    
        return 0;
    
    }

若是体系默认编码是GB2312（如中文Windows体系），该法度的输出成果应是——  
len<1>=5，str=一字A // D2 BB D7 D6 41  
len<2>=3，str=一字W // 4E00 5B57 0057

若是体系默认编码是UTF-8（如Linux体系），该法度的输出成果应是——  
len<1>=7，str=一字A // E4 B8 80 E5 AD 97 41  
len<4>=3，str=一字W // 4E00 5B57 0057

注：  
1. “len”旁尖括号内的是字符类型的宽度。char类型一般是1字节。而wchar\_t类型跟编译器与操纵体系有关，Windows平台下一般2字节，Linux平台下一般4字节。  
2. “len<？>=”右侧的数字是字符个数。用char类型，一个汉字的GB2312编码是2个字符，一个汉字的UTF-8编码一般是3个字符。而对于wchar\_t类型，一个汉字一般是1个字符。  
3. “str=”右侧的是所显示的字符串。  
4. “//”右侧用于显示每一个字符的值。

#    二、测试成果 #

须要测试这些方面——  
1. 分别测试不合操纵体系下的多种编译器。  
2. 无签名的UTF-8与带签名的UTF-8。UTF-8存储规划分别有两种，一是无签名的UTF-8，另一是带签名的UTF-8，这两种规划的差别是——是否存在签名字符（BOM）。  
3. 履行字符集。VC2010增长了“＃pragma execution\_character\_set（"utf-8"）”，指导char的履行字符集是UTF-8编码。

按照上方的请求，制订好了测试项目，分别有Window平台下的测试与Linux平台下的测试。  
　　Window平台下的测试有——  
\[VC6， noBOM\]：VC6.0 sp1，源码应用无签名的UTF-8编码。  
\[VC6， BOM\]：VC6.0 sp1，源码应用带签名的UTF-8编码。  
\[VC2003， noBOM\]：VC2003 sp1，源码应用无签名的UTF-8编码。  
\[VC2003， BOM\]：VC2003 sp1，源码应用带签名的UTF-8编码。  
\[VC2005， noBOM\]：VC2005 sp1，源码应用无签名的UTF-8编码。  
\[VC2005， BOM\]：VC2005 sp1，源码应用带签名的UTF-8编码。  
\[VC2010， noBOM\]：VC2010 sp1，源码应用无签名的UTF-8编码。  
\[VC2010， BOM\]：VC2010 sp1，源码应用带签名的UTF-8编码。  
\[VC2010， noBOM， execution\_character\_set\]：VC2010 sp1，源码应用无签名的UTF-8编码，并应用“＃pragma execution\_character\_set（"utf-8"）”。  
\[VC2010， BOM， execution\_character\_set\]：VC2010 sp1，源码应用带签名的UTF-8编码，并应用“＃pragma execution\_character\_set（"utf-8"）”。  
\[BCB6， noBOM\]：Borland C++ Builder 6.0，源码应用无签名的UTF-8编码。  
\[BCB6， BOM\]：Borland C++ Builder 6.0，源码应用带签名的UTF-8编码。  
\[gcc（mingw）， noBOM\]：MinGW中的GCC 4.6.2，源码应用无签名的UTF-8编码。  
\[gcc（mingw）， BOM\]：MinGW中的GCC 4.6.2，源码应用带签名的UTF-8编码。

Linux平台下的测试有——  
\[gcc（fedora）， noBOM， chs\]：Fedora 17自带的GCC 4.7.0，源码应用无签名的UTF-8编码，体系说话设为“简体中文”。  
\[gcc（fedora）， BOM， chs\]：Fedora 17自带的GCC 4.7.0，源码应用带签名的UTF-8编码，体系说话设为“简体中文”。  
\[gcc（fedora）， noBOM， eng\]：Fedora 17自带的GCC 4.7.0，源码应用无签名的UTF-8编码，体系说话设为“英语”。  
\[gcc（fedora）， BOM， eng\]：Fedora 17自带的GCC 4.7.0，源码应用带签名的UTF-8编码，体系说话设为“英语”。

测试成果汇总如下（分号“;”后的是我写的注释）——

[VC6， noBOM]
    
    len<1>=9，str=u4e00瀛桝    // 75 34 65 30 30 E5 AD 97 41    ; VC6无法辨认“\u”转义符，直接输出了“u4e00”。
    
    len<2>=7，str=u4e00瀛梂    // 0075 0034 0065 0030 0030 701B 6882
    
    
    
    [VC6， BOM]
    
    无法编译！    ; 因BOM字符被编译器当做了错误的语句。
    
    
    
    [VC2003， noBOM]
    
    len<1>=0，str=    //    ; 编译器无法辨认字符串。
    
    len<2>=3，str=一瀛梂    // 4E00 701B 6882
    
    
    
    [VC2003， BOM]
    
    len<1>=0，str=    //
    
    len<2>=3，str=一字W    // 4E00 5B57 0057
    
    
    
    [VC2005， noBOM]
    
    len<1>=6，str=一瀛桝    // D2 BB E5 AD 97 41
    
    len<2>=3，str=一瀛梂    // 4E00 701B 6882
    
    
    
    [VC2005， BOM]
    
    len<1>=5，str=一字A    // D2 BB D7 D6 41
    
    len<2>=3，str=一字W    // 4E00 5B57 0057
    
    
    
    [VC2010， noBOM]
    
    len<1>=6，str=一瀛桝    // D2 BB E5 AD 97 41    ; “字A”的UTF-8编码为“E5 AD 97 41”，编译器将它们辨认为GB2312编码的“瀛桝”，并将其存储为GB2312字符串。
    
    len<2>=3，str=一瀛梂    // 4E00 701B 6882    ; “字W”的UTF-8编码为“E5 AD 97 57”，编译器将它们辨认为GB2312编码的“瀛梂”，并将其存储为UTF-16字符串。
    
    
    
    [VC2010， BOM]
    
    len<1>=5，str=一字A    // D2 BB D7 D6 41    ; 因带有BOM，编译器正确的辨认了字符串，并将其存储为GB2312字符串。
    
    len<2>=3，str=一字W    // 4E00 5B57 0057    ; 因带有BOM，编译器正确的辨认了字符串，并将其存储为UTF-16字符串。
    
    
    
    [VC2010， noBOM， execution_character_set]
    
    len<1>=8，str=一鐎涙    // D2 BB E7 80 9B E6 A1 9D    ; “\u4e00”被辨认为“一”，并存储为GB2312编码“D2 BB”。“字A”的UTF-8编码为“E5 AD 97 41”，编译器将它们辨认为GB2312编码的“瀛桝”，并存储为UTF-8编码的“E7 80 9B E6 A1 9D”。但显示时体系默认是 GB2312 编码。
    
    len<2>=3，str=一瀛梂    // 4E00 701B 6882
    
    
    
    [VC2010， BOM， execution_character_set]
    
    len<1>=6，str=一瀛桝    // D2 BB E5 AD 97 41    ; “\u4e00”被辨认为“一”，并存储为GB2312编码“D2 BB”。“字A”的UTF-8编码为“E5 AD 97 41”，编译器正确的将其存储为UTF-8编码。但显示时体系默认是 GB2312 编码。
    
    len<2>=3，str=一字W    // 4E00 5B57 0057
    
    
    
    [BCB6， noBOM]
    
    len<1>=6，str=一瀛桝    // D2 BB E5 AD 97 41
    
    len<2>=3，str=一瀛梂    // 4E00 701B 6882
    
    
    
    [BCB6， BOM]
    
    无法编译！    ; 因BOM字符被编译器当做了错误的语句。
    
    
    
    [gcc（mingw）， noBOM]
    
    len<1>=7，str=涓€瀛桝    // E4 B8 80 E5 AD 97 41    ; 存储为UTF-8编码。但显示时体系默认是 GB2312 编码。
    
    len<2>=3，str=一字W    // 4E00 5B57 0057
    
    
    
    [gcc（mingw）， BOM]
    
    len<1>=7，str=涓€瀛桝    // E4 B8 80 E5 AD 97 41
    
    len<2>=3，str=一字W    // 4E00 5B57 0057
    
    
    
    
    
    [gcc（fedora）， noBOM， chs]
    
    len<1>=7，str=一字A    // E4 B8 80 E5 AD 97 41    ; 存储为UTF-8编码。显示时体系默认是 zh_CN.utf8 编码，正常输出。
    
    len<4>=3，str=一字W    // 4E00 5B57 0057
    
    
    
    [gcc（fedora）， BOM， chs]
    
    len<1>=7，str=一字A    // E4 B8 80 E5 AD 97 41
    
    len<4>=3，str=一字W    // 4E00 5B57 0057
    
    
    
    [gcc（fedora）， noBOM， eng]
    
    len<1>=7，str=一字A    // E4 B8 80 E5 AD 97 41    ; 存储为UTF-8编码。显示时体系默认是 en_US.utf8 编码，正常输出。
    
    len<4>=3，str=一字W    // 4E00 5B57 0057
    
    
    
    [gcc（fedora）， BOM， eng]
    
    len<1>=7，str=一字A    // E4 B8 80 E5 AD 97 41
    
    len<4>=3，str=一字W    // 4E00 5B57 0057

#    三、成果解析 #

调查测试成果，我们起首可以发明以下几点——　　  
VC6和BCB6都无法编译带签名UTF-8编码的代码文件，它们会将签名字符（BOM）当做错误的语句。  
VC6无法辨认“\\u”转义符。  
VC2003无法辨认UTF-8编码的char。

##    3.1 道理解析 ##

Windows下的测试以VC2010最为典范，以此为例来讲解。

在编译过程中，处理惩罚字符串时会涉及下面两种字符集——  
源码字符集（the source character set）：源码文件是应用何种编码保存的。  
履行字符集（the execution character set）：可履行法度内保存的是何种编码。

要想使法度不会乱码，必须满足——  
1） 编译器正确辨认了源码字符集，从而获得正确的字符串数据。  
2） 运行景象的编码与履行字符集雷同。运行景象的编码可经由过程setlocale函数来设备，“setlocale（LC\_ALL， ""）”默示应用体系默认编码。对于简体中文Windows来说一般是GB2312，若是履行字符集雷同，那就能正常显示，不然会乱码。

VC2010是如许处理惩罚的——  
源码字符集：若是有签名字符，就按它的编码来解析；不然应用本地Locale字符集。  
履行字符集：对于char类型，若是有“＃pragma execution\_character\_set”，就按它的编码来存储字符串；不然应用本地Locale字符集。对于wchar\_t类型，老是应用UTF-16编码。

当源码应用带签名的UTF-8编码时，VC2010能正确的辨认源码字符集是UTF-8。然后因没有“＃pragma execution\_character\_set”，履行字符集是本地Locale字符集——  
\[VC2010， BOM\]  
len<1>=5，str=一字A // D2 BB D7 D6 41 ; 因带有BOM，编译器正确的辨认了字符串，并将其存储为GB2312字符串。  
len<2>=3，str=一字W // 4E00 5B57 0057 ; 因带有BOM，编译器正确的辨认了字符串，并将其存储为UTF-16字符串。

当源码应用无签名的UTF-8编码时，VS2010因找不到签名字符，源码字符集被误认为是本地Locale字符集。然后因没有“＃pragma execution\_character\_set”，履行字符集是本地Locale字符集——  
\[VC2010， noBOM\]  
len<1>=6，str=一瀛桝 // D2 BB E5 AD 97 41 ; “字A”的UTF-8编码为“E5 AD 97 41”，编译器将它们辨认为GB2312编码的“瀛桝”，并将其存储为GB2312字符串。  
len<2>=3，str=一瀛梂 // 4E00 701B 6882 ; “字W”的UTF-8编码为“E5 AD 97 57”，编译器将它们辨认为GB2312编码的“瀛梂”，并将其存储为UTF-16字符串。

当应用“＃pragma execution\_character\_set（"utf-8"）”设备了履行字符集为UTF-8后，景象变得更错杂了。我们先看看VC2010能正确辨认源码字符集的带签名文件——  
\[VC2010， BOM， execution\_character\_set\]  
len<1>=6，str=一瀛桝 // D2 BB E5 AD 97 41 ; “\\u4e00”被辨认为“一”，并存储为GB2312编码“D2 BB”。“字A”的UTF-8编码为“E5 AD 97 41”，编译器正确的将其存储为UTF-8编码。但显示时体系默认是 GB2312 编码。  
len<2>=3，str=一字W // 4E00 5B57 0057

再看看无签名时的景象。VS2010因找不到签名字符，源码字符集被误认为是本地Locale字符集，即误将UTF-8辨认为GB2312。然后按照履行字符集，又转换编码为UTF-8进行存储。最后在运行时因默认编码是GB2312，再次误将UTF-8辨认为GB2312——  
\[VC2010， noBOM， execution\_character\_set\]  
len<1>=8，str=一鐎涙 // D2 BB E7 80 9B E6 A1 9D ; “\\u4e00”被辨认为“一”，并存储为GB2312编码“D2 BB”。“字A”的UTF-8编码为“E5 AD 97 41”，编译器将它们辨认为GB2312编码的“瀛桝”，并存储为UTF-8编码的“E7 80 9B E6 A1 9D”。但显示时体系默认是 GB2312 编码。  
len<2>=3，str=一瀛梂 // 4E00 701B 6882

从上方这2个例子中，发明VC2010存在一个Bug——“＃pragma execution\_character\_set”对“\\u”转义字符无效，“\\u”转义字符老是应用本地Locale字符集，而不是履行字符集。

##    3.2 GCC解析 ##

GCC的源码字符集与履行字符集默认是UTF-8编码，这是因为如今的Linux体系大多应用UTF-8编码。就算调剂了Linux体系说话后，只是区域产生了变更，字符编码依然是UTF-8。所以我们的法度在“简体中文”与“英语”下，均能正确的显示中文字符。

MinGW中的GCC也是如许的，源码字符集与履行字符集默认是UTF-8编码。然则简体中文的Windows的默认编码是GB2312，会将printf输出UTF-8字符串误认为是GB2312，造成乱码。

##    3.2 最佳规划 ##

若是字符串常量中没有非ASCII字符，建议源码文件应用无签名的UTF-8编码，如许能支撑早期的编译器。  
　　若是字符串常量中含有非ASCII字符，建议源码文件应用带签名的UTF-8编码，如许能使大多半编译器正确的处理惩罚源码字符集。

补充——  
1. 重视前提仅是“字符串常量中没有非ASCII字符”。若是是从外部文件或其他路子获得非ASCII字符串，只要选择了合适的字符串函数，无签名UTF-8编码的源码文件也是能行的。  
2. VC2010新增的“＃pragma execution\_character\_set”用于明白请求UTF-8字符串的场合。因为Windows没有UTF-8的locale，实用性较小，

参考文献——  
《ISO/IEC 9899:1999 （C99）》。ISO/IEC，1999。www.open-std.org/jtc1/sc22/wg14/www/docs/n1124.pdf  
《C99标准》。yourtommy。http://blog.csdn.net/yourtommy/article/details/7495033  
《QString乱谈（2） 》。dbzhang800。http://blog.csdn.net/dbzhang800/article/details/7540905

源码下载——   
http://files.cnblogs.com/zyl910/testwchar.rar

迎着阳光开放的花朵才美丽，伴着革命理想的爱情才甜蜜。——莫贵英

[http_blog.csdn.net_dbzhang800_article_details_7540905]: http://blog.csdn.net/dbzhang800/article/details/7540905
[http_gcc.gnu.org_onlinedocs_cpp_Character-sets.html_Character-sets]: http://gcc.gnu.org/onlinedocs/cpp/Character-sets.html#Character-sets
[http_support.microsoft.com_kb_980263]: http://support.microsoft.com/kb/980263