1．进程和线程的差别。

线程是指进程内的一个执行单元,也是进程内的可调度实体.
(1)调度：线程作为调度和分配的基本单位，进程作为拥有资源的基本单位(2)并发性：不仅进程之间可以并发执行，同一个进程的多个线程之间也可并发执行(3)拥有资源：进程是拥有资源的独立单位，线程不拥有系统资源，但可以访问隶属于进程的资源.
(4)系统开销：在创建或撤消进程时，由于系统都要为之分配和回收资源，导致系统的开销明显大于创建或撤消线程时的开销。

6．C/C++编译器中虚表是如何完成的？

7．谈谈COM的线程模型。然后讨论进程内/外组件的差别。

8．谈谈IA32下的分页机制

小页(4K)两级分页模式，大页(4M)一级

9．给两个变量，如何找出一个带环单链表中是什么地方出现环的？

一个递增一，一个递增二，他们指向同一个接点时就是环出现的地方 ？？

10．在IA32中一共有多少种办法从用户态跳到内核态？

11．如果只想让程序有一个实例运行，不能运行两个。像winamp一样，只能开一个窗口，怎样实现？

用内存映射或全局原子（互斥变量）、查找窗口句柄..
FindWindow，互斥，写标志到文件或注册表,共享内存。.　

12．如何截取键盘的响应，让所有的‘a’变成‘b’？

13．Apartment在COM中有什么用？为什么要引入？

14．存储过程是什么？有什么用？有什么优点？

存储过程（Stored Procedure）是一组为了完成特定功能的SQL 语句集，经编译后存储在数据库。中用户通过指定存储过程的名字并给出参数（如果该存储过程带有参数）来执行它。

存储过程用于实现频繁使用的查询、业务规则、被其他过程使用的公共例行程序

存储过程在创建时即在服务器上进行编译，所以执行起来比单个 SQL 语句快

15．Template有什么特点？什么时候用？

今天群硕笔试，考了好多内容，其中Java占很大部分！

本试卷中最有难度的编程题：给定一个数组，这个数组中既有正数又有负数，找出这个数组中的子数组，此子数组的和最大！

thinking:检测电冰箱（我用软件工程的思想随便写写）

的最大区别。 和ADO 的区别？答案：实际上除了“能够让应用程序处理存储于DBMS 中的数据“这一基本相似点外，两者没有太多共同之处。但是ADO 使用OLE DB 接口并基于微软的COM 技术，而 接口并且基于微软的.NET 体系架构。众所周知.NET 体系不同于COM 体系， 和ADO是两种数据访问方式。，看起来好像这些概念都广泛被PHP开发人员所了解。这就说明了PHP实际上到底是多专业。

　　对于非常小的项目，它可以是一个十分符合人意的编程语言。但是对于较大的和更为复杂的项目，PHP就显出他的薄弱了。当你不断地摸索之后，你会发现笔者提到的某些问题的解决方案。所以，当解决方案已知之后，为什么不能修正他呢？另外为什么这些修补不在手册中提到呢？

　　一个开源的语言十分流行是一件好事。但不幸得是，它不是一个伟大的语言。笔者希望所有的问题能有一天得到解决（也许在PHP6？），然后我们就将拥有一个开源语言，他既开源，又好用。

三、编程题：30分 共1题 注意：要求提供完整代码，如果可以编译运行酌情加分。

1. 两个已排序的整型数组，求交集，最快算法 输入：两个已排序的整型数组（int a[m], b[n]） 输出：两个数组的交集

