谈谈Windows程序中的字符编码（1）

写这篇文章的起因是这么一个问题：我们在使用和安装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 3，核心态处于ring 0。
从用户态进入核心态的最常用的方法是在寄存器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 VersionWinlogon项下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代码页。