16,551
社区成员
发帖
与我相关
我的任务
分享请发表友善的回复…
发表回复
gohappy_1999 2005-09-06
- 打赏
- 举报
chenzunshi4() ( 一级(初级))
建议斑主把这个ID封了，到处发广告
建议斑主把这个ID封了，到处发广告
bjbluecoffee 2005-09-06
- 打赏
- 举报
（续）
例如Windows的标准对话框也会出现乱码。假设我们使用简体中文Windows，当前Locale是Chinese (TW)，我们的程序是MBCS的，使用标准的打开文件对话框。因为在BIG5中没有“开”这个字，所以“打开”会被显示成“打?”。将程序编译成Unicode版本，就可以避免这个问题。
如果字符不是保存在资源中，而是硬编码在程序中。然后开发者和用户使用不同的代码页，就会导致乱码。假设开发者的Locale是Chinese (PRC)，用户的Locale是English (US)，程序中硬编码了字符串“文件”。 Chinese (PRC)的ANSI代码页是GBK，“文件”的编码“CE C4 BC FE”。
English (US)的ANSI代码页是Latin I，用户按照Latin I编码去解释“CE C4 BC FE”，就会看到“???t”。
回答我前面提过的一个问题：Delphi程序根据用户LCID转换资源中的字符串。如果用户LCID是Chinese (PRC)，系统LCID是English (US)。那么资源中的Unicode字符串会被转换为GBK编码，然后按照Latin I显示，这时我们看到的就是类似“???t”的东东，不是??。
既然资源是以Unicode保存的，MBCS程序如果不将其转换到ANSI代码页，而用W版本的函数直接显示，就不会产生乱码。例如MFC程序菜单里的中文，在English (US)的Locale也可以正常显示。不过这取决于各部分代码的具体实现，menu bar控件里的中文在English (US)的Locale会全部显示成??。
进一步的参考资料
本文的第0节和附录0主要参考了《Inside Windows 2000 Third Edition》，国内出过该书的影印版。DDK文档中有大量Windows内核的信息。用Win32dsm和各种调试器查看Windows系统文件可以获得更直接的信息。
关于Window程序的字符编码，最好的参考资料是winnt.h等SDK的包含文件、VCL、MFC、CRT的源文件。我们不需要阅读它们，只要找到自己感兴趣的信息就可以了，用Source Insight可能方便一些。
本文所谈的不是什么万古不迁的道理，只是别的程序员的一些设定，我们因为需要使用他们的程序，所以有必要了解一些细节。研究问题的方法和兴趣永远比问题本身重要，如一句拉丁俗语所说：res, non verba，实质胜于文字。
尾声
“明月虽有圆缺，但毕竟永恒不灭，人生却如过眼烟云，一去不回，真不知计较为何？”
“蛙声虽是短促，但却是万籁中一个活泼的禅机，也可以说万古如斯，永恒不迁，无奈感受到的，能有几人？”
这是一本武侠书中的对话。在时间的长河中，人生和蛙声一样易逝。说到蛙声，我的20个月的小宝宝在喝汤后，略加酝酿，就会紧闭着嘴巴，发出很像蛙鸣的声音。我们会逗他说：“小青蛙又来了”。小家伙益发得意，不管我的抗议，将连汤带油的小下巴亲热地贴在我的身上。
第0节第一段有一处笔误，应该是“用户态处于ring 3，核心态处于ring 0”。
例如Windows的标准对话框也会出现乱码。假设我们使用简体中文Windows，当前Locale是Chinese (TW)，我们的程序是MBCS的，使用标准的打开文件对话框。因为在BIG5中没有“开”这个字，所以“打开”会被显示成“打?”。将程序编译成Unicode版本，就可以避免这个问题。
如果字符不是保存在资源中，而是硬编码在程序中。然后开发者和用户使用不同的代码页，就会导致乱码。假设开发者的Locale是Chinese (PRC)，用户的Locale是English (US)，程序中硬编码了字符串“文件”。 Chinese (PRC)的ANSI代码页是GBK，“文件”的编码“CE C4 BC FE”。
English (US)的ANSI代码页是Latin I，用户按照Latin I编码去解释“CE C4 BC FE”，就会看到“???t”。
回答我前面提过的一个问题：Delphi程序根据用户LCID转换资源中的字符串。如果用户LCID是Chinese (PRC)，系统LCID是English (US)。那么资源中的Unicode字符串会被转换为GBK编码，然后按照Latin I显示，这时我们看到的就是类似“???t”的东东，不是??。
既然资源是以Unicode保存的，MBCS程序如果不将其转换到ANSI代码页，而用W版本的函数直接显示，就不会产生乱码。例如MFC程序菜单里的中文，在English (US)的Locale也可以正常显示。不过这取决于各部分代码的具体实现，menu bar控件里的中文在English (US)的Locale会全部显示成??。
进一步的参考资料
本文的第0节和附录0主要参考了《Inside Windows 2000 Third Edition》，国内出过该书的影印版。DDK文档中有大量Windows内核的信息。用Win32dsm和各种调试器查看Windows系统文件可以获得更直接的信息。
关于Window程序的字符编码，最好的参考资料是winnt.h等SDK的包含文件、VCL、MFC、CRT的源文件。我们不需要阅读它们，只要找到自己感兴趣的信息就可以了，用Source Insight可能方便一些。
本文所谈的不是什么万古不迁的道理，只是别的程序员的一些设定，我们因为需要使用他们的程序，所以有必要了解一些细节。研究问题的方法和兴趣永远比问题本身重要，如一句拉丁俗语所说：res, non verba，实质胜于文字。
尾声
“明月虽有圆缺，但毕竟永恒不灭，人生却如过眼烟云，一去不回，真不知计较为何？”
“蛙声虽是短促，但却是万籁中一个活泼的禅机，也可以说万古如斯，永恒不迁，无奈感受到的，能有几人？”
这是一本武侠书中的对话。在时间的长河中，人生和蛙声一样易逝。说到蛙声，我的20个月的小宝宝在喝汤后，略加酝酿，就会紧闭着嘴巴，发出很像蛙鸣的声音。我们会逗他说：“小青蛙又来了”。小家伙益发得意，不管我的抗议，将连汤带油的小下巴亲热地贴在我的身上。
第0节第一段有一处笔误，应该是“用户态处于ring 3，核心态处于ring 0”。
bjbluecoffee 2005-09-06
- 打赏
- 举报
(续)
2 Locale和ANSI代码页
2.1 Locale和LCID
Locale是指特定于某个国家或地区的一组设定，包括字符集，数字、货币、时间和日期的格式等。在Windows中，每个Locale可以用一个32位数字表示，记作LCID。在winnt.h中可以看到LCID的组成。它的高16位表示字符的排序方法，一般为0。在它的低16位中，低10位是primary language的ID，高4位指定sublanguage。sublanguage被用来区分同一种语言的不同编码。下面是部分primary language和sublanguage的常数定义：
#define LANG_CHINESE 0x04
#define LANG_ENGLISH 0x09
#define LANG_FRENCH 0x0c
#define LANG_GERMAN 0x07
#define SUBLANG_CHINESE_TRADITIONAL 0x01 // Chinese (Taiwan Region)
#define SUBLANG_CHINESE_SIMPLIFIED 0x02 // Chinese (PR China)
#define SUBLANG_ENGLISH_US 0x01 // English (USA)
#define SUBLANG_ENGLISH_UK 0x02 // English (UK)
好，现在我们可以计算简体中文的LCID了，将sublanguage的常数左移10位，即乘上1024，再加上primary language的常数：2*1024+4=2052，16进制是0804。美国英语是：1*1024+9=1033，16进制是0409。。繁体中文是1*1024+4=1028，16进制是0404。
2.2 代码页
每个Locale都联系着很多信息，可以通过GetLocalInfo函数读取。其中最重要的信息就是字符集了，即Locale对应的语言文字的编码。Windows将字符集称作代码页。
每个Locale可以对应一个ANSI代码页和一个OEM代码页。Win32 API使用ANSI代码页，底层设备使用OEM代码页，两者可以相互映射。
例如English (US)的ANSI和OEM代码页分别为“1252 (ANSI - Latin I)”和“437 (OEM - United States)”。 Chinese (PRC)的ANSI和OEM代码页都是“950 (ANSI/OEM - Traditional Chinese Big5)”。 Chinese (TW)的ANSI和OEM代码页都是“936 (ANSI/OEM - Simplified Chinese GBK)”。
附录1中有一张很长的表。列出了我正在使用的Windows所支持的135个Locale的部分信息，包括 LCID、国家/地区名称、语言名称、语言缩写和对应的ANSI代码页。
2.3 系统Locale、用户Locale，再谈ANSI代码页
在Windows中，通过控制面板可以为系统和用户分别设置Locale。系统Locale决定代码页，用户Locale决定数字、货币、时间和日期的格式。这不是一个好的设计，后面会谈到它带来的问题。
使用GetSystemDefaultLCID函数和GetUserDefaultLCID函数分别得到系统和用户的LCID。有很多材料将这两个函数和另外两个函数混淆：GetSystemDefaultUILanguage和GetUserDefaultUILanguage。
GetSystemDefaultUILanguage和GetUserDefaultUILanguage得到的是您当前使用的Windows版本所带的UI资源的语言。
用户程序缺省使用的代码页是当前系统Locale的ANSI代码页，可以称作ANSI编码，也就是A版本的Win32 API默认的字符编码。对于一个未指定编码方式的文本文件，Windows会按照ANSI编码解释。
2.4 AppLocale
如果一个文本文件采用BIG5编码，系统当前的ANSI代码页是GBK。打开这个文件，就会显示乱码。例如“中文”在BIG5中的编码是A4A4、A4E5，这两个编码在GBK中对应的字符是“いゅ”。这是日文的两个平假名。
在Windows XP平台有一个AppLocale程序，可以以指定的语言运行非Unicode程序。用Win32dsm打开看一看，其实它只是在运行程序前设置了两个环境变量。我们可以用个批处理文件模仿一下：
@ECHO OFF
SET __COMPAT_LAYER=#ApplicationLocale
SET ApplocaleID=0404
start notepad.exe
在简体中文平台，用这个批处理文件启动的记事本可以正确显示BIG5编码的文本文件。用它打开GBK编码的文本文件会怎么样？“中文”会被显示为“笢恅”。设置这两个环境变量会作用于当前进程和其子进程。Windows 2000平台不支持这个方法。
3 MBCS程序和Unicode程序
3.1 与字符编码有关的编译参数
让我们回到Win32 API。我们在程序中使用的Win32 API没有A/W后缀，Windows的头文件会根据编译参数UNICODE将没有后缀的函数名替换为A版本或W版本，例如：
#ifdef UNICODE
#define CreateFile CreateFileW
#else
#define CreateFile CreateFileA
#endif
C RunTime库（CRT）也使用_UNICODE和_MBCS来区分三套字符串处理函数，分别用于SBCS、MBCS和Unicdoe字符串。SBCS和MBCS分别指单字节字符串和多字节字符串。例如_tcsclen的3个版本分别为strlen、_mbslen和wcslen ，猜猜以下函数返回几？
strlen(＂VOIP网关＂)；
_mbslen((unsigned char *)＂VOIP网关＂)；
wcslen(L＂VOIP网关＂)；
答案是8、6、6。L＂ANSI字符串＂通知编译器将ANSI字符串转换为Unicode字符串，这是VC++编译器提供的一个小甜点。不过我们应该用宏：_T(＂ANSI字符串＂)。_T宏只在我们定义了_UNICODE时才转换。这样同一套代码既可以编译MBCS版本，也可以编译Unicode版本。
MFC用_UNICODE参数区分Unicode版本特有的代码，决定使用什么版本的导入库或静态库。
3.2 Unicode程序、MBCS程序和多语言支持
Unicode程序直接使用Unicode版本的CRT和Win32 API。Unicode程序的运行与当前的ANSI代码页没有关系。MBCS程序的运行依赖于ANSI代码页。如果设计者和使用者使用不同的代码页，就可能出现乱码。微软开发的程序大都是Unicode程序，不管我们怎样变换系统Locale，它们总能正常运行。
使用VCL类库的Delphi程序都是MBCS程序。VCL框架在程序启动会调用GetThreadLocale获取当前用户的LCID，然后在当前目录查找对应的资源文件，命名规则是：程序名+''.''+语言缩写，语言缩写可以参见附录1。在找不到时才会使用EXE文件中的资源。不过如果系统LCID是English(United States)，用户LCID是Chinese(PRC)，由VCL产生的程序就会出现乱码。读者可以自己分析原因。
为VCL程序做多语言版本。只要用Delphi自带的Resource DLL Wizard再做一个特定语言的资源DLL，原来的程序都不用改。不过很多程序员用其它组件做多语言版本，例如TsiLang 。
MBCS程序虽然也可以做成多语言版本，但它无法在同时显示不同代码页特有的字符，这时就必须使用Unicode程序了。
VS.NET文档中有个多语言资源的例子：SatDLL。它只用Win32 API的例子，却用了VC7项目。我在学习时将它改成了VC6项目，并纠正了它的两个问题：
1、用GetUserDefaultUILanguage读到的是Windows资源版本，不是当前用户设置的代码页。
2、没有使用资源DLL里的初始菜单。
在我的个人主页(http://fmddlmyy.home4u.china.com)上可以下载修改过的SatDLL。这个程序说明了支持多语言资源的基本思路：将不同语言资源放到不同的DLL中，在程序启动时根据当前Locale装载对应的资源DLL。必要时动态切换资源。为了标记不同语言的资源，可以将它们放到不同的目录中，以LCID作为目录名，例如“2052”、“1033”。
MFC程序可以在App类的InitInstance函数中用AfxSetResourceHandle函数设置资源DLL。在Delphi中动态切换资源可以参考Delphi Demo目录RichEdit项目的ReInit.pas。在读取当前设定时，建议用GetSystemDefaultLCID函数，因为系统Locale决定ANSI代码页。
3.4 资源和乱码
通过检查可执行文件，我们可以确定VC和Delphi的资源编译器都以Unicode保存字符资源。在VC环境编辑资源时，我们会指定资源的代码页。编译器根据资源的代码页，将其转换到Unicode。
Unicode程序直接使用以Unicode编码保存的资源。MBCS程序需要将Unicode资源先转换回当前ANSI代码页，然后再使用。如果资源中的Unicode字符串不能映射到当前代码页中的字符，就会出现??。
2 Locale和ANSI代码页
2.1 Locale和LCID
Locale是指特定于某个国家或地区的一组设定，包括字符集，数字、货币、时间和日期的格式等。在Windows中，每个Locale可以用一个32位数字表示，记作LCID。在winnt.h中可以看到LCID的组成。它的高16位表示字符的排序方法，一般为0。在它的低16位中，低10位是primary language的ID，高4位指定sublanguage。sublanguage被用来区分同一种语言的不同编码。下面是部分primary language和sublanguage的常数定义：
#define LANG_CHINESE 0x04
#define LANG_ENGLISH 0x09
#define LANG_FRENCH 0x0c
#define LANG_GERMAN 0x07
#define SUBLANG_CHINESE_TRADITIONAL 0x01 // Chinese (Taiwan Region)
#define SUBLANG_CHINESE_SIMPLIFIED 0x02 // Chinese (PR China)
#define SUBLANG_ENGLISH_US 0x01 // English (USA)
#define SUBLANG_ENGLISH_UK 0x02 // English (UK)
好，现在我们可以计算简体中文的LCID了，将sublanguage的常数左移10位，即乘上1024，再加上primary language的常数：2*1024+4=2052，16进制是0804。美国英语是：1*1024+9=1033，16进制是0409。。繁体中文是1*1024+4=1028，16进制是0404。
2.2 代码页
每个Locale都联系着很多信息，可以通过GetLocalInfo函数读取。其中最重要的信息就是字符集了，即Locale对应的语言文字的编码。Windows将字符集称作代码页。
每个Locale可以对应一个ANSI代码页和一个OEM代码页。Win32 API使用ANSI代码页，底层设备使用OEM代码页，两者可以相互映射。
例如English (US)的ANSI和OEM代码页分别为“1252 (ANSI - Latin I)”和“437 (OEM - United States)”。 Chinese (PRC)的ANSI和OEM代码页都是“950 (ANSI/OEM - Traditional Chinese Big5)”。 Chinese (TW)的ANSI和OEM代码页都是“936 (ANSI/OEM - Simplified Chinese GBK)”。
附录1中有一张很长的表。列出了我正在使用的Windows所支持的135个Locale的部分信息，包括 LCID、国家/地区名称、语言名称、语言缩写和对应的ANSI代码页。
2.3 系统Locale、用户Locale，再谈ANSI代码页
在Windows中，通过控制面板可以为系统和用户分别设置Locale。系统Locale决定代码页，用户Locale决定数字、货币、时间和日期的格式。这不是一个好的设计，后面会谈到它带来的问题。
使用GetSystemDefaultLCID函数和GetUserDefaultLCID函数分别得到系统和用户的LCID。有很多材料将这两个函数和另外两个函数混淆：GetSystemDefaultUILanguage和GetUserDefaultUILanguage。
GetSystemDefaultUILanguage和GetUserDefaultUILanguage得到的是您当前使用的Windows版本所带的UI资源的语言。
用户程序缺省使用的代码页是当前系统Locale的ANSI代码页，可以称作ANSI编码，也就是A版本的Win32 API默认的字符编码。对于一个未指定编码方式的文本文件，Windows会按照ANSI编码解释。
2.4 AppLocale
如果一个文本文件采用BIG5编码，系统当前的ANSI代码页是GBK。打开这个文件，就会显示乱码。例如“中文”在BIG5中的编码是A4A4、A4E5，这两个编码在GBK中对应的字符是“いゅ”。这是日文的两个平假名。
在Windows XP平台有一个AppLocale程序，可以以指定的语言运行非Unicode程序。用Win32dsm打开看一看，其实它只是在运行程序前设置了两个环境变量。我们可以用个批处理文件模仿一下：
@ECHO OFF
SET __COMPAT_LAYER=#ApplicationLocale
SET ApplocaleID=0404
start notepad.exe
在简体中文平台，用这个批处理文件启动的记事本可以正确显示BIG5编码的文本文件。用它打开GBK编码的文本文件会怎么样？“中文”会被显示为“笢恅”。设置这两个环境变量会作用于当前进程和其子进程。Windows 2000平台不支持这个方法。
3 MBCS程序和Unicode程序
3.1 与字符编码有关的编译参数
让我们回到Win32 API。我们在程序中使用的Win32 API没有A/W后缀，Windows的头文件会根据编译参数UNICODE将没有后缀的函数名替换为A版本或W版本，例如：
#ifdef UNICODE
#define CreateFile CreateFileW
#else
#define CreateFile CreateFileA
#endif
C RunTime库（CRT）也使用_UNICODE和_MBCS来区分三套字符串处理函数，分别用于SBCS、MBCS和Unicdoe字符串。SBCS和MBCS分别指单字节字符串和多字节字符串。例如_tcsclen的3个版本分别为strlen、_mbslen和wcslen ，猜猜以下函数返回几？
strlen(＂VOIP网关＂)；
_mbslen((unsigned char *)＂VOIP网关＂)；
wcslen(L＂VOIP网关＂)；
答案是8、6、6。L＂ANSI字符串＂通知编译器将ANSI字符串转换为Unicode字符串，这是VC++编译器提供的一个小甜点。不过我们应该用宏：_T(＂ANSI字符串＂)。_T宏只在我们定义了_UNICODE时才转换。这样同一套代码既可以编译MBCS版本，也可以编译Unicode版本。
MFC用_UNICODE参数区分Unicode版本特有的代码，决定使用什么版本的导入库或静态库。
3.2 Unicode程序、MBCS程序和多语言支持
Unicode程序直接使用Unicode版本的CRT和Win32 API。Unicode程序的运行与当前的ANSI代码页没有关系。MBCS程序的运行依赖于ANSI代码页。如果设计者和使用者使用不同的代码页，就可能出现乱码。微软开发的程序大都是Unicode程序，不管我们怎样变换系统Locale，它们总能正常运行。
使用VCL类库的Delphi程序都是MBCS程序。VCL框架在程序启动会调用GetThreadLocale获取当前用户的LCID，然后在当前目录查找对应的资源文件，命名规则是：程序名+''.''+语言缩写，语言缩写可以参见附录1。在找不到时才会使用EXE文件中的资源。不过如果系统LCID是English(United States)，用户LCID是Chinese(PRC)，由VCL产生的程序就会出现乱码。读者可以自己分析原因。
为VCL程序做多语言版本。只要用Delphi自带的Resource DLL Wizard再做一个特定语言的资源DLL，原来的程序都不用改。不过很多程序员用其它组件做多语言版本，例如TsiLang 。
MBCS程序虽然也可以做成多语言版本，但它无法在同时显示不同代码页特有的字符，这时就必须使用Unicode程序了。
VS.NET文档中有个多语言资源的例子：SatDLL。它只用Win32 API的例子，却用了VC7项目。我在学习时将它改成了VC6项目，并纠正了它的两个问题：
1、用GetUserDefaultUILanguage读到的是Windows资源版本，不是当前用户设置的代码页。
2、没有使用资源DLL里的初始菜单。
在我的个人主页(http://fmddlmyy.home4u.china.com)上可以下载修改过的SatDLL。这个程序说明了支持多语言资源的基本思路：将不同语言资源放到不同的DLL中，在程序启动时根据当前Locale装载对应的资源DLL。必要时动态切换资源。为了标记不同语言的资源，可以将它们放到不同的目录中，以LCID作为目录名，例如“2052”、“1033”。
MFC程序可以在App类的InitInstance函数中用AfxSetResourceHandle函数设置资源DLL。在Delphi中动态切换资源可以参考Delphi Demo目录RichEdit项目的ReInit.pas。在读取当前设定时，建议用GetSystemDefaultLCID函数，因为系统Locale决定ANSI代码页。
3.4 资源和乱码
通过检查可执行文件，我们可以确定VC和Delphi的资源编译器都以Unicode保存字符资源。在VC环境编辑资源时，我们会指定资源的代码页。编译器根据资源的代码页，将其转换到Unicode。
Unicode程序直接使用以Unicode编码保存的资源。MBCS程序需要将Unicode资源先转换回当前ANSI代码页，然后再使用。如果资源中的Unicode字符串不能映射到当前代码页中的字符，就会出现??。
bjbluecoffee 2005-09-06
- 打赏
- 举报
引用(『IT视界』 [大话IT]谈谈Windows程序中的字符编码
作者：寒潭惊鹤影 提交日期：2005-6-11 7:59:00 )：
写这篇文章的起因是这么一个问题：我们在使用和安装Windows程序时，有时会看到以“2052”、“1033”这些数字为名的文件夹，这些数字似乎和字符集有关，但它们究竟是什么意思呢？
研究这个问题的同时，又会遇到其它问题。我们会谈到Windows的内部架构、Win32 API的A/W函数、Locale、ANSI代码页、与字符编码有关的编译参数、MBCS和Unicode程序、资源和乱码等，一起经历这段琐碎细节为主，间或乐趣点缀的旅程。
0 Where is Win32 API
Windows程序有用户态和核心态的说法。在32位地址空间中，0x80000000以下属于用户态，0x80000000以上属于核心态。所有硬件管理都在核心态。用户态程序的不能直接使用核心态的任何代码。所谓核心态其实只是CPU的一种保护模式。在x86 CPU上，用户态处于ring 0，核心态处于ring 3。
从用户态进入核心态的最常用的方法是在寄存器eax填一个功能码，然后执行int 2e。这有点像DOS时代的DOS和BIOS系统调用。在NT架构中这种机制被称作system service。
在核心态提供system service的有两个家伙：ntoskrnl.exe和win32k.sys。ntoskrnl.exe是Windows的大脑，它的上层被称为Executive，下层被称作Kernel。Win32k.sys提供与显示有关的system service。
在用户态一侧，有一个重要的角色叫作ntdll.dll，大多数system service都是它调用的。它封装这些system service，然后提供一个API接口。这个接口被称作native API。 native API的用户是各个子系统（subsystem），包括Win32子系统、OS/2子系统、POSIX子系统。各个子系统为Win32、OS2、POSIX程序提供了运行平台。
ntdll.dll由于提供了平台无关的API接口，所以被看作是NT系统的原生接口，由之得到了“native API”的匪号。其实它的主要工作是将调用传递到核心态。
Win32、OS/2、POSIX，听起来很庞大。其实真正做好的只有Win32子系统。OS2、POSIX都是Console UI，即只有字符界面。提供OS/2子系统，只因为在1988年，NT的主要设计目标就是与OS/2兼容，后来由于Windows 3.0卖得很好，所以设计目标被变更为与Windows兼容。提供POSIX子系统，是为了应付美国政府的一个编号为FIPS 151-2的标准。
Win32子系统的管理员是一个叫作csrss.exe的弟兄，它的全名是：Client/Server Run-Time Subsystem。它刚上任时，本来要分管所有的子系统，但后来POSIX和OS/2都被分别处理了，所以只管了一个Win32。即使这样也很了不起，所有的Win32程序的进程、线程们都要向它登记。
不过Win32程序用得最多的还是Win32子系统的DLL们，最核心的DLL包括：kernel32.dll、User32.dll、Gdi32.dll、Advapi32.dll。这些DLL包装了ntdll.dll的native API。其中Gdi32.dll比较特殊，它与核心态的win32k.sys直接保持联系，以提高NT系统的图形处理能力。Win32子系统的DLL们提供的接口函数在MSDN文档中被详细介绍，它们就是Win32 API。
附录0 Windows的启动
计算机上电后，从BIOS的ROM开始运行。BIOS在做一些初始化后会将硬盘的第一个扇区的数据读入内存，然后将控制权交给它，这段数据被称作Master Boot Record（MBR）。
MBR包含一段启动代码和硬盘的主分区表。这段启动代码扫描主分区表，找到第一个可以启动的分区，然后将这个分区的第一个扇区读入内存并运行。这个扇区被称作引导扇区（boot sector）。
引导扇区的代码具备读文件系统根目录的能力，显然不同的文件系统需要不同的代码。引导扇区会从根目录中读出一个叫作ntldr的文件。顾名思义，这个文件是load NT的主要角色。它的业绩主要包括将CPU从实模式转入保护模式，启动分页机制，处理boot.ini等。
如果boot.ini中有一句：
C:\bootsect.rh=＂Red Hat Linux＂
bootsect.rh的内容是Linux引导扇区，用户又选择了“Red Hat Linux”，ntldr就会将执行Linux的引导扇区，开始Linux的引导。如果用户选择继续使用Windows，ntldr会装载并运行我们前面提到的ntoskrnl.exe。
ntoskrnl.exe会启动会话管理器smss.exe。smss.exe启动csrss.exe和winlogon.exe。smss.exe会永远等待csrss.exe和winlogon.exe返回。如果两者之一异常中止，就会导致系统崩溃。所以病毒们经常以打击csrss.exe为乐。
winlogon.exe负责用户登录，在完成登录后，它会启动注册表HKLM\SOFTWARE\Microsoft\Windows NT\Current Version\Winlogon项下Userinit值指定的程序。该值的缺省数据是userinit.exe。userinit.exe会装载个人设置，让硬盘响个不停，并考验我们的耐性，最后启动注册表同一项下Shell值指定的程序。该值的缺省数据是Explorer.exe。Explorer.exe运行后，我们就会看到熟悉的开始菜单和桌面。
1 Win32 API的A/W函数
要了解Win32子系统的DLL们提供了哪些API，最直接的方法就是用Win32dsm直接查看DLL们的导出表。这时我们会发现Win32 API中带字符串的API一般都有两个版本，例如CreateFileA和CreateFileW。当然也有例外，例如GetProcAddress函数。
A代表ANSI代码页，W是宽字符，即Unicode字符。Windows中的Unicode字符一般指UCS2的UTF16-LE编码。让我们通过几个实例观察A/W版本间的关系。
例1：用WIn32dsm查看gdi32.dll的汇编代码，可以看到TextOutA调用GdiGetCodePage获取当前代码页，再调用MultiByteToWideChar转换输入的字符串，然后调用一个内部函数。而TextOutW直接调用这个内部函数。
例2：用调试器跟踪一个使用了CreateFileA的程序，可以看到：CreateFileA在将输入字符串转换为Unicode后，会调用CreateFileW。假设输入文件名是“测试.txt”，对应的数据就是：“B2 E2 CA D4 2E 74 78 74 00”。
在调试器中可以看到传给CreateFileW的文件名数据是：“4B 6D D5 8B 2E 00 74 00 78 00 74 00 00 00”。 这是＂测试.txt＂对应的Unicdoe字符串。CreateFileW会接着调用ntdll.dll中的NtCreateFile。顺便看看NtCreateFile的代码：
mov eax, 00000020
lea edx, dword ptr [esp+04]
int 2E
ret 002C
可见这个native API只是简单地调用了核心态提供的0x20号system service。
例3：gdi32.dll中的GetGlyphOutline函数可以获取指定字符的字模。GetGlyphOutlineA和GetGlyphOutlineW函数都会调用同一个内部函数（记作F）。函数F在返回前将通过int 2E调用0x10B1号system service。
GetGlyphOutlineW直接调用函数F。GetGlyphOutlineA在调用函数F前，要依次调用GdiGetCodePage、IsDBCSLeadByteEx和MultiByteToWideChar，将当前代码页的字符编码转换成Unicode编码。
如果我们调用GetGlyphOutlineA时传入“baba”，这是“汉”字的GBK编码，用调试器可以看到传给函数F的字符编码是“6c49”，这是“汉”字的Unicode编码。
从以上例子可见，A版本总会在某处将输入的字符串转换为Unicode字符串，然后和W版本执行相同的代码。在由A/W版本API引出MBCS程序和Unicode程序前，让我们先解释一下Locale和ANSI代码页。
作者：寒潭惊鹤影 提交日期：2005-6-11 7:59:00 )：
写这篇文章的起因是这么一个问题：我们在使用和安装Windows程序时，有时会看到以“2052”、“1033”这些数字为名的文件夹，这些数字似乎和字符集有关，但它们究竟是什么意思呢？
研究这个问题的同时，又会遇到其它问题。我们会谈到Windows的内部架构、Win32 API的A/W函数、Locale、ANSI代码页、与字符编码有关的编译参数、MBCS和Unicode程序、资源和乱码等，一起经历这段琐碎细节为主，间或乐趣点缀的旅程。
0 Where is Win32 API
Windows程序有用户态和核心态的说法。在32位地址空间中，0x80000000以下属于用户态，0x80000000以上属于核心态。所有硬件管理都在核心态。用户态程序的不能直接使用核心态的任何代码。所谓核心态其实只是CPU的一种保护模式。在x86 CPU上，用户态处于ring 0，核心态处于ring 3。
从用户态进入核心态的最常用的方法是在寄存器eax填一个功能码，然后执行int 2e。这有点像DOS时代的DOS和BIOS系统调用。在NT架构中这种机制被称作system service。
在核心态提供system service的有两个家伙：ntoskrnl.exe和win32k.sys。ntoskrnl.exe是Windows的大脑，它的上层被称为Executive，下层被称作Kernel。Win32k.sys提供与显示有关的system service。
在用户态一侧，有一个重要的角色叫作ntdll.dll，大多数system service都是它调用的。它封装这些system service，然后提供一个API接口。这个接口被称作native API。 native API的用户是各个子系统（subsystem），包括Win32子系统、OS/2子系统、POSIX子系统。各个子系统为Win32、OS2、POSIX程序提供了运行平台。
ntdll.dll由于提供了平台无关的API接口，所以被看作是NT系统的原生接口，由之得到了“native API”的匪号。其实它的主要工作是将调用传递到核心态。
Win32、OS/2、POSIX，听起来很庞大。其实真正做好的只有Win32子系统。OS2、POSIX都是Console UI，即只有字符界面。提供OS/2子系统，只因为在1988年，NT的主要设计目标就是与OS/2兼容，后来由于Windows 3.0卖得很好，所以设计目标被变更为与Windows兼容。提供POSIX子系统，是为了应付美国政府的一个编号为FIPS 151-2的标准。
Win32子系统的管理员是一个叫作csrss.exe的弟兄，它的全名是：Client/Server Run-Time Subsystem。它刚上任时，本来要分管所有的子系统，但后来POSIX和OS/2都被分别处理了，所以只管了一个Win32。即使这样也很了不起，所有的Win32程序的进程、线程们都要向它登记。
不过Win32程序用得最多的还是Win32子系统的DLL们，最核心的DLL包括：kernel32.dll、User32.dll、Gdi32.dll、Advapi32.dll。这些DLL包装了ntdll.dll的native API。其中Gdi32.dll比较特殊，它与核心态的win32k.sys直接保持联系，以提高NT系统的图形处理能力。Win32子系统的DLL们提供的接口函数在MSDN文档中被详细介绍，它们就是Win32 API。
附录0 Windows的启动
计算机上电后，从BIOS的ROM开始运行。BIOS在做一些初始化后会将硬盘的第一个扇区的数据读入内存，然后将控制权交给它，这段数据被称作Master Boot Record（MBR）。
MBR包含一段启动代码和硬盘的主分区表。这段启动代码扫描主分区表，找到第一个可以启动的分区，然后将这个分区的第一个扇区读入内存并运行。这个扇区被称作引导扇区（boot sector）。
引导扇区的代码具备读文件系统根目录的能力，显然不同的文件系统需要不同的代码。引导扇区会从根目录中读出一个叫作ntldr的文件。顾名思义，这个文件是load NT的主要角色。它的业绩主要包括将CPU从实模式转入保护模式，启动分页机制，处理boot.ini等。
如果boot.ini中有一句：
C:\bootsect.rh=＂Red Hat Linux＂
bootsect.rh的内容是Linux引导扇区，用户又选择了“Red Hat Linux”，ntldr就会将执行Linux的引导扇区，开始Linux的引导。如果用户选择继续使用Windows，ntldr会装载并运行我们前面提到的ntoskrnl.exe。
ntoskrnl.exe会启动会话管理器smss.exe。smss.exe启动csrss.exe和winlogon.exe。smss.exe会永远等待csrss.exe和winlogon.exe返回。如果两者之一异常中止，就会导致系统崩溃。所以病毒们经常以打击csrss.exe为乐。
winlogon.exe负责用户登录，在完成登录后，它会启动注册表HKLM\SOFTWARE\Microsoft\Windows NT\Current Version\Winlogon项下Userinit值指定的程序。该值的缺省数据是userinit.exe。userinit.exe会装载个人设置，让硬盘响个不停，并考验我们的耐性，最后启动注册表同一项下Shell值指定的程序。该值的缺省数据是Explorer.exe。Explorer.exe运行后，我们就会看到熟悉的开始菜单和桌面。
1 Win32 API的A/W函数
要了解Win32子系统的DLL们提供了哪些API，最直接的方法就是用Win32dsm直接查看DLL们的导出表。这时我们会发现Win32 API中带字符串的API一般都有两个版本，例如CreateFileA和CreateFileW。当然也有例外，例如GetProcAddress函数。
A代表ANSI代码页，W是宽字符，即Unicode字符。Windows中的Unicode字符一般指UCS2的UTF16-LE编码。让我们通过几个实例观察A/W版本间的关系。
例1：用WIn32dsm查看gdi32.dll的汇编代码，可以看到TextOutA调用GdiGetCodePage获取当前代码页，再调用MultiByteToWideChar转换输入的字符串，然后调用一个内部函数。而TextOutW直接调用这个内部函数。
例2：用调试器跟踪一个使用了CreateFileA的程序，可以看到：CreateFileA在将输入字符串转换为Unicode后，会调用CreateFileW。假设输入文件名是“测试.txt”，对应的数据就是：“B2 E2 CA D4 2E 74 78 74 00”。
在调试器中可以看到传给CreateFileW的文件名数据是：“4B 6D D5 8B 2E 00 74 00 78 00 74 00 00 00”。 这是＂测试.txt＂对应的Unicdoe字符串。CreateFileW会接着调用ntdll.dll中的NtCreateFile。顺便看看NtCreateFile的代码：
mov eax, 00000020
lea edx, dword ptr [esp+04]
int 2E
ret 002C
可见这个native API只是简单地调用了核心态提供的0x20号system service。
例3：gdi32.dll中的GetGlyphOutline函数可以获取指定字符的字模。GetGlyphOutlineA和GetGlyphOutlineW函数都会调用同一个内部函数（记作F）。函数F在返回前将通过int 2E调用0x10B1号system service。
GetGlyphOutlineW直接调用函数F。GetGlyphOutlineA在调用函数F前，要依次调用GdiGetCodePage、IsDBCSLeadByteEx和MultiByteToWideChar，将当前代码页的字符编码转换成Unicode编码。
如果我们调用GetGlyphOutlineA时传入“baba”，这是“汉”字的GBK编码，用调试器可以看到传给函数F的字符编码是“6c49”，这是“汉”字的Unicode编码。
从以上例子可见，A版本总会在某处将输入的字符串转换为Unicode字符串，然后和W版本执行相同的代码。在由A/W版本API引出MBCS程序和Unicode程序前，让我们先解释一下Locale和ANSI代码页。
MapleInHG 2005-09-06
- 打赏
- 举报
查MSDN嘛，上述函数返回一个language id，下面是一个表（MSDN上的）：
0x0000 Language Neutral
0x007f The language for the invariant locale (LOCALE_INVARIANT). See MAKELCID.
0x0400 Process or User Default Language
0x0800 System Default Language
0x0436 Afrikaans
0x041c Albanian
0x0401 Arabic (Saudi Arabia)
0x0801 Arabic (Iraq)
0x0c01 Arabic (Egypt)
0x1001 Arabic (Libya)
0x1401 Arabic (Algeria)
0x1801 Arabic (Morocco)
0x1c01 Arabic (Tunisia)
0x2001 Arabic (Oman)
0x2401 Arabic (Yemen)
0x2801 Arabic (Syria)
0x2c01 Arabic (Jordan)
0x3001 Arabic (Lebanon)
0x3401 Arabic (Kuwait)
0x3801 Arabic (U.A.E.)
0x3c01 Arabic (Bahrain)
0x4001 Arabic (Qatar)
0x042b Windows 2000/XP: Armenian. This is Unicode only.
0x042c Azeri (Latin)
0x082c Azeri (Cyrillic)
0x042d Basque
0x0423 Belarusian
0x0402 Bulgarian
0x0455 Burmese
0x0403 Catalan
0x0404 Chinese (Taiwan)
0x0804 Chinese (PRC)
0x0c04 Chinese (Hong Kong SAR, PRC)
0x1004 Chinese (Singapore)
0x1404 Windows 98/Me, Windows 2000/XP: Chinese (Macau SAR)
0x041a Croatian
0x0405 Czech
0x0406 Danish
0x0465 Windows XP: Divehi. This is Unicode only.
0x0413 Dutch (Netherlands)
0x0813 Dutch (Belgium)
0x0409 English (United States)
0x0809 English (United Kingdom)
0x0c09 English (Australian)
0x1009 English (Canadian)
0x1409 English (New Zealand)
0x1809 English (Ireland)
0x1c09 English (South Africa)
0x2009 English (Jamaica)
0x2409 English (Caribbean)
0x2809 English (Belize)
0x2c09 English (Trinidad)
0x3009 Windows 98/Me, Windows 2000/XP: English (Zimbabwe)
0x3409 Windows 98/Me, Windows 2000/XP: English (Philippines)
0x0425 Estonian
0x0438 Faeroese
0x0429 Farsi
0x040b Finnish
0x040c French (Standard)
0x080c French (Belgian)
0x0c0c French (Canadian)
0x100c French (Switzerland)
0x140c French (Luxembourg)
0x180c Windows 98/Me, Windows 2000/XP: French (Monaco)
0x0456 Windows XP: Galician
0x0437 Windows 2000/XP: Georgian. This is Unicode only.
0x0407 German (Standard)
0x0807 German (Switzerland)
0x0c07 German (Austria)
0x1007 German (Luxembourg)
0x1407 German (Liechtenstein)
0x0408 Greek
0x0447 Windows XP: Gujarati. This is Unicode only.
0x040d Hebrew
0x0439 Windows 2000/XP: Hindi. This is Unicode only.
0x040e Hungarian
0x040f Icelandic
0x0421 Indonesian
0x0410 Italian (Standard)
0x0810 Italian (Switzerland)
0x0411 Japanese
0x044b Windows XP: Kannada. This is Unicode only.
0x0457 Windows 2000/XP: Konkani. This is Unicode only.
0x0412 Korean
0x0812 Windows 95, Windows NT 4.0 only: Korean (Johab)
0x0440 Windows XP: Kyrgyz.
0x0426 Latvian
0x0427 Lithuanian
0x0827 Windows 98 only: Lithuanian (Classic)
0x042f FYRO Macedonian
0x043e Malay (Malaysian)
0x083e Malay (Brunei Darussalam)
0x044e Windows 2000/XP: Marathi. This is Unicode only.
0x0450 Windows XP: Mongolian
0x0414 Norwegian (Bokmal)
0x0814 Norwegian (Nynorsk)
0x0415 Polish
0x0416 Portuguese (Brazil)
0x0816 Portuguese (Portugal)
0x0446 Windows XP: Punjabi. This is Unicode only.
0x0418 Romanian
0x0419 Russian
0x044f Windows 2000/XP: Sanskrit. This is Unicode only.
0x0c1a Serbian (Cyrillic)
0x081a Serbian (Latin)
0x041b Slovak
0x0424 Slovenian
0x040a Spanish (Spain, Traditional Sort)
0x080a Spanish (Mexican)
0x0c0a Spanish (Spain, International Sort)
0x100a Spanish (Guatemala)
0x140a Spanish (Costa Rica)
0x180a Spanish (Panama)
0x1c0a Spanish (Dominican Republic)
0x200a Spanish (Venezuela)
0x240a Spanish (Colombia)
0x280a Spanish (Peru)
0x2c0a Spanish (Argentina)
0x300a Spanish (Ecuador)
0x340a Spanish (Chile)
0x380a Spanish (Uruguay)
0x3c0a Spanish (Paraguay)
0x400a Spanish (Bolivia)
0x440a Spanish (El Salvador)
0x480a Spanish (Honduras)
0x4c0a Spanish (Nicaragua)
0x500a Spanish (Puerto Rico)
0x0430 Sutu
0x0441 Swahili (Kenya)
0x041d Swedish
0x081d Swedish (Finland)
0x045a Windows XP: Syriac. This is Unicode only.
0x0449 Windows 2000/XP: Tamil. This is Unicode only.
0x0444 Tatar (Tatarstan)
0x044a Windows XP: Telugu. This is Unicode only.
0x041e Thai
0x041f Turkish
0x0422 Ukrainian
0x0420 Windows 98/Me, Windows 2000/XP: Urdu (Pakistan)
0x0820 Urdu (India)
0x0443 Uzbek (Latin)
0x0843 Uzbek (Cyrillic)
0x042a Windows 98/Me, Windows NT 4.0 and later: Vietnamese
0x0000 Language Neutral
0x007f The language for the invariant locale (LOCALE_INVARIANT). See MAKELCID.
0x0400 Process or User Default Language
0x0800 System Default Language
0x0436 Afrikaans
0x041c Albanian
0x0401 Arabic (Saudi Arabia)
0x0801 Arabic (Iraq)
0x0c01 Arabic (Egypt)
0x1001 Arabic (Libya)
0x1401 Arabic (Algeria)
0x1801 Arabic (Morocco)
0x1c01 Arabic (Tunisia)
0x2001 Arabic (Oman)
0x2401 Arabic (Yemen)
0x2801 Arabic (Syria)
0x2c01 Arabic (Jordan)
0x3001 Arabic (Lebanon)
0x3401 Arabic (Kuwait)
0x3801 Arabic (U.A.E.)
0x3c01 Arabic (Bahrain)
0x4001 Arabic (Qatar)
0x042b Windows 2000/XP: Armenian. This is Unicode only.
0x042c Azeri (Latin)
0x082c Azeri (Cyrillic)
0x042d Basque
0x0423 Belarusian
0x0402 Bulgarian
0x0455 Burmese
0x0403 Catalan
0x0404 Chinese (Taiwan)
0x0804 Chinese (PRC)
0x0c04 Chinese (Hong Kong SAR, PRC)
0x1004 Chinese (Singapore)
0x1404 Windows 98/Me, Windows 2000/XP: Chinese (Macau SAR)
0x041a Croatian
0x0405 Czech
0x0406 Danish
0x0465 Windows XP: Divehi. This is Unicode only.
0x0413 Dutch (Netherlands)
0x0813 Dutch (Belgium)
0x0409 English (United States)
0x0809 English (United Kingdom)
0x0c09 English (Australian)
0x1009 English (Canadian)
0x1409 English (New Zealand)
0x1809 English (Ireland)
0x1c09 English (South Africa)
0x2009 English (Jamaica)
0x2409 English (Caribbean)
0x2809 English (Belize)
0x2c09 English (Trinidad)
0x3009 Windows 98/Me, Windows 2000/XP: English (Zimbabwe)
0x3409 Windows 98/Me, Windows 2000/XP: English (Philippines)
0x0425 Estonian
0x0438 Faeroese
0x0429 Farsi
0x040b Finnish
0x040c French (Standard)
0x080c French (Belgian)
0x0c0c French (Canadian)
0x100c French (Switzerland)
0x140c French (Luxembourg)
0x180c Windows 98/Me, Windows 2000/XP: French (Monaco)
0x0456 Windows XP: Galician
0x0437 Windows 2000/XP: Georgian. This is Unicode only.
0x0407 German (Standard)
0x0807 German (Switzerland)
0x0c07 German (Austria)
0x1007 German (Luxembourg)
0x1407 German (Liechtenstein)
0x0408 Greek
0x0447 Windows XP: Gujarati. This is Unicode only.
0x040d Hebrew
0x0439 Windows 2000/XP: Hindi. This is Unicode only.
0x040e Hungarian
0x040f Icelandic
0x0421 Indonesian
0x0410 Italian (Standard)
0x0810 Italian (Switzerland)
0x0411 Japanese
0x044b Windows XP: Kannada. This is Unicode only.
0x0457 Windows 2000/XP: Konkani. This is Unicode only.
0x0412 Korean
0x0812 Windows 95, Windows NT 4.0 only: Korean (Johab)
0x0440 Windows XP: Kyrgyz.
0x0426 Latvian
0x0427 Lithuanian
0x0827 Windows 98 only: Lithuanian (Classic)
0x042f FYRO Macedonian
0x043e Malay (Malaysian)
0x083e Malay (Brunei Darussalam)
0x044e Windows 2000/XP: Marathi. This is Unicode only.
0x0450 Windows XP: Mongolian
0x0414 Norwegian (Bokmal)
0x0814 Norwegian (Nynorsk)
0x0415 Polish
0x0416 Portuguese (Brazil)
0x0816 Portuguese (Portugal)
0x0446 Windows XP: Punjabi. This is Unicode only.
0x0418 Romanian
0x0419 Russian
0x044f Windows 2000/XP: Sanskrit. This is Unicode only.
0x0c1a Serbian (Cyrillic)
0x081a Serbian (Latin)
0x041b Slovak
0x0424 Slovenian
0x040a Spanish (Spain, Traditional Sort)
0x080a Spanish (Mexican)
0x0c0a Spanish (Spain, International Sort)
0x100a Spanish (Guatemala)
0x140a Spanish (Costa Rica)
0x180a Spanish (Panama)
0x1c0a Spanish (Dominican Republic)
0x200a Spanish (Venezuela)
0x240a Spanish (Colombia)
0x280a Spanish (Peru)
0x2c0a Spanish (Argentina)
0x300a Spanish (Ecuador)
0x340a Spanish (Chile)
0x380a Spanish (Uruguay)
0x3c0a Spanish (Paraguay)
0x400a Spanish (Bolivia)
0x440a Spanish (El Salvador)
0x480a Spanish (Honduras)
0x4c0a Spanish (Nicaragua)
0x500a Spanish (Puerto Rico)
0x0430 Sutu
0x0441 Swahili (Kenya)
0x041d Swedish
0x081d Swedish (Finland)
0x045a Windows XP: Syriac. This is Unicode only.
0x0449 Windows 2000/XP: Tamil. This is Unicode only.
0x0444 Tatar (Tatarstan)
0x044a Windows XP: Telugu. This is Unicode only.
0x041e Thai
0x041f Turkish
0x0422 Ukrainian
0x0420 Windows 98/Me, Windows 2000/XP: Urdu (Pakistan)
0x0820 Urdu (India)
0x0443 Uzbek (Latin)
0x0843 Uzbek (Cyrillic)
0x042a Windows 98/Me, Windows NT 4.0 and later: Vietnamese
yqzq 2005-09-06
- 打赏
- 举报
能否详细点，谢谢
MapleInHG 2005-09-06
- 打赏
- 举报
GetSystemDefaultLangID()??
yqzq 2005-09-06
- 打赏
- 举报
散分！