四、设计题：35分 共1题 注意：请尽可能详细描述你的数据结构、系统架构、设计思路等。建议多写一些伪代码或者流程说明。1. 考虑一个字符串替换的过程，在一个文本文件中含有一些文本内容和一些需要替换的变量，变量的格式为“$Var$”，原来的“$”使用“$$”进行转义，原来的“$$”表示为“$$$”。我们将含有变量的文件称为模板(文件名为t)，文本文件的平均长度为100K。另外，还有一系列的变量文件，里面为变量名和变量值的对应关系(文件名为1.v

百度11月4日网上笔试题及答案（仅供参考）1用C语言实现一个revert函数，它的功能是将输入的字符串在原串上倒序后返回。2 函数的功能是拷贝src所指的内存内容前n个字节到dest所指的地址上。3 英文拼写纠错：在用户输入英文单词时，经常发生错误，我们需要对其进行纠错。假设已经有一个包含了正确英文单词的词典，请你设计一个拼写纠错的程序。（1）请描述你解决这个问题的思路；
（2）请给出主要的处理流程，算法，以及算法的复杂度；（3）请描述可能的改进（改进的方向如效果，性能等等，这是一个开放问题）。4 寻找热门查询：搜索引擎会通过日志文件把用户每次检索使用的所有检索串都记录下来，每个查询串的长度为1-255字节。假设目前有一千万个记录，这些查询串的重复度比较高，虽然总数是1千万，但如果除去重复后，不超过3百万个
。一个查询串的重复度越高，说明查询它的用户越多，也就是越热门。请你统计最热门的10个查询串，要求使用的内存不能超过1G。（1）请描述你解决这个问题的思路；（2）请给出主要的处理流程，算法，以及算法的复杂度。5 要求将其中交集不为空的集合合并，要求合并完成后的集合之间无交集，例如上例应输出{aaa bbb ccc ddd hhh}，{eee fff}， {ggg}
（1）请描述你解决这个问题的思路；（2）请给出主要的处理流程，算法，以及算法的复杂度（3）请描述可能的改进（改进的方向如效果，性能等等，这是一个开放问题）。1
字典以字母键树组织，在用户输入同时匹配(2)流程:
沿字典树向下一层，a）若可以顺利下行，则继续至结束，给出结果；b)若该处不能匹配，纠错处理，给出拼写建议,继续至a）；算法:
1.在字典中查找单词字典采用27叉树组织,每个节点对应一个字母,查找就是一个字母一个字母匹配.算法时间就是单词的长度k.
2.纠错算法情况:当输入的最后一个字母不能匹配时就提示出错,简化出错处理，动态提示可能 处理方法:
(a)当前字母前缺少了一个字母：搜索树上两层到当前的匹配作为建议；(b)当前字母拼写错误：当前字母的键盘相邻作为提示；（只是简单的描述，可以有更多的）根据分析字典特征和用户单词已输入部分选择(a),(b)处理复杂性分析：影响算法的效率主要是字典的实现与纠错处理
（a）字典的实现已有成熟的算法，改进不大，也不会成为瓶颈；(b)纠错策略要简单有效 ,如前述情况，是线性复杂度；(3)改进策略选择最是重要，可以采用统计学习的方法改进。//
题(1)思路：用哈希做(2)首先逐次读入查询串，算哈希值，保存在内存数组中，同时统计频度（注意值与日志项对应关系）
选出前十的频度，取出对应的日志串，简单不过了。哈希的设计是关键。 //
题（1）思路：先将集合按照大小排列后,优先考虑小的集合是否与大的集合有交集。有就合并，如果小集合与所有其他集合都没有交集，则独立。独立的集合在下一轮的比较中不用考虑。这样就可以尽量减少字符串的比较次数。当所有集合都独立的时候，
就终止。（2）处理流程：1.将集合按照大小排序，组成集合合并待处理列表2.选择最小的集合，找出与之有交集的集合，
如果有，合并之；如果无，则与其它集合是独立集合，从待处理列表 中删除。3.重复直到待处理列表为空算法：1。将集合按照大小从小到大排序,组成待处理的集合列表。2。取出待处理集合列表中最小的集合，对于集合的每个元素，依次在其他集合中搜索
是否有此元素存在：1>若存在，则将此小集合与大集合合并，并根据大小插入对应的位置 。转3
。2>若不存在，则在该集合中取下一个元素。如果无下一个元素，即所有元素都不存在于其他集合。则表明此集合独立，从待处理集合列表中删除。并加入结果集合列表。转3。
3。如果待处理集合列表不为空，转2。如果待处理集合列表为空，成功退出，则结果集合列表就是最终的输出。算法复杂度分析：假设集合的个数为n，最大的集合元素为m
排序的时间复杂度可以达到n*log(n)
然后对于元素在其他集合中查找，最坏情况下为（n-1）*m
查找一个集合是否与其他集合有交集的最坏情况是m*m*(n-1)
合并的时间复杂度不会超过查找集合有交集的最坏情况。所以最终最坏时间复杂度为O(m*m*n*n)
需要说明的是：此算法的平均时间复杂度会很低，因为无论是查找还是合并，都是处于最坏情况的概率很小，而且排序后优先用最小集合作为判断是否独立的对象，优先与最大的集合进行比较，这些都最大的回避了最坏情况。(3)可能的改进：
首先可以实现将每个集合里面的字符串按照字典序进行排列，这样就可以将查找以及合并的效率增高。另外，可能采取恰当的数据结构也可以将查找以及合并等操作的效率得到提高

