本地化的问题就是处理不同字符集的问题。多年来，我们一直在将文本字符串编码成一组以
0结尾的单字节字符。许多人对此已经习已为常。调用strlen，它会返回“以0结尾的一个ANSI
单字节字符数组”中的字符数。
问题是，某些语言和书写系统（例如日本汉字）的字符集有非常多的符号。一个字节最多只
能表示256个符号，因此是远远不够的。为了支持这些语言和书写系统，双字节字符集
（double-byte character set，DBCS）应运而生。在双字节字符集中，一个字符串中的每个字
符都由1个或2个字节组成。以日本汉字为例，如果第一个字符在0x81到0x9F之间，或者在
0xE0到0xFC之间，就必须检查下一个字节，才能判断出一个完整的汉字。对程序员而言，
和双字节字符集打交道如同一场噩梦，因为某些字符是1个字节宽，而有的字符却是2个字节
宽。幸运的是，我们可以把DBCS放到一边，专心利用Windows函数和C运行库对Unicode字
符串的支持。
Unicode是1988年由Apple和Xerox共同建立的一项标准。1991年，成立了专门的协会来开发
和推动Unicode。该协会由Apple、 Compaq、Hewlett-Packard、IBM、Microsoft、 Oracle、Silicon
Graphics、Sybase、Unisys和Xerox等多家公司组成（协会成员的最新列表可从
http://www.Unicode.org获得）。该组织负责维护Unicode标准。Unicode的完整描述可以参考
Addison-Wesley出版的The Unicode Standard一书，该书可通过http://www.Unicode.org获得。
在Windows Vista中，每个Unicode字符都使用UTF-16编码，UTF的全称是Unicode
Transformation Format（ Unicode转换格式）。UTF-16将每个字符编码为2个字节（或者说16
位）。在本书中，我们在谈到Unicode时，除非专门声明，否则一般都是指UTF-16编码。
Windows之所以使用UTF-16，是因为全球各地使用的大部分语言中，每个字符很容易用一
个16位值来表示。这样一来，应用程序很容易遍历字符串并计算出它的长度。但是，16位不
足以表示某些语言的所有字符。对于这些语言，UTF-16支持使用代理（surrogates），后者
是用32位（或者说4个字节）来表示一个字符的一种方式。由于只有少数应用程序需要表示
这些语言中的字符，所以UTF-16在节省空间和简化编码这两个目标之间，提供了一个很好
的折衷。注意，.NET Framework始终使用UTF-16来编码所有字符和字符串，所以在你自己
的Windows应用程序中，如果需要在原生代码（native code）和托管代码（managed code）
之间传递字符或字符串，使用UTF-16能改进性能和减少内存消耗。
另外还有其他用于表示字符的UTF标准，具体如下。
¾ UTF-8 UTF-8将一些字符编码为1个字节，一些字符编码为2个字节，一些字符编
码为3个字节，一些字符编码为4个字节。值在0x0080以下的字符压缩为1个字节，
这对美国使用的字符非常适合。0x0080和0x07FF之间的字符转换为2个字节，这对
欧洲和中东地区的语言非常适用。0x0800以上的字符都转换为3个字节，适合东亚
地区的语言。最后，代理对（surrogate pairs）被写为4个字节。UTF-8是一种相当
流行的编码格式。但在对值为0x0800及以上的大量字符进行编码的时候，不如
UTF-16高效。
¾ UTF-32 UTF-32将每个字符都编码为4个字节。如果打算写一个简单的算法来遍
历字符（任何语言中使用的字符），但又不想处理字节数不定的字符，这种编码方
式就非常有用。例如，如果采用UTF-32编码方式，就不需要关心代理（surrogate）
的问题，因为每个字符都是4个字符。显然，从内存使用这个角度来看，UTF-32 并
不是一种高效的编码格式。因此，很少用它将字符串保存到文件或传送到网络。这
种编码格式一般在应用程序内部使用。
目前，Unicode为阿拉伯语、汉语拼音、西里尔文（俄语）、希腊语、希伯来语、日语假名、
朝鲜语和拉丁语（英语）字符等——这些字符称为书写符号（scripts）——定义了码位（code point，即一个符号在字符集中的位置）。每个版本的Unicode都在现有的书写符号的基础上
引入了新的字符，甚至会引入新的书写符号，比如腓尼基文（一种古地中海文字）。字符集
中还包含大量标点符号、数学符号、技术符号、箭头、装饰标志、读音符号以及其他字符。