关于unicode

Windows(NT4.0以上版本)对unicode提供了良好的技持，不同语言版本还对本地编码（ASCII)提供了支持。
API函数分别提供了Ascii和WChar(unicode)两个版本。Windows内部使用的是unicode,比如界面显示文字，文件系统中的文件名。
当用户调用Ascii版的的API函数(比如CreateFile())时，系统会在内部将字符转成WChar再转调WChar版的API。
所以在Windows中不管理用A版的API，还是W版的API来读写文件，均运行正常。

Linux中则不然。
较新版本的Linux（fedora 8或RHEL5.0以上)内码使用的是utf-8。
当将utf-8字符传给open函数时，则一切正常。
如果使用Ascii字符作为参数来调用open（）函数，能正常运行，但系统不能正确显示文件名。
因为各种Ascii编码与utf-8都是多字节字符集，所以能正常调用。
我怀疑open函数将Ascii当作utf-8字符来处理了，故显示乱码。
如果将系统编码改成GB2312后则可以正确显示文件名。
linux(g++)中也没有接受宽字符作为文件名参数的fstream。

在Windows中用Ascii字符调用open函数时，一切正常。因为在Windows平台上，c库函数open也是调用CreateFile，
等API函数来实现的，故不会有什么问题。

另VC编译器能够智能识别代码文本的编码（.h, .cpp, .inl等).
G++（在eclipse集成开发环境中)编译器须要显式指示文本编码，否则会得出错误结果。

在VC编译器中，代码文本文件的编码和程序中静态字符的运行时编码没有关系。模拟转换流程如下：
1、编译器调取文本文件件；
2、编译器根数据类型(char* 或 wchar_t)，将文本中静态字符串转成对应编码（unicode或Ascii)的内存字节。
3、据预定义宏（有没有_UNICODE)，调用对应版本的API函数。如果调用c库函数，须要自己控制(例open和wopen)。
以上的步骤都是在编译阶段完成，不会带来运行中的问题。

在G++编译器中，如果没有指定文本编码，将导致严重的乱码问题。
另：Qt的QString是用Unicode在内存中存储的。