写一段程序，找出数组中第k大小的数，输出数所在的位置。例如{2，4，3，4，7}中，第一大的数是7，位置在4。第二大、第三大的数都是4，位置在1、3随便输出哪一个均可。函数接口为：int find_orderk(const int * narry, const int n, const int k)
要求算法复杂度不能是O(n^2）

2可以先用快速排序进行排序，其中用另外一个进行地址查找 代码如下，在VC++6.0运行通过。

1 用C++开发的时候，用来做基类的类的析构函数一般都是虚函数。

这个很简单，非常好理解。 但是，如果把类ClxBase析构函数前的virtual去掉，那输出结果就是下面的样子了：

也就是说，类ClxDerived的析构函数根本没有被调用！一般情况下类的析构函数里面都是释放内存资源，而析构函数不被调用的话就会造成内存泄漏。我想所有的C++程序员都知道这样的危险性。当然，如果在析构函数中做了其他工作的话，那你的所有努力也都是白费力气。所以，文章开头的那个问题的答案就是－－这样做是为了当用一个基类的指针删除一个派生类的对象时，派生类的析构函数会被调用。

我曾经写过一篇（以下简称《谈谈Unicode编码》），在网上流传较广，我也收到不少朋友的反馈。本文探讨《谈谈Unicode编码》中未介绍或介绍较少的代码页、Surrogates等问题，补充一些Unicode资料，顺带介绍一下我最近编写的一个Unicode工具：UniToy。本文虽然是前文的补充，但在写作上尽量做到独立成篇。

标题中的“浅谈”是对自己的要求，我希望文字能尽量浅显易懂。但本文还是假设读者知道字节、16进制，了解《谈谈Unicode编码》中介绍过的字节序和Unicode的基本概念。

UniToy是我编写的一个小工具。通过UniToy，我们可以全方位、多角度地查看Unicode，了解Unicode和语言、代码页的关系，完成一些文字编码的相关工作。本文的一些内容是通过UniToy演示的。大家可以从我的网站（ ）下载UniToy的 。

我们首先以Windows为例来看看文字显示过程中发生了什么。用记事本打开一个文本文件，可以看到文件包含的文字：

EB”，这就是记事本从文件中读到的内容。记事本是用来打开文本文件的，所以它会调用Windows的文本显示函数将读到的数据作为文本显示。Windows首先将文本数据转换到它内部使用的编码格式：Unicode，然后按照文本的Unicode去字体文件中查找字体图像，最后将图像显示到窗口上。总结一下前面的分析，文字的显示应该是这样的：

• 步骤1：文字首先以某种编码保存在文件中。
• 步骤2：Windows将文件中的文字编码映射到Unicode。
• 步骤3：Windows按照Unicode在字体文件中查找字体图像，画到窗口上。

所谓编码就是用数字表示字符，例如用D7D6表示“字”。当然，编码还意味着约定，即大家都认可。从《谈谈Unicode编码》中，我们知道Unicode也是一种文字编码，它的特殊性在于它是由国际组织设计，可以容纳全世界所有语言文字。而我们平常使用的文字编码通常是针对一个区域的语言、文字设计，只支持特定的语言文字。例如：在上面的例子中，文件“例子GBK.txt”采用的就是GBK编码。

如果上述3个步骤中任何一步发生了错误，文字就不能被正确显示，例如：

• 错误1：如果弄错了编码，例如将Big5编码的文字当作GBK编码，就会出现乱码。

• 错误2：如果从特定编码到Unicode的映射发生错误，例如文本数据中出现该编码方案未定义的字符，Windows就会使用缺省字符，通常是?。

• 如果当前字体不支持要显示的字符，Windows就会显示字体文件中的缺省图像：空白或方格。

在Unicode被广泛使用前，有多少种语言、文字，就可能有多少种文字编码方案。一种文字也可能有多种编码方案。那么我们怎么确定文本数据采用了什么编码？

1.2 采用了哪种编码？

按照惯例，文本文件中的数据都是文本编码，那么它怎么表明自己的编码格式？在记事本的“打开”对话框上：

在《谈谈Unicode编码》中介绍过，Windows通过在文本文件开头增加一些特殊字节（BOM）来区分上述3种编码，并将没有BOM的文本数据按照ANSI代码页处理。那么什么是代码页，什么是ANSI代码页？

代码页（Code Page）是个古老的专业术语，据说是IBM公司首先使用的。代码页和字符集的含义基本相同，代码页规定了适用于特定地区的字符集合，和这些字符的编码。可以将代码页理解为字符和字节数据的映射表。

Windows为自己支持的代码页都编了一个号码。例如代码页936就是简体中文 GBK，代码页950就是繁体中文 Big5。代码页的概念比较简单，就是一个字符编码方案。但要说清楚Windows的ANSI代码页，就要从Windows的区域（Locale）说起了。

微软为了适应世界上不同地区用户的文化背景和生活习惯，在Windows中设计了区域（Locale）设置的功能。Local是指特定于某个国家或地区的一组设定，包括代码页，数字、货币、时间和日期的格式等。在Windows内部，其实有两个Locale设置：系统Locale和用户Locale。系统Locale决定代码页，用户Locale决定数字、货币、时间和日期的格式。我们可以在控制面板的“区域和语言选项”中设置系统Locale和用户Locale：

每个Locale都有一个对应的代码页。Locale和代码页的对应关系，大家可以参阅我的另一篇文章的附录1。系统Locale对应的代码页被作为Windows的默认代码页。在没有文本编码信息时，Windows按照默认代码页的编码方案解释文本数据。这个默认代码页通常被称作ANSI代码页（ACP）。

ANSI代码页还有一层意思，就是微软自己定义的代码页。在历史上，IBM的个人计算机和微软公司的操作系统曾经是PC的标准配置。微软公司将IBM公司定义的代码页称作OEM代码页，在IBM公司的代码页基础上作了些增补后，作为自己的代码页，并冠以ANSI的字样。我们在“区域和语言选项”高级页面的代码页转换表中看到的包含ANSI字样的代码页都是微软自己定义的代码页。例如：

在UniToy中，我们可以按照代码页编码顺序查看这些代码页的字符和编码：

我们不能直接设置ANSI代码页，只能通过选择系统Locale，间接改变当前的ANSI代码页。微软定义的Locale只使用自己定义的代码页。所以，我们虽然可以通过“区域和语言选项”中的代码页转换表安装很多代码页，但只能将微软的代码页作为系统默认代码页。

2000以后，Windows统一采用UTF-16作为内部字符编码。现在，安装一个代码页就是安装一张代码页转换表。通过代码页转换表，Windows既可以将代码页的编码转换到UTF-16，也可以将UTF-16转换到代码页的编码。代码页转换表的具体实现可以是一个以nls为后缀的数据文件，也可以是一个提供转换函数的动态链接库。有的代码页是不需要安装的。例如：Windows将UTF-7和UTF-8分别作为代码页65000和代码页65001。UTF-7、UTF-8和UTF-16都是基于Unicode的编码方案。它们之间可以通过简单的算法直接转换，不需要安装代码页转换表。

在安装过一个代码页后，Windows就知道怎样将该代码页的文本转换到Unicode文本，也知道怎样将Unicode文本转换成该代码页的文本。例如：UniToy有导入和导出功能。所谓导入功能就是将任一代码页的文本文件转换到Unicode文本；导出功能就是将Unicode文本转换到任一指定的代码页。这里所说的代码页就是指系统已安装的代码页：

其实，如果全世界人民在计算机刚发明时就统一采用Unicode作为字符编码，那么代码页就没有存在的必要了。可惜在Unicode被发明前，世界各国人民都发明并使用了各种字符编码方案。所以，Windows必须通过代码页支持已经被广泛使用的字符编码。从这种意义看，代码页主要是为了兼容现有的数据、程序和习惯而存在的。

SBCS、DBCS和MBCS分别是单字节字符集、双字节字符集和多字节字符集的缩写。SBCS、DBCS和MBCS的最大编码长度分别是1字节、两字节和大于两字节（例如4或5字节）。例如：代码页1252 （ANSI-拉丁文 I）是单字节字符集；代码页936 （ANSI/OEM-简体中文 GBK）是双字节字符集；代码页54936 （GB18030 简体中文）是多字节字符集。

单字节字符集中的字符都用一个字节表示。显然，SBCS最多只能容纳256个字符。

双字节字符集的字符用一个或两个字节表示。那么我们从文本数据中读到一个字节时，怎么判断它是单字节字符，还是双字节字符的首字符？答案是通过字节所处范围来判断。例如：在GBK编码中，单字节字符的范围是0x00-0x80，双字节字符首字节的范围是0x81到0xFE。我们顺序读取字节数据，如果读到的字节在0x81到0xFE内，那么这个字节就是双字节字符的首字节。GBK定义双字节字符的尾字节范围是0x40到0x7E和0x80到0xFE。

GB18030是多字节字符集，它的字符可以用一个、两个或四个字节表示。这时我们又如何判断一个字节是属于单字节字符，双字节字符，还是四字节字符？GB18030与GBK是兼容的，它利用了GBK双字节字符尾字节的未使用码位。GB18030的四字节字符的第一字节的范围也是0x81到0xFE，第二字节的范围是0x30-0x39。通过第二字节所处范围就可以区分双字节字符和四字节字符。GB18030定义四字节字符的第三字节范围是0x81到0xFE，第四字节范围是0x30-0x39。

1.1节的“错误2”中演示了一个全被显示成'?'的文件。这个文件的数据是：

其实，这是一个包含了6个四字节字符的GB18030编码的文件。记事本按照GBK显示这些数据，而GB18030的四字节字符编码在GBK中是未定义的。Windows根据首字节范围判断出12个双字节字符，然后因为找不到匹配的转换而将其映射到默认字符'?'。使用UniToy按照GB18030代码页导入这个文件，就可以看到：

这个GB18030编码的文件是用UniToy创建的，编辑Unicode文本，然后导出到GB18030编码格式。

综合使用UniToy的导入、导出功能就可以在任意两个代码页之间转换文本。其实，由于各代码页支持的字符范围不同，我们一般不会直接在代码页间转换文本。例如将以下GBK编码的文本：

直接转换到Big5编码，就会看到：

变成'?'的字符都是Big5编码不支持的简化字。在从Unicode转换到Big5编码时，由于Big5编码不支持这些字符，Windows就用默认字符'?'代替。在UniToy中，我们可以先将简体字转换到繁体字，然后再导出到Big5编码，就可以正常显示：

同理，将Big5编码的文本转换到GBK编码的步骤应该是：

• 将Big5编码的文本导入到Unicode文本；
• 将简体的Unicode文本导出到GBK文本。

2.3 互联网的字符集

互联网上的信息缤纷多彩，但文本依然是最重要的信息载体。html文件通过标记表明自己使用的字符集。例如：

那么我们可以使用哪些字符集（charset）呢？在IETF（互联网工程任务组）的网页上维护着一份可以在互联网上使用的字符集的清单：。如果有新的字符集被登记，IETF会更新这份文档。

简单浏览一下，2006年12月7日的版本列出了253个字符集。其中也包括微软的CP1250 ~ CP1258，在这里它们不会被称作什么ANSI代码页，而是被简单地称作windows-1250、windows-1251等。其实在Unicode被广泛使用前，除了中日韩等大字符集，世界上，特别是西方使用最广泛的字符集应该是ISO 8859系列字符集。

ISO 8859系列字符集是欧洲计算机制造商协会（ECMA）在上世纪80年代中期设计，并被国际标准化（ISO）组织采纳为国际标准。ISO 8859系列字符集目前有15个字符集，包括：

• ISO 8859-1 大部分的西欧语系，例如英文、法文、西班牙文和德文等（Latin-1）
• ISO 8859-2 大部分的中欧和东欧语系，例如捷克文、波兰文和匈牙利文等（Latin-2）
• ISO 8859-5 拉丁文与斯拉夫文（俄文、保加利亚文等）

其中缺少的编号12据说是为了预留给天城体梵文字母（Deva-nagari）的。印地文和尼泊尔文都使用了这种在七世纪形成的字母表。由于印度定义了自己的编码ISCII（Indian Script Code for Information Interchange），所以这个编号就未被使用。ISO 8859系列字符集都是单字节字符集，即只使用0x00-0xFF对字符编码。

大家都知道ASCII吧，那么大家知道ANSI X3.4和ISO 646吗？在1968年发布的ANSI X3.4和1972年发布的ISO 646就是ASCII编码，只不过是不同组织发布的。绝大多数字符集都与ASCII编码保持兼容，ISO 8859系列字符集也不例外，它们的0x00-0x7f都与ASCII码保持一致，各字符集的不同之处在于如何利用0x80-0xff的码位。使用UniToy可以查看ISO 8859系列所有字符集的编码，例如：

通过这些演示，大家是不是觉得代码页和字符集都是很简单、朴实的东西呢？好，在进入Unicode的话题前，让我们先看一个很深奥的概念。

程序员经常会面对复杂的问题，而降低复杂性的最简单的方法就是分而治之。Peter Constable在他的文章中描述了字符编码的四层模型。我觉得这种说法确实可以更清晰地展现字符编码中发生的事情，所以在这里也介绍一下。

设计字符编码的第一层就是确定字符的范围，即要支持哪些字符。有些编码方案的字符范围是固定的，例如ASCII、ISO 8859 系列。有些编码方案的字符范围是开放的，例如Unicode的字符范围就是世界上所有的字符。

设计字符编码的第二层是将字符和数字对应起来。可以将这个层次理解成数学家（即从数学角度）看到的字符编码。数学家看到的字符编码是一个正整数。例如在Unicode中：汉字“字”对应的数字是23383。汉字“”对应的数字是134192。

在写html文件时，可以通过输入"字"来插入字符“字”。不过在设计字符编码时，我们还是习惯用16进制表示数字。即将23383写成0x5BD7，将134192写成0x20C30。

设计字符编码的第三层是用编程语言中的基本数据类型来表示字符。可以将这个层次理解成程序员看到的字符编码。在Unicode中，我们有很多方式将数字23383表示成程序中的数据，包括：UTF-8、UTF-16、UTF-32。UTF是“UCS Transformation Format”的缩写，可以翻译成Unicode字符集转换格式，即怎样将Unicode定义的数字转换成程序数据。例如，“汉字”对应的数字是0x6c49和0x5b57，而编码的程序数据是：

“汉字”的UTF-8编码需要6个字节。“汉字”的UTF-16编码需要两个WORD，大小是4个字节。“汉字”的UTF-32编码需要两个DWORD，大小是8个字节。4.2节会介绍将数字映射到UTF编码的规则。

字符编码的第四层是计算机看到的字符，即在文件或内存中的字节流。例如，“字”的UTF-32编码是0x5b57，如果用little endian表示，字节流是“57 5b 00 00”。如果用big endian表示，字节流是“00 00 5b 57”。

字符编码的第三层规定了一个字符由哪些编码单位按什么顺序表示。字符编码的第四层在第三层的基础上又考虑了编码单位内部的字节序。UTF-8的编码单位是字节，不受字节序的影响。UTF-16、UTF-32根据字节序的不同，又衍生出UTF-16LE、UTF-16BE、UTF-32LE、UTF-32BE四种编码方案。LE和BE分别是Little Endian和Big

通过四层模型，我们又把字符编码中发生的这些事情梳理了一遍。其实大多数代码页都不需要完整的四层模型，例如GB18030以字节为编码单位，直接规定了字节序列和字符的映射关系，跳过了第二层，也不需要第四层。

Unicode是国际组织制定的可以容纳世界上所有文字和符号的字符编码方案。Unicode用数字0-0x10FFFF来映射这些字符，最多可以容纳1114112个字符，或者说有1114112个码位。码位就是可以分配给字符的数字。UTF-8、UTF-16、UTF-32都是将数字转换到程序数据的编码方案。

先看一些数字：每个平面有2^16=65536个码位。Unicode计划使用了17个平面，一共有17*2个码位。其实，现在已定义的码位只有238605个，分布在平面0、平面1、平面2、平面14、平面15、平面16。其中平面15和平面16上只是定义了两个各占65534个码位的专用区（Private Use Area），分别是0xF0000-0xFFFFD和0xx10FFFD。所谓专用区，就是保留给大家放自定义字符的区域，可以简写为PUA。

平面0也有一个专用区：0xE000-0xF8FF，有6400个码位。平面0的0xD800-0xDFFF，共2048个码位，是一个被称作代理区（Surrogate）的特殊区域。它的用途将在4.2节介绍。

34*2-089。余下的99089个已定义码位分布在平面0、平面1、平面2和平面14上，它们对应着Unicode目前定义的99089个字符，其中包括71226个汉字。平面0、平面1、平面2和平面14上分别定义了52080、3419、43253和337个字符。平面2的43253个字符都是汉字。平面0上定义了27973个汉字。

在更深入地了解Unicode字符前，我们先了解一下UCD。

UCD中的文本文件大都是适合于程序分析的Unicode相关数据。其中的html文件解释了数据库的组织，数据的格式和含义。UCD中最庞大的文件无疑就是描述汉字属性的文件Unihan.txt。在UCD 5.0,0中，Unihan.txt文件大小有28,221K字节。Unihan.txt中包含了很多有参考价值的索引，例如汉字部首、笔划、拼音、使用频度、四角号码排序等。这些索引都是基于一些比较权威的辞典，但大多数索引只能检索部分汉字。

我介绍UCD的目的主要是为了使用其中的两个概念：Block和Script。

Block是Unicode字符的一个属性。属于同一个Block的字符有着相近的用途。Block表中的开始码位、结束码位只是用来划分出一块区域，在开始码位和结束码位之间可能还有很多未定义的码位。使用UniToy，大家可以按照Block浏览Unicode字符，既可以按列表显示：

也可以显示每个字符的详细信息：

Unicode中每个字符都有一个Script属性，这个属性表明字符所属的文字系统。Unicode目前支持以下Script：

其中，有两个Script值有着特殊的含义：

• Common：Script属性为Common的字符可能在多个文字系统中使用，不是某个文字系统特有的。例如：空格、数字等。

左侧Script窗口中，第一层节点是按英文字母顺序排列的Script属性。第二层节点是包含该Script文字的行（row），点击后显示该行内属于这个Script的字符。这样，就可以集中查看属于同一文字系统的字符。

前面提过，在Unicode已定义的99089个字符中，有71226个字符是汉字。它们的分布如下：

UCD的Unihan.txt中的部首偏旁索引（kRSUnicode）可以检索全部71226个汉字。kRSUnicode的部首是按照康熙字典定义的，共214个部首。简体字按照简体部首对应的繁体部首检索。UniToy整理了康熙字典部首对应的简体部首，提供了按照部首检索汉字的功能：

在字符编码的四个层次中，第一层的范围和第二层的编码在4.1节已经详细讨论过了。本节讨论第三层的UTF编码和第四层的字节序，主要谈谈第三层的UTF编码，即怎样将Unicode定义的编码转换成程序数据。

UTF-8的特点是对不同范围的字符使用不同长度的编码。对于0x00-0x7F之间的字符，UTF-8编码与ASCII编码完全相同。UTF-8编码的最大长度是4个字节。从上表可以看出，4字节模板有21个x，即可以容纳21位二进制数字。Unicode的最大码位0x10FFFF也只有21位。

UniToy有个“输出编码”功能，可以输出当前选择的文本编码。因为UniToy内部采用UTF-16编码，所以输出的编码就是文本的UTF-16编码。例如：如果我们输出“汉”字的UTF-16编码，可以看到0x6C49，这与“汉”字的Unicode编码是一致的。如果我们输出“”字的UTF-16编码，可以看到0xD843,

UTF-16编码以16位无符号整数为单位。我们把Unicode编码记作U。编码规则如下：

• 如果U<0x10000，U的UTF-16编码就是U对应的16位无符号整数（为书写简便，下文将16位无符号整数记作WORD）。

为什么U'可以被写成20个二进制位？Unicode的最大码位是0x10ffff，减去0x10000后，U'的最大值是0xfffff，所以肯定可以用20个二进制位表示。例如：“”字的Unicode编码是0x20C30，减去0x10000后，得到0x10C30，写成二进制是：00 。用前10位依次替代模板中的y，用后10位依次替代模板中的x，就得到：110110 110111，即0xD843

高位替代就是指这个范围的码位是两个WORD的UTF-16编码的第一个WORD。低位替代就是指这个范围的码位是两个WORD的UTF-16编码的第二个WORD。那么，高位专用替代是什么意思？我们来解答这个问题，顺便看看怎么由UTF-16编码推导Unicode编码。

按照编码的相反步骤，取出高低WORD的后10位，并拼在一起，得到

UTF-32编码以32位无符号整数为单位。Unicode的UTF-32编码就是其对应的32位无符号整数。

那么，怎么判断字节流的字节序呢？

Unicode标准建议用BOM（Byte Order Mark）来区分字节序，即在传输字节流前，先传输被作为BOM的字符"零宽无中断空格"。这个字符的编码是FEFF，而反过来的FFFE（UTF-16）和FFFE0000（UTF-32）在Unicode中都是未定义的码位，不应该出现在实际传输中。下表是各种UTF编码的BOM：

程序员的工作就是将复杂的世界简单地表达出来，希望这篇文章也能做到这一点。本文的初稿完成于2007年2月14日。我会在我的个人主页维护这篇文章的最新版本。