汉字编码问题
下面是搜集的多篇关于汉字编码问题文章的合集，相信你的问题一定包含在其中，如果没有请留言，一起把这方面的内容补充全。一、汉字编码的种类
汉字编码中现在主要用到的有三类，包括GBK，GB2312和Big5。
1、 GB2312又称国标码，由国家标准总局发布，1981年5月1日实施，通行于大陆。新加坡等地也使用此编码。它是一个简化字的编码规范，当然也包括其他 的符号、字母、日文假名等，共7445个图形字符，其中汉字占6763个。我们平时说6768个汉字，实际上里边有5个编码为空白，所以总共有6763个 汉字。
GB2312规定”对任意一个图形字符都采用两个字节表示，每个字节均采用七位编码表示”，习惯上称第一个字节为”高字节”，第二个字节 为”低字节”。GB2312中汉字的编码范围为，第一字节0xB0-0xF7(对应十进制为176-247)，第二个字节0xA0-0xFE（对应十进制 为160-254）。
GB2312将代码表分为94个区，对应第一字节（0xa1-0xfe）；每个区94个位（0xa1-0xfe），对应第二 字节，两个字节的值分别为区号值和位号值加32（2OH），因此也称为区位码。01-09区为符号、数字区，16-87区为汉字区（0xb0- 0xf7），10-15区、88-94区是有待进一步标准化的空白区。
2、Big5又称大五码，主要为香港与台湾使用，即是一个繁体字编码。每个 汉字由两个字节构成，第一个字节的范围从0X81－0XFE（即129-255），共126种。第二个字节的范围不连续，分别为0X40－0X7E（即 64-126），0XA1－0XFE（即161-254），共157种。

3、GBK是GB2312的扩展，是向上兼容的，因此 GB2312 中的汉字的编码与GBK中汉字的相同。另外，GBK中还包含繁体字的编码，它与Big5编码之间的关系我还没有弄明白，好像是不一致的。GBK中每个汉字 仍然包含两个字节，第一个字节的范围是0×81-0xFE（即129-254），第二个字节的范围是0×40-0xFE（即64-254）。GBK中有码 位23940个，包含汉字21003个。

表1 汉字编码范围

名称    |       第一字节          |           第二字节
——–|————————-|————————
GB2312  |   0xB0-0xF7(176-247)    |    0xA0-0xFE（160-254）
——–|————————-|————————-
GBK0    |  x81-0xFE（129-254）    |   0×40-0xFE（64-254）
——–|————————-|————————-
Big5    |   0×81-0xFE（129-255）  |   0×40-0x7E（64-126），
|                         |    0xA1－0xFE（161-254）
——–|————————-|————————
二、对汉字进行hash
为了处理汉字的方便，在查找汉字的时候，我们通常会用到hash的方法，那怎么来确定一个汉字位置呢？这就和每种编码的排列有关了，这里主要给出一种hash函数的策略。
对于GB2312编码，设输入的汉字为GBword，我们可以采用公式(C1-176)*94 + (C2-161)确定GBindex。其中，C1表示第一字节，C2表示第二字节。具体如下：
GBindex = ((unsigned char)GBword.at(0)-176)*94 + (unsigned char)GBword.at(1) – 161;
之所以用unsigned char类型，是因为char是一个字节，如果用unsigend int，因为int是4个字节的，所以会造成扩展，导致错误。
对于GBK编码，设输入的汉字为GBKword，则可以采用公式   index=(ch1-0×81)*190+(ch2-0×40)-(ch2/128)，其中ch1是第一字节，ch2是第二字节。
具体的，
GBKindex = ((unsigned char)GBKword[0]-129)*190 +
((unsigned char)GBKword[1]-64) – (unsigned char)GBKword[1]/128;

三、怎样判断一个汉字的是什么编码
直接根据汉字的编码范围判断，对于GB2312和GBK可用下面两个程序实现。
1、判断是否是GB2312
bool isGBCode(const string& strIn)
{
unsigned char ch1;
unsigned char ch2;

if (strIn.size() >= 2)
{
ch1 = (unsigned char)strIn.at(0);
ch2 = (unsigned char)strIn.at(1);
if (ch1>=176 && ch1<=247 &&ch2>=160 && ch2<=254)
return true;
else return false;
}
else return false;
}
2、判断是否是GBK编码
bool isGBKCode(const string& strIn)
{
unsigned char ch1;
unsigned char ch2;

if (strIn.size() >= 2)
{
ch1 = (unsigned char)strIn.at(0);
ch2 = (unsigned char)strIn.at(1);
if (ch1>=129 && ch1<=254 &&ch2>=64 && ch2<=254)
return true;
else return false;
}
else return false;
}

3、对于Big5
它 的范围为：高字节从0xA0到0xFE，低字节从0×40到0x7E，和0xA1到0xFE两部分。判断一个汉字是否是BIG5编码，可以如上对字符的编 码范围判断即可。如何定位呢？那么也想象所有编码排列为一个二维坐标，纵坐标是高字节，横坐标是低字节。这样一行上的汉字个数：(0x7E-0×40+ 1)+(0xFE-0xA1+1)＝157。那么定位算法分两块，为:

if 0×40<=ch2<=0x7E: #is big5 char
index=((ch1-0xA1)*157+(ch2-0×40))*2
elif 0xA1<=ch2<=0xFE: #is big5 char
index=((ch1-0xA1)*157+(ch2-0xA1+63))*2

对于第二块，计算偏移量时因为有两块数值，所以在计算后面一段值时，不要忘了前面还有一段值。0x7E-0×40+1=63。

四、如果判断一个字符是西文字符还是中文字符
大家知道西文字符主要是指ASCII码，它用一个字节表示。且这个字符转换成数字之后，该数字是大于0的，而汉字是两个字节的，第一个字节的转化为数字之后应该是小于0的，因此可以根据每个字节转化为数字之后是否小于0，判断它是否是汉字。
例如，设输入字为strin，则，
If (strin.at(0) < 0)
cout << “是汉字” << endl;
else cout << “不是汉字” << endl;
五、下载GBK编码表（见附件）
下载GB2312编码表见下面的回帖

——————————————————————————–
另一些与编码相关的文章：
1、GB码和BIG5码的互换技术
————————————————————————-
中文与英文用ASCII码一个字节表示不同，它使用两个字节来表示。事实上，在文本文件中保存的就是每个汉字对应的两个字节编码，而显示问题由中文操作系统自动解决。
汉字编码并不统一，我们使用的是GB码，而台湾地区使用的是BIG5码。BIG5码文件中保存的是汉字相应的BIG5编码，GB码文件中保存的是汉字相应的GB编码。所以转换工作的关键是有一个记录每个BIG5编码对应GB编码的码表文件。
GB码编码规则是这样的：每个汉字由两个字节构成，第一个字节的范围从0XA1－0XFE，共96种。第二个字节的范围分别为0XA1－0XFE，共96种。利用这两个字节共可定义出 96 * 96＝8836种汉字。实际共有6763个汉字。
BIG5码编码规则是这样的：每个汉字由两个字节构成，第一个字节的范围从0X81－0XFE，共126种。第二个字节的范围分别为0X40－0X7E， 0XA1－0XFE，共157种。也就是说，利用这两个字节共可定义出 126 * 157＝19782种汉字。这些汉字的一部分是我们常用到的，如一、丁，这些字我们称为常用字，其BIG5码的范围为0XA440－0XC671，共 5401个。较不常用的字，如滥、调，我们称为次常用字，范围为 0XC940－0XF9FE，共7652个，剩下的便是一些特殊字符。
制作码表文件的原理是这样的：首先将所有的GB编码写入一个文件，然后，使用具有GB码到BIG5码转换功能的软件，如UCDOS下的CONVERT.EXE，将文件转换为BIG5码文件，即得到码表文件。
下面的程序可将全部国标码写入文件gb.txt(以下全部程序用foxpro书写，可很容易的转换成其他语言)
fp = fopen(“gb.txt”,2)
for i=161 to 247
for j=161 to 254
=fwrite(fp,chr(i)+chr(j))
next
=fwrite(fp,chr(13)+chr(10))
next
=fwrite(fp,chr(26))
=fclose(fp)

文件的组织形式：行对应编码的第一字节，列对应编码的第二字节。使用时请注意编码的偏移量，如汉字”啊”GB编码0xb1a1第一字节0xb1(177) 第二字节0xa1(161)所以他应该在文件的第(177-161=16)行第((161-161)*2=0)列。
运行CONVERT.EXE将gb.txt转换成BIG5码的文件，这样就可得到按GB码组织的BIG5码表文件big5.txt。反之亦可得到按BIG5码组织的GB码表文件。

转换的思路是这样的：(用foxpro书写)
首先将码表文件装入数组
fp = fopen(“big5.txt”)
i = 0
do while feof(fp)
i = i+1
dime dict
dict = fgets(fp)
enddo
=fclose(fp)
其次将待转换的文本装入变量
create cursor temp (mm m)
append blank
append memo mm from textfilename
text = mm
然后扫描文本，替换所有的GB编码
temp = “”
i = 1
do while i < len(text)
ch = substr(text,i,1)
if isascii(ch)   && 若是ASCII码
temp = temp+ch
i = i+1
else
ch1 = substr(text,i+1,1)
big5 = substr(dict[asc(ch)-161+1],(asc(ch1)-161)*2+1,2)
temp = temp+big5
i = i+2
endif
enddo
最后将在temp中得到转换后的文本

需要注意的是，在foxpro中数组指针是以1开始，substr函数的起始位>=1。

———————————————————————————
一、GB2312-80介绍
GB2312码是中华人民共和国国家汉字信息交换用编码，全称《信息交换用汉字编码字符集–基本集》，由国家标准总局发布，1981年5月1日实施，通行于大陆。新加坡等地也使用此编码。
GB2312 收录简化汉字及符号、字母、日文假名等共7445个图形字符，其中汉字占6763个。GB2312规定”对任意一个图形字符都采用两个字节表示，每个字节 均采用七位编码表示”，习惯上称第一个字节为”高字节”，第二个字节为”低字节”。GB2312-80包含了大部分常用的一、二级汉字，和9区的符号。该 字符集是几乎所有的中文系统和国际化的软件都支持的中文字符集，这也是最基本的中文字符集。其编码范围是高位0xa1－0xfe，低位也是0xa1- 0xfe；汉字从0xb0a1开始，结束于0xf7fe。
GB2312将代码表分为94个区，对应第一字节（0xa1-0xfe）；每个区94个 位（0xa1-0xfe），对应第二字节，两个字节的值分别为区号值和位号值加32（2OH），因此也称为区位码。01-09区为符号、数字区，16- 87区为汉字区（0xb0-0xf7），10-15区、88-94区是有待进一步标准化的空白区。GB2312将收录的汉字分成两级：第一级是常用汉字计 3755个，置于16-55区，按汉语拼音字母/笔形顺序排列；第二级汉字是次常用汉字计3008个，置于56-87区，按部首/笔画顺序排列。故而 GB2312最多能表示6763个汉字。
GB2312的编码范围为2121H-777EH，与ASCII有重叠，通行方法是将GB码两个字节的最高位置1以示区别。
二、GB2312-80的扩展

GBK是GB2312-80的扩展，是向上兼容的。它包含了20902个汉字，其编码范围是0×8140-0xfefe，剔除高位0×80的字位。其所有字符都可以一对一映射到Unicode2.0。
GB18030-2000(GBK2K)在GBK的基础上进一步扩展了汉字，增加了藏、蒙等少数民族的字形。GBK2K从根本上解决了字位不够，字形不足的问题。它有几个特点：
它并没有确定所有的字形，只是规定了编码范围，留待以后扩充。
编码是变长的，其二字节部分与GBK兼容；四字节部分是扩充的字形、字位，其编码范围是首字节0×81-0xfe、二字节0×30-0×39、三字节0×81-0xfe、四字节0×30-0×39。
它的推广是分阶段的，首先要求实现的是能够完全映射到Unicode3.0标准的所有字形。
它是国家标准，是强制性的。
现在还没有任何一个操作系统或软件实现了GBK2K的支持，这是现阶段和将来汉化的工作内容。

三、Unicode编码

国 际标准组织于1984年4月成立ISO/IECJTC1/SC2/WG2工作组，针对各国文字、符号进行统一性编码。1991年美国跨国公司成立 UnicodeConsortium，并于1991年10月与WG2达成协议，采用同一编码字集。目前Unicode是采用16位编码体系，其字符集内容 与ISO10646的BMP（BasicMultilingualPlane）相同。Unicode于1992年6月通过DIS （DrafInternationalStandard），目前版本V2.0于1996公布，内容包含符号6811个，汉字20902个，韩文拼音 11172个，造字区6400个，保留20249个，共计65534个。
随着国际互联网的迅速发展，要求进行数据交换的需求越来越大，不同的编码体系越来越成为信息交换的障碍，而且多种语言共存的文档不断增多，单靠代码页已很难解决这些问题，于是UNICODE应运而生。
UNICODE 有双重含义，首先UNICODE是对国际标准ISO/IEC10646编码的一种称谓（ISO/IEC10646是一个国际标准，亦称大字符集，它是 ISO于1993年颁布的一项重要国际标准，其宗旨是全球所有文种统一编码），另外它又是由美国的HP、Microsoft、IBM、Apple等大企业 组成的联盟集团的名称，成立该集团的宗旨就是要推进多文种的统一编码。
UNICODE同现在流行的代码页最显著不同点在于：UNICODE是两字 节的全编码，对于ASCII字符它也使用两字节表示。代码页是通过高字节的取值范围来确定是ASCII字符，还是汉字的高字节。如果发生数据损坏，某处内 容破坏，则会引起其后汉字的混乱。UNICODE则一律使用两个字节表示一个字符，最明显的好处是它简化了汉字的处理过程。
UNICODE使用平面来描述编码空间，每个平面分为256行，256列，相对于两字节编码的高低两个字节。
UNICODE的第一个平面，称为BasicMultilingualPlane（基本多文种平面），简称BMP，由于BMP仅用两个字节表示，所以倍受青睐。

一些相关的网页：
GBK代码表： http://www.haiyan.com/steelk/navigator/ref/gbk/gbindex2.htm
GBK 汉字内码扩展规范：http://www.haizhuedu.net/no-weiyischool/hzdwzx/xxzy/xxzy-kj/xxzy-xx/xkjs2-8/HAIZI/GBK.htm
下载GB2312编码表，见附件
——————————————————————————–
谈谈Unicode编码，简要解释UCS、UTF、BMP、BOM等名词
这是一篇程序员写给程序员的趣味读物。所谓趣味是指可以比较轻松地了解一些原来不清楚的概念，增进知识，类似于打RPG游戏的升级。整理这篇文章的动机是两个问题：
问题一：
使用Windows记事本的”另存为”，可以在GBK、Unicode、Unicode big endian和UTF-8这几种编码方式间相互转换。同样是txt文件，Windows是怎样识别编码方式的呢？

我 很早前就发现Unicode、Unicode big endian和UTF-8编码的txt文件的开头会多出几个字节，分别是FF、FE（Unicode）,FE、FF（Unicode big endian）,EF、BB、BF（UTF-8）。但这些标记是基于什么标准呢？

问题二：
最近在网上看到一个 ConvertUTF.c，实现了UTF-32、UTF-16和UTF-8这三种编码方式的相互转换。对于Unicode(UCS2)、GBK、UTF- 8这些编码方式，我原来就了解。但这个程序让我有些糊涂，想不起来UTF-16和UCS2有什么关系。
查了查相关资料，总算将这些问题弄清楚了，顺带也了解了一些Unicode的细节。写成一篇文章，送给有过类似疑问的朋友。本文在写作时尽量做到通俗易懂，但要求读者知道什么是字节，什么是十六进制。

0、big endian和little endian
big endian和little endian是CPU处理多字节数的不同方式。例如”汉”字的Unicode编码是6C49。那么写到文件里时，究竟是将6C写在前面，还是将49写在前 面？如果将6C写在前面，就是big endian。如果将49写在前面，就是little endian。

“endian”这个词出自《格列佛游记》。小人国的内战就源于吃鸡蛋时是究竟从大头(Big-Endian)敲开还是从小头(Little-Endian)敲开，由此曾发生过六次叛乱，一个皇帝送了命，另一个丢了王位。

我们一般将endian翻译成”字节序”，将big endian和little endian称作”大尾”和”小尾”。

1、字符编码、内码，顺带介绍汉字编码
字符必须编码后才能被计算机处理。计算机使用的缺省编码方式就是计算机的内码。早期的计算机使用7位的ASCII编码，为了处理汉字，程序员设计了用于简体中文的GB2312和用于繁体中文的big5。

GB2312(1980年)一共收录了7445个字符，包括6763个汉字和682个其它符号。汉字区的内码范围高字节从B0-F7，低字节从A1-FE，占用的码位是72*94=6768。其中有5个空位是D7FA-D7FE。

GB2312支持的汉字太少。1995年的汉字扩展规范GBK1.0收录了21886个符号，它分为汉字区和图形符号区。汉字区包括21003个字符。

从ASCII、 GB2312到GBK，这些编码方法是向下兼容的，即同一个字符在这些方案中总是有相同的编码，后面的标准支持更多的字符。在这些编码中，英文和中文可以 统一地处理。区分中文编码的方法是高字节的最高位不为0。按照程序员的称呼，GB2312、GBK都属于双字节字符集 (DBCS)。

2000 年的GB18030是取代GBK1.0的正式国家标准。该标准收录了27484个汉字，同时还收录了藏文、蒙文、维吾尔文等主要的少数民族文字。从汉字字 汇上说，GB18030在GB13000.1的20902个汉字的基础上增加了CJK扩展A的6582个汉字（Unicode码0×3400- 0x4db5），一共收录了27484个汉字。

CJK就是中日韩的意思。Unicode为了节省码位，将中日韩三国语言中的文字统一编码。GB13000.1就是ISO/IEC 10646-1的中文版，相当于Unicode 1.1。

GB18030 的编码采用单字节、双字节和4字节方案。其中单字节、双字节和GBK是完全兼容的。4字节编码的码位就是收录了CJK扩展A的6582个汉字。例如： UCS的0×3400在GB18030中的编码应该是8139EF30，UCS的0×3401在GB18030中的编码应该是8139EF31。

微软提供了GB18030的升级包，但这个升级包只是提供了一套支持CJK扩展A的6582个汉字的新字体：新宋体-18030，并不改变内码。Windows 的内码仍然是GBK。

这里还有一些细节：

GB2312的原文还是区位码，从区位码到内码，需要在高字节和低字节上分别加上A0。

对 于任何字符编码，编码单元的顺序是由编码方案指定的，与endian无关。例如GBK的编码单元是字节，用两个字节表示一个汉字。这两个字节的顺序是固定 的，不受CPU字节序的影响。UTF-16的编码单元是word（双字节），word之间的顺序是编码方案指定的，word内部的字节排列才会受到 endian的影响。后面还会介绍UTF-16。

GB2312的两个字节的最高位都是1。但符合这个条件的码位只有 128*128=16384个。所以GBK和GB18030的低字节最高位都可能不是1。不过这不影响DBCS字符流的解析：在读取DBCS字符流时，只 要遇到高位为1的字节，就可以将下两个字节作为一个双字节编码，而不用管低字节的高位是什么。

2、Unicode、UCS和UTF
前面提到从ASCII、GB2312、GBK到GB18030的编码方法是向下兼容的。而Unicode只与ASCII兼容（更准确地说，是与ISO-8859-1兼容），与GB码不兼容。例如”汉”字的Unicode编码是6C49，而GB码是BABA。

Unicode 也是一种字符编码方法，不过它是由国际组织设计，可以容纳全世界所有语言文字的编码方案。Unicode的学名是”Universal Multiple-Octet Coded Character Set”，简称为UCS。UCS可以看作是”Unicode Character Set”的缩写。

根据维基百科全书(http://zh.wikipedia.org/wiki/)的记载：历史上存在两个试图独立设计Unicode的组织，即国际标准化组织（ISO）和一个软件制造商的协会（unicode.org）。ISO开发了ISO 10646项目，Unicode协会开发了Unicode项目。

在1991年前后，双方都认识到世界不需要两个不兼容的字符集。于是它们开始合并双方的工作成果，并为创立一个单一编码表而协同工作。从Unicode2.0开始，Unicode项目采用了与ISO 10646-1相同的字库和字码。

目前两个项目仍都存在，并独立地公布各自的标准。Unicode协会现在的最新版本是2005年的Unicode 4.1.0。ISO的最新标准是ISO 10646-3:2003。

UCS 只是规定如何编码，并没有规定如何传输、保存这个编码。例如”汉”字的UCS编码是6C49，我可以用4个ascii数字来传输、保存这个编码；也可以用 utf-8编码:3个连续的字节E6 B1 89来表示它。关键在于通信双方都要认可。UTF-8、UTF-7、UTF-16都是被广泛接受的方案。UTF-8的一个特别的好处是它与ISO- 8859-1完全兼容。UTF是”UCS Transformation format”的缩写。

IETF的RFC2781和 RFC3629以RFC的一贯风格，清晰、明快又不失严谨地描述了UTF-16和UTF-8的编码方法。我总是记不得IETF是Internet Engineering Task Force的缩写。但IETF负责维护的RFC是Internet上一切规范的基础。

2.1、内码和code page
目前Windows的内核已经支持Unicode字符集，这样在内核上可以支持全世界所有的语言文字。但是由于现有的大量程序和文档都采用了某种特定语言的编码，例如GBK，Windows不可能不支持现有的编码，而全部改用Unicode。

Windows使用代码页(code page)来适应各个国家和地区。code page可以被理解为前面提到的内码。GBK对应的code page是CP936。

微软也为GB18030定义了code page：CP54936。但是由于GB18030有一部分4字节编码，而Windows的代码页只支持单字节和双字节编码，所以这个code page是无法真正使用的。

3、UCS-2、UCS-4、BMP
UCS有两种格式：UCS-2和UCS-4。顾名思义，UCS-2就是用两个字节编码，UCS-4就是用4个字节（实际上只用了31位，最高位必须为0）编码。下面让我们做一些简单的数学游戏：

UCS-2有2^16=65536个码位，UCS-4有2^31=2147483648个码位。

UCS -4根据最高位为0的最高字节分成2^7=128个group。每个group再根据次高字节分为256个plane。每个plane根据第3个字节分为 256行 (rows)，每行包含256个cells。当然同一行的cells只是最后一个字节不同，其余都相同。

group 0的plane 0被称作Basic Multilingual Plane, 即BMP。或者说UCS-4中，高两个字节为0的码位被称作BMP。

将UCS-4的BMP去掉前面的两个零字节就得到了UCS-2。在UCS-2的两个字节前加上两个零字节，就得到了UCS-4的BMP。而目前的UCS-4规范中还没有任何字符被分配在BMP之外。

4、UTF编码

UTF-8就是以8位为单元对UCS进行编码。从UCS-2到UTF-8的编码方式如下：

UCS-2编码(16进制) UTF-8 字节流(二进制)
0000 – 007F 0xxxxxxx
0080 – 07FF 110xxxxx 10xxxxxx
0800 – FFFF 1110xxxx 10xxxxxx 10xxxxxx

例 如”汉”字的Unicode编码是6C49。6C49在0800-FFFF之间，所以肯定要用3字节模板了：1110xxxx 10xxxxxx 10xxxxxx。将6C49写成二进制是：0110 110001 001001， 用这个比特流依次代替模板中的x，得到：11100110 10110001 10001001，即E6 B1 89。

读者可以用记事本测试一下我们的编码是否正确。需要注意，UltraEdit在打开utf-8编码的文本文件时会自动转换为UTF-16，可能产生混淆。你可以在设置中关掉这个选项。更好的工具是Hex Workshop。

UTF -16以16位为单元对UCS进行编码。对于小于0×10000的UCS码，UTF-16编码就等于UCS码对应的16位无符号整数。对于不小于 0×10000的UCS码，定义了一个算法。不过由于实际使用的UCS2，或者UCS4的BMP必然小于0×10000，所以就目前而言，可以认为UTF -16和UCS-2基本相同。但UCS-2只是一个编码方案，UTF-16却要用于实际的传输，所以就不得不考虑字节序的问题。

5、UTF的字节序和BOM
UTF -8以字节为编码单元，没有字节序的问题。UTF-16以两个字节为编码单元，在解释一个UTF-16文本前，首先要弄清楚每个编码单元的字节序。例如 “奎”的Unicode编码是594E，”乙”的Unicode编码是4E59。如果我们收到UTF-16字节流”594E”，那么这是”奎”还是 “乙”？

Unicode规范中推荐的标记字节顺序的方法是BOM。BOM不是”Bill Of Material”的BOM表，而是Byte Order Mark。BOM是一个有点小聪明的想法：

在UCS 编码中有一个叫做”ZERO WIDTH NO-BREAK SPACE”的字符，它的编码是FEFF。而FFFE在UCS中是不存在的字符，所以不应该出现在实际传输中。UCS规范建议我们在传输字节流前，先传输 字符”ZERO WIDTH NO-BREAK SPACE”。

这样如果接收者收到FEFF，就表明这个字节流是Big-Endian的；如果收到FFFE，就表明这个字节流是Little-Endian的。因此字符”ZERO WIDTH NO-BREAK SPACE”又被称作BOM。

UTF -8不需要BOM来表明字节顺序，但可以用BOM来表明编码方式。字符”ZERO WIDTH NO-BREAK SPACE”的UTF-8编码是EF BB BF（读者可以用我们前面介绍的编码方法验证一下）。所以如果接收者收到以EF BB BF开头的字节流，就知道这是UTF-8编码了。

Windows就是使用BOM来标记文本文件的编码方式的。

6、进一步的参考资料
本文主要参考的资料是 “Short overview of ISO-IEC 10646 and Unicode” (http://www.nada.kth.se/i18n/ucs/unicode-iso10646-oview.html)。

我还找了两篇看上去不错的资料，不过因为我开始的疑问都找到了答案，所以就没有看：

“Understanding Unicode A general introduction to the Unicode Standard” (http://scripts.sil.org/cms/scripts/page.php?site_id=nrsi&item_id=IWS-Chapter04a)
“Character set encoding basics Understanding character set encodings and legacy encodings” (http://scripts.sil.org/cms/scripts/page.php?site_id=nrsi&item_id=IWS-Chapter03)
我写过UTF-8、UCS-2、GBK相互转换的软件包，包括使用Windows API和不使用Windows API的版本。以后有时间的话，我会整理一下放到我的个人主页上(http://fmddlmyy.home4u.china.com)。

我是想清楚所有问题后才开始写这篇文章的，原以为一会儿就能写好。没想到考虑措辞和查证细节花费了很长时间，竟然从下午1:30写到9:00。希望有读者能从中受益。

附录1 再说说区位码、GB2312、内码和代码页
有的朋友对文章中这句话还有疑问：
“GB2312的原文还是区位码，从区位码到内码，需要在高字节和低字节上分别加上A0。”

我再详细解释一下：

“GB2312 的原文”是指国家1980年的一个标准《中华人民共和国国家标准 信息交换用汉字编码字符集 基本集 GB 2312-80》。这个标准用两个数来编码汉字和中文符号。第一个数称为”区”，第二个数称为”位”。所以也称为区位码。1-9区是中文符号，16-55 区是一级汉字，56-87区是二级汉字。现在Windows也还有区位输入法，例如输入1601得到”啊”。（这个区位输入法可以自动识别16进制的 GB2312和10进制的区位码，也就是说输入B0A1同样会得到”啊”。）

内码是指操作系统内部的字符编码。早期操作系统的内码是与语言相关的。现在的Windows在系统内部支持Unicode，然后用代码页适应各种语言，”内码”的概念就比较模糊了。微软一般将缺省代码页指定的编码说成是内码。

内码这个词汇，并没有什么官方的定义，代码页也只是微软这个公司的叫法。作为程序员，我们只要知道它们是什么东西，没有必要过多地考证这些名词。

所谓代码页(code page)就是针对一种语言文字的字符编码。例如GBK的code page是CP936，BIG5的code page是CP950，GB2312的code page是CP20936。

Windows中有缺省代码页的概念，即缺省用什么编码来解释字符。例如Windows的记事本打开了一个文本文件，里面的内容是字节流：BA、BA、D7、D6。Windows应该去怎么解释它呢？

是 按照Unicode编码解释、还是按照GBK解释、还是按照BIG5解释，还是按照ISO8859-1去解释？如果按GBK去解释，就会得到”汉字”两个 字。按照其它编码解释，可能找不到对应的字符，也可能找到错误的字符。所谓”错误”是指与文本作者的本意不符，这时就产生了乱码。

答案是Windows按照当前的缺省代码页去解释文本文件里的字节流。缺省代码页可以通过控制面板的区域选项设置。记事本的另存为中有一项ANSI，其实就是按照缺省代码页的编码方法保存。

Windows的内码是Unicode，它在技术上可以同时支持多个代码页。只要文件能说明自己使用什么编码，用户又安装了对应的代码页，Windows就能正确显示，例如在HTML文件中就可以指定charset。

有 的HTML文件作者，特别是英文作者，认为世界上所有人都使用英文，在文件中不指定charset。如果他使用了0×80-0xff之间的字符，中文 Windows又按照缺省的GBK去解释，就会出现乱码。这时只要在这个html文件中加上指定charset的语句，例如：
<meta http-equiv=”Content-Type” content=”text/html; charset=ISO8859-1″>
如果原作者使用的代码页和ISO8859-1兼容，就不会出现乱码了。

再 说区位码，啊的区位码是1601，写成16进制是0×10,0×01。这和计算机广泛使用的ASCII编码冲突。为了兼容00-7f的ASCII编码，我 们在区位码的高、低字节上分别加上A0。这样”啊”的编码就成为B0A1。我们将加过两个A0的编码也称为GB2312编码，虽然GB2312的原文根本 没提到这一点。

——————————————————————————–
一、几个基本概念
1、bit 与  byte
bite 是二进制的即0和1，译作比特。
Byte是指八个bit，代表一个Ansi或Ascii 代码，即一个英文字母，译作字节。由于汉字使用了16位（比特）代码，所以称为双字节。
其换算关系很简单，一byte等于八bit。
2，ANSI码，ANSI是（American National Standard Institude）的简写。ANCII是American Standard Code for Information Interchange的简写。
ANSI是以标准的八位来显示一个字符的，可以代表256字。基本上包括了拉丁语系中所需要的全部字符。起初美国人认为7位（比特）就足够了，因为2的 7次方等于128，而英文字母只有26个，大小写加一起52个，再加上十个数字，几个标点和数学运算符号，也够了。所以就制定了ANCII七位的代码系 统，这七位的代码系统的128位与ANSI的256中的前128完全一致，加之现在的计算机系统都能自动分别，所以，这两个概念也就不太分别了。
二、GB 2312 汉字编码字符集
GB2312 码是中华人民共和国国家标准汉字信息交换用编码，全称《信息交换用汉字编码字符集•基本集》，标准号为GB 2312―80（GB是”国标”二字的汉语拼音缩写），由国家标准总局发布，1981年5月1 日实施。习惯上称国标码、GB码，或区位码。它是一个简化字汉字的编码，通行于中国大陆地区。新加坡等地也使用这一编码。
GB 2312―80收录简化汉字及一般符号、序号、数字、拉丁字母、日文假名、希腊字母、俄文字母、汉语拼音符号、汉语注音字母，共7445个图形字符。其中 汉字以外的图形字符682个，汉字6763个。由于6763比那GB 2312-80要好记得多，尤其是在GBK也流行的时代，人们总是习惯用6763来代指那通行（同时也让我们痛苦了）若干年的字符系统。
GB 2312-80规定，”对任意一个图形字符都采用两个字节（Byte）表示。每个字节均采用GB 1988-80及GB 2311-80中的七位编码表示。两个字节中前面的字节为第一字节，后面的字节为第二字节。”习惯上称第一字节为”高字节”（Upper），第二字节为 “低字节”（low）。
GB 2312-80将代码分为94个区（Section），对应第一字节，每个区94个位（Position），对应第二字节。两个字节的值，分别为区号值和位号值各加32（20H）。我们通常所说的区位便由此而来。
GB 2312-80规定，01~09区（原规定为1~9区，为表示区位码方便起见，现改称01~09区）为符号、数字区，16~87区为汉字区。而10~15 区、88~94区是有待于”进一步标准化”的”空白位置”区域。便第10区推荐与第3区的94个图形字符（即GB1988-80中的94个图形字符）相 同，字形宽度为其宽度的一半。）
GB 2312-80把收录的汉字分成两级。第一级汉字是常用汉字，计3755个，置于16~55区，按汉语拼音字母/笔形顺序排列；第二级汉字是次常用汉字， 计3008个，置于56~87区，按部首/笔区顺序排列。字音以普通话审音委员会发表的《普通话导读词三次审音总表初稿》（1963年出版）为准，字形以 中华人民共和国文化部、中国文字改革委员会公布的《印刷通用汉字字形表》（1964年出版）为准。
例：汉字”啊”，第一字节为0110000，第二字节为0100001，即16区、01位，用16。
这 些字的来源我不知道是根据什么，但就我处理文献的情况看，有些是对很常用的字，如用于人名的”�”字，一是明代著名戏曲理论家”沈�”，一是南唐中主（同 时又是文学家）”李�”，出现频率比较高，但却没有收在6763之中，而象”芏”"塄”"蓥”等近千字几乎用不上的字却占据着极紧张的资源。
以后的GBK更有这种情况。
三、GB/T12345 汉字编码字符集
GB/T12345和GB2312一样，是中华人民共和国国家标准汉字信息交换用编码，全称《信息交换用汉字编码字符集辅助集》，标准号为GB/T12345-90，中华人民共和国国家技术监督局1990年6月13日发布，1990年12月1日实施。
GB/T12345-90是一个关于繁体汉字的编码标准。所谓”辅助集”，•是与”基本集”（GB2312-80）相对应而言。即：GB/T12345 是”与GB2312相对应的图形字符集。原则上，本字符集是将GB2312中的简化字用相应的繁体字替换而成。因此，这些替代的繁体字具有与被替代的简化 字相同的编码；未曾简化的汉字以及非汉字图形字符，仍是GB2312中的汉字及图形字符，并具有与之相同编码。”
关于繁体字替换简化字的原 则，GB/T12345注明：”本标准原则是按照《简化字总表》中所列繁体字与简化字的对应关系进行替换。”《简化字总表》由中国文字改革委员会1964 年5月发表，后经国家语言文字工作委员会作个别修订，国务院1986年6月4日批准重新发表。
除了以上的根本差异外，GB/T12345与GB2312的区别还有以下几点：1，增补了个别图形字符，共收录7583个图形字符：汉字以外的图形字符716个，汉字6866个（其中一级汉字3755个，二级汉字3008个，增补汉字103个。）
a，”根据排版需要，增补了竖排标点符号29个，这些字符增补于6区57位至85位。”
b，”根据GB5007.1（《信息交换用汉字24×24点阵字模集》），增加了6个汉语拼音用图形字符，这些字符增补于8区27位至32位。”
c，”GB2312中，由于60年代汉字简化被精简的字有103个，这些被精简的字根据繁体字处理系统的需要增补于88~89区。”所谓精简，即废除某 个繁体字，而用另一个字代替，如废除”�”字，而以”云”字代替。由此形成一个简化字对应两个或两个以上繁体字的现象。
2，GB/T12345规定的在七位环境中指明图形字符集的转义序列不同，同时规定了在八位环境中的转义序列。
GB/T12345没有指明其字符集字形依据，便它使用的繁体汉字，与《简化字总表》中所使用的字形一致。其绝大多数汉字，使用了”新字形”。例如， “产”的繁体字，它使用了新字形”�”，而不自旧字形”�”。因此，一些旧字形与新字形的差异，被视为字形的差异（异体字），而不是繁体与简体的差异。 如：收录”奂”"换”"唤”，而不用”�”"�”"�”，即因为”�”是旧字形，而非繁体字。但是其中极个别字又使用了旧字形，如”为”"伪”的繁体字， 使用了旧字形”�”"�”，而上用新字形”�”"�”。关于新旧字形，可参见中国社会科学院语言研究所编纂的《现代汉语词典》（商务印书馆1978年第一 版）、《新华字典》（商务印书馆1979年修订版）所附的《新旧字形对照表》，以及辞海编辑委员会编纂的《辞海》（上海辞书出版社1979年出版）所附的 《新旧字形对照举例》。
关于被精简的汉字：
1，88~89区所列的103个汉字，GB/T12345称为”60年代汉字简化时被精简 的字。”，这一表达不完全准确。例如：，”丰”与”�”，汉字简化时精简了”�”字，以”丰”字替代，而GB/T12345将被精简的”�”字，作为 “丰”的繁体，置于23~65，而将”丰”字置于88~19。类似的情况占其103字的三分之一左右。
2，所谓103个”被精简的汉字”，只 是被精简的”繁体字”，而未包括被精简（废除）的”异体字”。例如，”�”和”�”，作为”升”的异体字，被停止使用，GB/T12345亦未收录。相关 的法定文件为中华人民共和国文化部、中国文字改革委员会1955年6月发布的《第一批异体字整理表》，该表列出异体字810组，1865字，并规定废除异 体字1055个。一些异体字，习惯上也被看作是简化字，所以，《简化字总表》特地从《第一批异体字整理表》中选出39个异体字，列为附录。
3，按照汉字简化原则，在容易引起歧义时不简化。例如”余”和”�”，《简化字总表》对”�”字的脚注说；”在余和�意义可能混淆时，仍用�，如文言句 “�年无多”。同时，有些汉字只简化其字义的某一个或几个义项，如徵，在象徵等义项上被简化为征，而在音乐调值的义项上（即宫商角徵羽的徵，读作zhi [止]），并不简化。因此在GB2312中，保留了个别繁体（或异体）字，也就是说，同时收录了一个字的简体和繁体（或异体），这包括”干乾、后後、伙 夥、么麽、于於、余�、折摺、征徵”等。作为与GB2312对应的繁体编码，GB/T12345在这些字上处理较混乱。例如：GB/T12345将”伙” 置于27-79，”夥”置于66-23，与GB2312��相同，即，以”伙”��”伙”，以”夥”��”夥”。另一�情�是，GB/T12345� “後”置于26-83，对应GB2312的”后”，将”後”置于65-65，对应GB2312的”後”；将”徵”置于53-87，对应GB2312的 “征”，将”征”置于65-71，对应GB2312的”徵”，显然不当。
注：
1，以上代码表，除06、08区增补符号用GIF图形编制外，其他均使用GBK代码编制，只有在你的电脑能完全正确GBK汉字时，才能保证看到的上表与GB/T12345标准印刷件（中国标准出版社1991年10月版）相同的字形。
2，尽管满足查看GBK汉字的条件，仍有两个汉字的显示，与GB/T12345标准印刷件有所差异。两个字的代码为47-22、80-89。第一字的印 刷件字形，未列入有关简化字的法定文件，但习惯上被视为”隙”的繁体，而GBK编码未收录此字，无法显示，故以”隙”替代。第二字的印刷件字形，系对应简 体”�”，按照《简化字总表》第二表《可作简化偏旁的简化字和简化偏旁》，”�”简化为”夹”，所以，”瘗”对应的繁体字，应该是”瘗”，同时，印刷件上 的此字不见于字书，因此它可能是排版时错误，故上表使用了”瘗”字。
3，01~15区的符号和空白位置，除增补者以外，与GB2312的符号、编码位置完全相同。
——————————————————————————–
四、BIG-5字符集
BIG-5码是通行于台湾、香港地区的一个繁体字编码方案，俗称”大五码”。它并不是一个法定的编码方案，存在着一些瑕疵，业界的评价也不高，但它广泛地被应用于电脑业，尤其是在国际互联网中，从而成为一种事实上的行业标准。
关于BIG-5码的背景，一直未见详细记载，简单介绍如下：
1983年10月，台湾国家科学委员会、教育部汉字推行委员会、中央标准局、行政院主计处电子资料处理中心共同制定了《通用汉字标准交换码》 （chinese  Ideographic  standard  code for  information  interchange ，简称CISCII码），经试用修订，1986年8月4日由台湾中央标准局公布为法定标准，标准编号为CNS 11643。这一标准于1992年5月21日重新修订公布，更名为《中文标准交换码》（chinese standard  interchange  code）.1995mm 1 月4日，台湾中央标准局又公布了CNS 11643-1《中文标准交换码使用方法》。
BIG-５码是1984年台湾信息工业促进会根据《通用汉字标准交换码》制订的编码方案。至于为何称为”BIG-5″。
BIG-5码是一个双字节编码方案，其第一字节的值在16进制的AO~FE之间，第二字节在40~7E和A1~FE之间。因此，其第一字节的最高位是1，第二字节的最高位则可能是1，也可能是0。
BIG-5码的图形符号及汉字，基本与CNS 11643标准的第一、第二字面（Plane）一致，它收录13461个符号和汉字，包括：
1，符号408个，编码位置为A140~A3FE（实际止于A3BF，末尾有空白位置。）
2，汉字13053个，分为常用字和次常用字两部分，各部分中的汉字按笔划/部首排列。其中：
a，常用字5401个，编码位置为A440~C67E。包括台湾教育部颁布的《常用汉字标准字体表》中的全部汉字4808个，台湾国中国小教科书常用字587个，异体字6个。
B，次常用字7652个，编码位置为C940~F9FE（实际止于F9D5，末尾有空白位置）。包括台湾教育部《次常用汉字标准字体表》的全部汉字6341个，《罕用汉字标准字体表》中使用频率较高的字1311个。
其余的A040~A0FE、C6A1`FEFE为空白区域。一些空白位置，经常被用于用户造字区，而且多存放香港常用字和粤语方言字。
现在流行的BIG-5码字库，在F9D6~F9DC位置大都有7个常用字，据说为倚天系统所增。若计此7字，则全数为13060个汉字，13468个汉 字和符号。此外，一些BIG-5码字库，如Windows繁体中文版的True Type细明体（华康科技提供，2.0版），在F9DD~F9FE位置还有33个制表符和1个”■”符号。
五，BIG5+码
1，编订BIG5+码之缘起
台湾行政院协助解决众多使用BIG5码政府单位于进行公文电子传递时寓到自造字无法转换CNS问题，而于数次会商后决议成立专案委托中文电脑基金会办理[BIG5码字集扩编计划]，86年7月扩编完成。
2，编码原则
BIG5 +码系以CNS为蓝本，共增编标准字集4760个字符与推荐字集3250个字符；其标准字集即纳编CNS第3字面字集内之4145个，第4个字面字集内之 219个字，均为一般文书常用之中文字，如推广应用于研究发新版中文软体，则估计可解决80％的BIG5自造字转换CNS交换码问题。
（一），长度仍为双字节，即高字节之第一位元（MSB）=1。
（二），保留原有之标准字集字区及使用者加字区，使与原有系统具相容性。
（三），以国家标准（CNS11643）及国际标准（ISO10646）字集为字源范围，并依CNS之序编入。
（四）包含于ISO10646或CNS11643字集内且市面已广为使用之倚天自造字及符号，编入标准字集并保留原码位。
（五），单独成字之部首不再重覆编码（如金、木、水、火、土）。
（六），有重复的字删除其后者，错字则依CNS修正之。
3，字码架构
（一），总码位：由原有之19782个扩大为23940个（高字节为81-FE，低位元组为40-7E、80-FE）。
（二）编码区间
a，第一标准字集：此区即原BIG-5码标准字集但删除22个重字，编码范围为A140-F9FE（高字节为A1-F9，低字节为40-7E、A1- FE）。共有13973个字符，包括常用汉字5401个（A440-C67E），次常用汉字7693个（C940-F9D5）及符号471个（A140- A3FE）、字符408个（C6A1-C8FE）。
b，第二标准字集：此区即扩编部分，编码范围为8180-FEA0（高字节为81-F9，低字节为80-A0）。共收编罕用汉字4158个。
c，CMEX推荐字集：因BIG-5码系统之编码位置有限，未能编入第一及第二标准字集之较常用罕用及异体汉字、简体字与日韩汉字3454个，经中推会 （CMEX）建议集中收编于此区。编码范围为原造字区之8140-83FE、8E40-A0FE（高字节为81-83、8E-A0，低字节为40―7E、 A1-FE）。
d，造字区：仅使用第二标准字集时，仍保留5809个码位供使用者造字，可编码区间不变；但同时使用推荐字集时，因BIG5+ 码之推荐字集系使用原造字区之8140-83FE及8E40-A0FE，供造字之码位仅余2355个，可编码区间为FA40-FEFE（785个码位）、 8440-8DFE（1570个码位）。
e，使用者专用字集：为使各行业专用之字集亦能进行信息交换，向中推会申请登记ID后，将ID字形等依照 输规定传出供对方显示或列印。
使用者专用字集之编码区与CMEX推荐字集相同，亦使用到原造字区。
4，可用之工具
（一），24＊24点阵字形档。
（二），注音符号、仓颉码属性档。
（三），CNS11643、ISO10646码对照档。
（四），BIG5+〈――〉ISO10646转码程序。
（五），BIG5+〈――〉CNS11643转码程序。
（六）BIG-5码自造字转BIG-5码管理程序。
（七）BIG-5自造字转码程序。
5，使用方法
因BIG5+码在标准字集外尚提供推荐字集，各单位可依自己原有造字情况选择适当之使用方法：
（一）字集之使用1.以下情可使用全字集（即第一、第二标准字集及推荐字集，共21585个字符）
（1），全无自造字者。
（2），原来已有自造字，其编码区间未与推荐字集重叠者，（即FA40―FEFE及8440-8DFE以外）
（3），原来已有自造初开球编码区间虽与推荐字集重叠，但可全部转换为新码者。
（4），原来已有自造字，但经转换为新码后剩余自造字未超过2355个，且可以或原意改置于FA40-FEFE及8440-8DFE以外者。2.以下情况仅使用标准字集（即第一与二标准字集，共13461个字符）：
（1），有自造字，但转码后剩余自造字仍超过2355个者。
（2），原有自造字耸部或部分落于FA40-8440-8DFE两个造字区（推荐字集使用范围）内，不易或不愿转换为新码者。
（二）字形转输与交换规格之使用
BIG -5码虽已扩编，但其余未能纳入自造字及未来不断新增之自造字，依旧会产生交换及传送问题；为使这些自造字于网路传输及档案交换时，仍可作字形显示与列 印，特订定以下几项规格：1，文件档案交换传输规格，依SGML（ISO8879）格式及CNS（ISO9541）字形资讯交换规格，订定SGML文件档 案内字形应含之参数。2，中文周边装置字形下载规格：包括中文终端机、打印机及其他终端设备，系依CNS13479（ISO6429）规范订定字形下载之 规格。
（三）用户需准备之工作
BIG-5码编扩编后纳入之自造字，如不作转码，将来交换时一定会发生一字两码的问题，因此在BIG5+码 之新版中文系统软体推出前，用户必需先转换现在自造字之旧码，其程序如下：1，建立自造字之旧码与扩编后新码对照表：各单位之造字区管理者可利用第六项工 具[BIG5自造字转标准字对照表管理程式]比对造字区内自造字后建立单位内新/旧码对照表。2，清查需要转码之资料档：各单位或集中或各自处理，均必需 先清查所有用过原造字区字码之料档，以备进行转码。3，自造字旧码之转换：各项业务负责人或各使用者可利用第七项工具[BIG5自造字转标准字转换程式] 及所建立之单位内新/旧码对照表，将所有的[文字档（.txt。）原用之自编旧码转换为BIG5+新码。4，单位内造字区之重整；为避免转码后发生一字两 码之现象，各单位原有之造字区应作整理，删除已编入BIG5+码系统者，其余自造字则保留原编码或重新编码（重整造字区）。
6，应用现况
台湾厂商如：芙蓉坊、昌泰科枝、大同、倚天等公司已将BIG5+码应用于新产品中。

六、台湾制定的CNS11643
1，编订中文标准交换码之缘起
72年10月由台湾科学委员会、教育部、中央标准局及本中心合编[通用汉字标准交换码]后决议试用二年；试用期满，经检讨修正重编并向中央标准局申请订 为国家标准，75年8月4日获该局审定公布国家标准，编号[CNS11643]；81年51 21日再由该局因应实际需要修订扩编，并更名为[中文标准交换码（chinese standard interchange code）]。
2，CNS11643之适用范围
本标准适用于中文信息之处理。
3，编码之各项考虑
中文信息标准交换码是否能普遍地推广使用，使一般使用者共同乐意接受，端视其是否具有实用性，因此本码之编码原则研订时，曾先就标准码的结构、编码需求等作多方面的周密考虑。
（一），以教育部所公布的四个字体表之字集为范围。
（二），根据使用的频率及范围，整理后分别编排于各个字面，以适应各个层次之使用者。
（三），符合国际信息传输上所使用之CNS5205[信息处理及交换用七位码字符集]及CNS7654[信息处理-七位及八位码字符集-延码技术]标准通信定则。
（四）涵盖常用之外语字母及工商界与学校所使用之文字及符号。
4，字集编排原则
（一），中文标准交换码分为十六个字面，每个字面可陈列94列＊94行，即8836个字符。目前第一至第七字面列有字集，第八至第十一字面预留扩编之用；第十二至第十六字面则为使用者加字区，凡未收于本码系统之中文及符号，他用者可视需要自行编订于加字区使用。
总支持文字量达141376个。
（二）各字面字集排列大抵依使用频率为次序，每一字面以常用字为主，第二字面以次常用字为主，第三字面以部分罕用字及较常用异体字为主，第四字面以 ISODIS10646第二版之汉字、各单位/信息业用字及户政用字为主，第五字面以罕用字为主，第六、第七字面以异体字为主。其中第一第二字面字集先于 民国七十五年八月四日公布为国家标准。
5，字码编排原则
（一），文字之选择及字体悉依教育部[汉字标准字体表]为基准。说明：中 国文字的困扰主要有两方面，一是文字的数量太大，二是异体字繁多。实际上一般人常用的不过七千字左右，新字又不断的增加，造成中文资料处理上的困难；而教 育部的标准字体表之字集系经多年之搜集、考证、分析、选取，为较不偏颇，最具客观性之用字字集，应能符合一般使用者之需求。
（二），以2个字节（bytes）为中文码编码单位，并以十六进位制之文数字表示之。说明：[以2个字节为字码单位，于处理时可增加信息传输之速度]，符合一般资料处理作业之需要。采用十六进位制数字编码，系因应资料处理人员惯用之进位法，用以表示两字节最为简明。
（三）符合CNS5205及CNS7654之通信定则。说明：本编码为符合CNS5305及CNS7654通信定则之规定，所有控制码均予避开，即字码 中之00至20以及7F均予避开，则7BIT字码集共有94个编码位置，两个字节革命可编8836个中文字码，订为一字面。
（四），依字之使用频率而编排于各不同字面。说明：在做信息传输时，若欲传送出现在不同字面上的字，必须先送出转字面控制码。为提高传输效率，常会一起出现的字编在同一字面中，可减低字面转换的次数。
（五），使先笔画后部首的排列顺序来编订字码。说明：每一字面均按文字灭口笔画数为首序编订字码，使用者以笔画数即可查寻字码。
六、字集之说明
第一字面：本编码系统为减少字面转换次数，特编最常用之中文字及符号、字母、部首等于第一字面；所编字汇及码区分别说明如下：
1，符号区
符号区之编码位置规划于第一字面之2121至427E，有3102个编码位置，目前暂编符号684个，所余空位供尔后增添之用。
已编入之特殊符号及文字类别如下：
（1），间隔符号1个。
（2），标点符号28个。
（3）括号及制表符号89个。
（4），一般符号34个。
（5）、学术符号51个。
（6）、单位符号31个。
（7）数字符号42个，包括阿拉伯数字10个，罗马数字大小写共20个，中国数字12个。
（8）外文字母100个，包括大写英文字母，小字英文字母各26个，大写希腊字母、小写希腊字母各24个。
（9）汉字注音符号42个。

（10）数字序列符号20个。
（11）中国文字部首213个（夕，夕两部首同归于夕部首中，夕部首得于将来扩编时一并列入增订。）
（12）控制码符号33个。
2 中文字区
CNS第一字面之中文字区编码区间由4421至7D4B，所编字汇5401字，除包括教育部颁订之”常用汉字标准字体表”所列全部4808字外，并优收 编国中、国小教科书中常用字587字及异体字6字。第二字面：本字集所编字汇7650字，除教育部所颁”次常用汉字标准字体表”外，并筛选编入罕用字表中 使用频率较高之1320字。字码区间为2121至7244。第三字面：本字集即77年6月行政院主计处电子处理资料中心为搜集仍涵盖教育部罕用及异体字表 中之较常用字，所编订之使用者加字区第14字面字集第一部分，字数6148字；原码序不变，字码区间仍为2121至6246。第四字面：本字集所编字汇 7298字，除包括原第14字面第二部分171字外，并搜集户役政及其他使用单位，ISO10646第2版汉字集、信息业次常用字而成，字码区间为 2121至6E5C。第五字面：本字集所编字汇共8603个字，系未包含于前4个字面之教育部罕用字。字码区间为2121至7C51。第六字面：本字集所 编字汇共6388个字，为不包含于前5个字面且笔画在14画（含）以下之教育部异体字。字码区间为2121至647A。第七字面：本字集所编字汇6539 个字，为不包含前6个字面之教育部异体字，字码区间为2121为6655。使用者得视自己的需求参考本标准之字集、字序编订内码表。
七，CNS11643之使用
（一）字面之指定与转换依据CNS7654（78年7月15日版）第5。3。9节之规定，中文码可置于多字节符号字库（MULTIPLE BYTE GRAPHIC  REPERTOIRE）中，经由ESC2/4 2/9 F四个字节之逸出顺序码指定于G1字集，或经由ESC2/4 2/10 F 指定于G2字集，亦可经由ESC2/4 2/11 F指定于G3字集，其中F 可用3/0~3/15来指定相对之一至十六中文字面；至于英文之字集则可经由ESC2/8 F 指定于G0字面。在7个位元的环境下，对于各种字面的使用说明如下：1，利用SI使用G0字面，并为锁定方式。        2，利用SO使用G1字面，并为锁定方式。3，利用LS2使用G2字面，并为锁定方式。4，利用LS3使用G3字面，并为锁定方式。5，利用SS2使用 G2字面，并为非锁定方式。6，利用        SS3使用G3字面，并为非锁定方式。
为求使用方便，终端设备在开机时可将G0、G1、G2等三个字集分别设定为ASCII、第一字面及第二字面，将G3字集设定为其他较常用的字面。有关这些控制码的使用，请参考CNS7654        。
（二）使用者加字区之使用：
为适应各种不同性质之中文资料处理作业，CNS11643特别订定自第十二字面起为使用者加字区；尚未收编于本系统之中文字或符号。由使用者视需要先编于此区内使用；字面之指定与转换方法与前七个字面相同。
八，CNS11643之推广应用
本交换码系统依国家标准法之规定，系由经济部中央标准局负责检讨增修之，但该局为加强推广该标准之应用，特将此系统及中文字型档委托本中心代为办理推广 应用事宜；本中心为顾及标准字型档之完整性，以利此标准之推广，另再商得内政部及经济部工业局同意一并提供其他字型档。
CNS11643目前之应用情形如下：
（一）台湾之应用情形
1，公文电子交换之标准传递码，行政院”政府机关公文电子传递作业”决定，凡是经”交换中心”（交通部管资中心）之公文，一律须先转换为CNS后再传递。
2，EUC码援用CNS之字集及架构：UNIX系统上使用之EUC虽为4BYTE之内码，但却全部采用CNS之编码架构及字集；其2个低字节之HIGH均OFF后字码即与CNS完全相同，因此不需再以对照表方式转换；亦可视为CNS应用于内码之实例。
3，BIG5+码之字源：86年7月完成之”BIG5+”（即BIG-5码之扩编）系以CNS11643为蓝本，纳编CNS第3字面之4，145个、第4字面之219个一般文书常用之中文字。
（二）国外之应用情形
ISO10646及UNICODE汉字均收编CNS字集：ISO10646及UNICODE目前共收编20902个汉字，其中17011个字系来自 CNS（第1第2字面及第3字面3895个，第4字面56个），现又增编CNS的5881个字。因此，不便台湾标准得与国际标准相容，国内电脑业者在国际 市场之竞争力得以增强，将来ISO10646及UNICODE发展成熟后，使用者亦可得以顺利转换。
七，CCCII编码
CCCII编码是CHINESE CHARACTER CODE FOR INformATION INTERCHANGE 的缩写，是经台湾中研院中美会及国科会等单位支持，于1979年12月25日集合由台湾图书馆学者，文字学家及电脑专家组成”汉字整理小组”提出的汉字编 码，已广泛用于港台图书馆及与美国网上数字化图书信息中心OCLC系统。该编写系统提供了94面（PLANE）×行（ROW）×94列（CELL）= 830584字符空间；其中每六个面构成一个层（LAYER）提供6×94×94=53016编码空间，（最后一层只有四个面）。各层定义的汉字情况如 下：
第1层，符号和繁体汉字。
第2层，大陆的简体汉字。
第3-12层，汉字异体字。
第13层，日本汉字。
第14层，朝鲜汉字。
第15层，保留字。
第16层，杂项字（日本与朝鲜）
第一至十二层的编码的编码存在关联含义，就是说同样的码在这些不同的层表示同一个汉字的不同变形。如第一层表示繁体字，第二层表示大陆简体字（如果有的话），第三至十二层表示其他的异体字，例如以下这个字的三种变形，编码的第二三字节是相同的：
字形类型编码点，层字样
繁体字  OX224E411
简体字  OX284E412
异体字  OX2E4E413
第一层所定义的字符集如下：第1面/第2行56数学符号第1面/第3行ASCII第1面/第11行35中文标点符号第1面/第12-14行214康熙字 典偏旁部首第1面/第15行41中文数字，37拼音符号，4音调符号第1面/第16-67行4808备用字，字码213021-21637E第1面/第 68行-第3面/第64行17032备用字，字码216421-23607E20583罕用字，字码为236121-262543第3面/第65行含教育 部颁定之罕用字汇12924字，次常用字汇314字，第6面/第5行以及康�字典、中文大辞典、财税资料考核中心字汇、电信传输码字汇、五大专题码字汇， 与其他信息字汇7345字。
第二层收异体字共11517字，其中包含大陆简体字3625字，其它简体字7892字所有各层的第一行均为保留行，共收字53940个。
四交大资料-BBS95年1月中国文字资料库（CCDB）字型集的应用（1）中国文字资料库（CCDB）字型集的应用（2）中国文字资料库（CCDB） 字型集的应用（3）中国文字资料库（CCDB）属性档介绍。三，ANSIZ39.64-1989 THIS NATIONAL STANDARD IS DESIGNATED as ANSIZ39.64-1989 and named “EAST ASIAN CHARACTER CODE”（EACC），but was origianlly known as REACC (RLIN EAST ASIAN CHARACTER CODE), THAT IS BEFORE IT BECAME A NATIONAL STANDARD RLIN STANDS FOR “RESEARCH LIBRARIES INformATION NETWORK ” which was developed by the
B ，浏览器：IE4。01（或更高的版本）中文版，或NETSGAPE NAVIGATOR 3。X
2，其他语种的WINDOWSS 95（或更高的版本）+微软简体中文支持或外挂中文平台。一般情况下，使用外挂中文平台时，需要将当前环境设置成为GBK码，并关闭汉字自动识别的功能。而且，许多外挂中文平台不支持全部GBK汉字。
3，已知的常见错误。
A，IE4。0无法显示GBK/4 AB-AF、F9-FD以及FE 中 FE40-FE4F各位置的汉字。
B，在简体WINDOWS95环境下，NETSGAPE NAVIGATOR4。X 无法显示GBK/3中XXA0位置的汉字，A040-AOFE位置显示错误。
C，在繁体WINDOWS95环境下，NETSGAPE NAVIGATOR4。X不能正确显示GBK/3-GBK/5之间的字符。
GBK代表码（按分类顺序排列）
GBK/1：GB2312非汉字符号A1-A9
B0-B7B8-BF C0-C7C8-CF D0-D7
GBK/2：GB2312汉字
D8-DFE0-E7E8-EFF0-F7
81-8384-87 88-8B8C-8F 90-93
GBK/3：扩充汉字
94-9798-9B 9C-A0
AA-AFB0-B7B8-BFC0-C7C8-CF
GBK/4：扩充汉字
D0-D7D8-DFE0-E7E8-EFF0-F7
F8-FE
GBK/5：扩充非汉字
A8-A9
（1）AA-AF  （2）F8-FE
用户自定义区
（3）A1-A7

import java.io.File;
import java.io.Reader;
import java.io.FileInputStream;
import java.io.*;
import java.util.Date;
import java.util.HashSet;/**
* <p>Title: Java中文分词接口</p>
* <p>Description: 本组件以哈工大分词系统为基础，在其基础之上开发
* 本组件仅供学习和研究用途，任何商业用途将自行承担法律后果，与组件编写人无关。</p>
* <p>Copyright: Copyright (c) 2006</p>
* <p>Company: dalian univercity of techology</p>
* @author ：yezheng
* @version 1.0
*/

public class IRSplit {

private static IRSplit instance = null; //instance时类中一成员，所以可以访问其中被private修饰的变量或方法
private static StringBuffer stringb = new StringBuffer(102400);
private static StringBuffer longSentence = new StringBuffer(10240);

//私有构造方法
private IRSplit() {
System.out.println(“正在加载词典……”);
this.LoadSegRes();
System.out.println(“加载结束”);
}

//获得一个实例
public static IRSplit getInstance() {
if (instance == null) {
instance = new IRSplit();
}
return instance;
}

//本地方法
private native void LoadSegRes();

private native void ReleaseSegger();

private native String split(String sentence);

//对一句话分词
public String splitSentence(String sentence) {
if (sentence.length() < 1 || sentence == null)
return “”;
else
return split(sentence);
}

public String splitLongSentence(String sentence) {
if (sentence.length() < 1 || sentence == null)
return “”;
else
{
this.longSentence.setLength(0);
int start = 0 ; int  end = 0;
for (int i = 0; i < sentence.length(); i++)
{
char c = sentence.charAt(i);
switch (Character.getType(c))
{
case 24:
end++;
//System.out.println(sentence.substring(start, end));
this.longSentence.append(split(sentence.substring(start, end)));
start = end;
break;
default:
end++;
break;
}
}
if(start < end)
{
longSentence.append(split(sentence.substring(start, end)));
}
return longSentence.toString();
}
}

public void ReleaseSeggers() {
instance = null;
ReleaseSegger();
}

//对一个文件分词
public void splitFile(File file, File outfile) {
try {
FileInputStream fis = new FileInputStream(file);
BufferedReader br = new BufferedReader(new InputStreamReader(fis));
this.stringb.setLength(0);
String ts;
while ( (ts = br.readLine()) != null) {
if (ts.length() != 0) {
stringb.append(splitLongSentence(ts) + ‘r’ + ‘n’); //进行分词
}
else {
stringb.append(‘r’);
stringb.append(‘n’);
}
}
br.close();
fis.close();

FileWriter writer = new FileWriter(outfile);
writer.write(stringb.toString());
writer.close();
}
catch (FileNotFoundException ex) {
System.out.println(file.toString() + “File not Found”);
}
catch (IOException ex1) {
System.out.println(file.toString() + “IO errors”);
}
}

public void splitFile(String source, String destination) {
File file = new File(source);
File outfile = new File(destination);
if (file.isFile()) {
splitFile(file, outfile);
}
}

public Reader splitFile(Reader reader) {
BufferedReader br = new BufferedReader(reader);
StringBuffer stringb = new StringBuffer();

try {
String ts;
while ( (ts = br.readLine()) != null) {
if (ts.length() != 0) {
stringb.append(splitSentence(ts) + ‘r’ + ‘n’); //进行分词
}
else {
stringb.append(‘r’);
stringb.append(‘n’);
}
}
reader = new StringReader(stringb.toString());
}
catch (IOException ex) {
}
return reader;
}

//处理一个目录下的所有文件
public void splitFiles(String sourceDir, String destinationDir) { //参数：源文件目录和目标文件目录
File directory = new File(sourceDir);
File dirdes = new File(destinationDir);
//FilenameFilter txtFilter = new myFilter(“txt”);
File files[] = directory.listFiles();
for (int i = 0; i < files.length; i++) {
if (files[i].isFile()) {
File outfile = new File(destinationDir + “/” +
files[i].getName());
//System.out.println(directory.getName() + “:” + dirdes.getName());
splitFile(files[i], outfile);
}
else if (files[i].isDirectory()) {

File tempdir = new File(destinationDir + “/” + files[i].getName());
if (!tempdir.exists() || !tempdir.isDirectory()) {
tempdir.mkdir();
}
splitFiles(sourceDir + “/” + files[i].getName(),
tempdir.getAbsolutePath());
}
}
}

static {
System.loadLibrary(“IRdll”);
}

public static void main(String[] args) {

IRSplit split = IRSplit.getInstance(); //其它类使用

long start = System.currentTimeMillis();
Date startdate = new Date();

//split.splitFiles(“clean”, “out”);
split.splitLongSentence(ss);

Date enddate = new Date();

System.out.println(startdate);
System.out.println(enddate);
System.out.println(enddate.getTime()- startdate.getTime());
}

}

终于清楚如何用读Lucene的索引 。本文要介绍一下如何利用IndexReader获取信息。为什么要读索引呢？因为我需要实现这些功能：
(1) 统计term在整个collection中的文档频度(document frequency, DF)；
(2) 统计term在整个collection中出现的词次(term frequency in whole collection)；
(3) 统计term在某个文档中出现的频度(term frequency, TF)；
(4) 列出term在某文档中出现的位置(position)；
(5) 整个collection中文档的个数；

那 么为什么要用到这些数据呢？这些数据是实现TR(Text Retrieval，文本检索)的必备的”原料”，而且是经过加工的。在检索之前，只有原始文本(raw data)；经过索引器(indexer)的处理之后，原始文本变成了一个一个的term(或者token)，然后被indexer纪录下来所在的位置、 出现的次数。有了这些数据，应用一些模型，就可以实现搜索引擎实现的功能――文本检索。

聪明的读 者您可能会说，这看起来似乎很好做，不过就是计数(count)么。不错，就是计数，或者说是统计。但是看似简单的过程，如果加上空间(内存容量)的限 制，就显得不那么简单了。假设如果每篇文档有100个term，每个term需要存储10字节信息，存1,000,000篇文档需要 10x100x10^6=10^9=2^30字节，也就是1GB。虽然现在1G内存不算什么，可是总不能把1GB的数据时时刻刻都放入内存吧。那么放入硬 盘好了，现在需要用数据的时候，再把1GB数据从硬盘搬到内存。OK，可以先去冲杯咖啡，回来在继续下面的操作。这是1,000,000的文档，如果更多 一点呢，现在没有任何辅助数据结构的方式，会导致很差的效率。

Lucene的索引会把数据分成 段，并且在需要的时候才读，不需要的时候就让数据乖乖地呆在硬盘上。Lucene本身是一个优秀的索引引擎，能够提供有效的索引和检索机制。文本的目的 是，介绍如用利用Lucene的API，如何从已经建好的索引的数据中读取需要的信息。至于Lucene如何使用，我会在后续的文章中逐渐介绍。

我们一步一步来看。这里建设已经有实现建好索引，存放在index目录下。好，要读索引，总得先生成一个读索引器(即Lucene中IndexReader的实例)。好，写下面的程序(程序为C#程序，本文使用DotLucene)。
IndexReader reader;
问 题出来了，IndexReader是一个abstract类，不能实例化。那好，换派生类试试看。找到IndexReader的两个孩子 ――SegmentReader和MultiReader。用哪个呢？无论是哪个都需要一大堆参数(我是颇费了周折才搞清楚它们的用途，后面再解释)，似 乎想用Lucene的索引数据不是那么容易啊。通过跟踪代码和查阅文档，我终于找到使用IndexReader的钥匙。原来IndexReader有一个 “工厂模式”的static interface――IndexReader.Open。定义如下：
#0001 public static IndexReader Open(System.String path)
#0002 public static IndexReader Open(System.IO.FileInfo path)
#0003 public static IndexReader Open(Directory directory)
#0004 private static IndexReader Open(Directory directory, bool closeDirectory)
其中有三个是public的接口，可供调用。打开一个索引，就是这么简单：
#0001 IndexReader reader = IndexReader.Open(index);

实际上，这个打开索引经历了这样的一个过程：
#0001 SegmentInfos infos = new SegmentInfos();
#0002 Directory directory = FSDirectory.GetDirectory(index, false);
#0003 infos.Read(directory);
#0004 bool closeDirectory = false;
#0005 if (infos.Count == 1)
#0006 {
#0007 // index is optimized
#0008 return new SegmentReader(infos, infos.Info(0), closeDirectory);
#0009 }
#0010 else
#0011 {
#0012 IndexReader[] readers = new IndexReader[infos.Count];
#0013 for (int i = 0; i < infos.Count; i++)
#0014 readers[i] = new SegmentReader(infos.Info(i));
#0015 return new MultiReader(directory, infos, closeDirectory, readers);
#0016 }

首 先要读入索引的段信息(segment information, #0001~#0003)，然后看一下有几个段：如果只有一个，那么可能是优化过的，直接读取这一个段就可以(#0008)；否则需要一次读入各个段 (#0013~#0014)，然后再拼成一个MultiReader(#0015)。打开索引文件的过程就是这样。

接下来我们要看看如何读取信息了。用下面这段代码来说明。
#0001 public static void PrintIndex(IndexReader reader)
#0002 {
#0003 //显示有多少个document
#0004 System.Console.WriteLine(reader + “tNumDocs = ” + reader.NumDocs());
#0005 for (int i = 0; i < reader.NumDocs(); i++)
#0006 {
#0007 System.Console.WriteLine(reader.Document(i));
#0008 }
#0009
#0010 //枚举term，获得<document, term freq, position* >信息
#0011 TermEnum termEnum = reader.Terms();
#0012 while (termEnum.Next())
#0013 {
#0014 System.Console.Write(termEnum.Term());
#0015 System.Console.WriteLine(“tDocFreq=” + termEnum.DocFreq());
#0016
#0017 TermPositions termPositions = reader.TermPositions(termEnum.Term());
#0018 int i = 0;
#0019 int j = 0;
#0020 while (termPositions.Next())
#0021 {
#0022 System.Console.WriteLine((i++) + “->” + ” DocNo:” + termPositions.Doc() + “, Freq:” + termPositions.Freq());
#0023 for (j = 0; j < termPositions.Freq(); j++)
#0024 System.Console.Write(“[" + termPositions.NextPosition() + "]“);
#0025 System.Console.WriteLine();
#0026 }
#0027
#0028 //直接获取 <term freq, document> 的信息
#0029 TermDocs termDocs = reader.TermDocs(termEnum.Term());
#0030 while (termDocs.Next())
#0031 {
#0032 System.Console.WriteLine((i++) + “->” + ” DocNo:” + termDocs.Doc() + “, Freq:” + termDocs.Freq());
#0033 }
#0034 }
#0035
#0036 // FieldInfos fieldInfos = reader.fieldInfos;
#0037 // FieldInfo pathFieldInfo = fieldInfos.FieldInfo(“path”);
#0038
#0039 //显示 term frequency vector
#0040 for (int i = 0; i < reader.NumDocs(); i++)
#0041 {
#0042 //对contents的token之后的term存于了TermFreqVector
#0043 TermFreqVector termFreqVector = reader.GetTermFreqVector(i, “contents”);
#0044
#0045 if (termFreqVector == null)
#0046 {
#0047 System.Console.WriteLine(“termFreqVector is null.”);
#0048 continue;
#0049 }
#0050
#0051 String fieldName = termFreqVector.GetField();
#0052 String[] terms = termFreqVector.GetTerms();
#0053 int[] frequences = termFreqVector.GetTermFrequencies();
#0054
#0055 System.Console.Write(“FieldName:” + fieldName);
#0056 for (int j = 0; j < terms.Length; j++)
#0057 {
#0058 System.Console.Write(“[" + terms[j] + “:” + frequences[j] + “]”);
#0059 }
#0060 System.Console.WriteLine();
#0061 }
#0062 System.Console.WriteLine();
#0063 }

#0004 计算document的个数
#0012~#0034 枚举collection中所有的term
其中#0017~#0026 枚举每个term在出现的document中的所有位置(第几个词，从1开始计数)；#0029~#0033 计算每个term出现在哪些文档和相应的出现频度(即DF和TF)。
#0036~#0037在reader是SegmentReader类型的情况下有效。
#0040~#0061可以快速的读取某篇文档中出现的term和相应的频度。但是这部分需要在建索引时，设置storeTermVector为true。比如
doc.Add(Field.Text(“contents”, reader, true));
其中的第三项即是。默认为false。

有了这些数据，就可以统计我需要的数据了。以后我会介绍如何建立索引，如何应用Lucene。

Accepted Papers

Hierarchical Classification for Automatic Image Annotation
Jianping Fan

Alternatives to Bpref
Tetsuya Sakai

Laplacian Optimal Design for Image Retrieval
Xiaofei He, Deng Cai

Federated Text Retrieval From Uncooperative Overlapped Collections
Milad Shokouhi, Justin Zobel

A New Approach for Evaluating Query Expansion: Query-document Term Mismatch
Tonya Custis, Khalid Al-Kofahi

Fast Generation of Result Snippets in Web Search
Andrew Turpin, Yohannes Tsegay, David Hawking, Hugh E. Williams

Updating Collection Representations For Federated Search
Milad Shokouhi, Mark Baillie, Leif Azzopardi

HITS hits TREC: Exploring IR evaluation results with network analysis
Stefano Mizzaro, Stephen Robertson

Latent Concept Expansion Using Markov Random Fields
Donald Metzler, Bruce Croft

Query Performance Prediction in Web Search Environments
Yun Zhou, Bruce Croft

Indexing Confusion Networks for Morph-based Spoken Document Retrieval
Ville Turunen, Mikko Kurimo

Reliable Information Retrieval Evaluation with Incomplete and Biased Judgements
Stefan Buettcher, Charles Clarke, Peter Yeung, Ian Soboroff

New Event Detection Based on Indexing-tree and Named Entity
Kuo ZHANG, JuanZi LI, Gang WU

A Time Machine for Text Search
Klaus Berberich, Srikanta Bedathur, Thomas Neumann, Gerhard Weikum

Compressed Permuterm Index
Paolo Ferragina, Rossano Venturini

Detecting, Categorizing and Clustering Entity Mentions in Chinese Text
Wenjie Li, Donglei Qian, Chunfa Yuan, Qin Lu

FRank: A Ranking Method with Fidelity Loss
Ming-Feng Tsai, Tie-Yan Liu, Tao Qin, Hsin-Hsi Chen, Wei-Ying Ma

A Regression Framework for Learning Ranking Functions Using Relative Relevance Judgments
Zhaohui Zheng, Hongyuan Zha, Keke Chen, Gordon Sun

History Repeats Itself: Re-Finding Queries in a Major Search Engine’s Logs
Jaime Teevan, Eytan Adar, Rosie Jones, Michael Potts

Random Walks on the Click Graph
Nick Craswell, Martin Szummer

Towards Automatic Extraction of Event and Place Semantics from Flickr Tags
Tye Rattenbury, Nathaniel Good, Mor Naaman

Clustering of Documents with Local and Global Regularization
Fei Wang, Changshui Zhang, Tao Li

An InterActive Algorithm For Asking And Incorporating Feature Feedback into Support Vector Machines
Hema Raghavan, James Allan

Efficient Document Retrieval in Main Memory
Trevor Strohman, Bruce Croft

A Boosting Algorithm for Information Retrieval
Jun Xu, Hang Li

How well does result relevance predict session satisfaction?
Scott Huffman, Michael Hochster

A Support Vector Method for Optimizing Average Precision
Yisong Yue, Thomas Finley, Filip Radlinski, Thorsten Joachims

Strategic System Comparisons via Targeted Relevance Judgments
Alistair Moffat, William Webber, Justin Zobel

Topic Segmentation with Shared Topic Detection and Alignment of Multiple Documents
Sun Bingjun, Prasenjit Mitra, Lee Giles, Hongyuan Zha, John Yen

HITS on the Web: How does it Compare?
Marc Najork, Hugo Zaragoza, Michael Taylor

Effective Missing Data Prediction for Collaborative Filtering
Hao Ma, Irwin King, Michael R. Lyu

Feature Selection for Ranking
Xiubo Geng, Tie-Yan Liu, Tao Qin

Interesting Nuggets and Their Impact on Definitional Question Answering
Kian-Wei Kor, Tat Seng Chua

Ranking with Multiple Hyperplanes
Tao Qin, Tie-Yan Liu, Wei Lai, Xu-Dong Zhang, De-Sheng Wang, Hang Li

Building Simulated Queries for Known-Item Topics: An Analysis using Six European Languages
Leif Azzopardi, Maarten de Rijke, Krisztian Balog

CollabSum: Exploiting Multiple Document Clustering for Collaborative Single Document Summarizations
Xiaojun Wan

The Influence of Caption Features on Clickthrough Patterns in Web Search
Charles Clarke, Eugene Agichtein, Susan Dumais, Ryen White

Personalized Query Expansion for the Web
Paul – Alexandru Chirita, Claudiu Firan, Wolfgang Nejdl

Principles of Hash-based Text Retrieval
Benno Stein

An Outranking Approach for Rank Aggregation in Information Retrieval
Mohamed Farah, Daniel Vanderpooten

Deconstructing Nuggets: The Stability and Reliability of Complex Question Answering Evaluation
Jimmy Lin, Pengyi Zhang

DiffusionRank: A Possible Penicillin for Web Spamming
Haixuan Yang, Irwin King, Michael R. Lyu

Investigating the Querying and Browsing Behavior of Advanced Search Engine Users
Ryen White, Dan Morris

Neighborhood Restrictions in Geographic IR
Steven Schockaert, Martine De Cock

A Probabilistic Graphical Model for Joint Answer Ranking in Question Answering
Jeongwoo Ko, Luo Si, Eric Nyberg

Towards Task-based PIM Evaluations
David Elsweiler, Ian Ruthven

Utility-based Information Distillation Over Temporally Sequenced Documents
Yiming Yang, Abhimanyu Lad, Ni Lao, Abhay Harpale, Bryan Kisiel, Monica Rogati, Jian Zhang, Jaime Carbonell, Peter Brusilovsky, Daqing He

A Semantic Approach to Contextual Advertising
Vanja Josifovski, Andrei Broder, Lance Riedel, Marcus Fontoura

Test Theory for Assessing IR Test Collections
David Bodoff, Pu Li

Vocabulary Independent Spoken Term Detection
Jonathan Mamou, Bhuvana Ramabhadran, Olivier Siohan

ESTER: Efficient Search on Text, Entities, and Relations
Holger Bast, Alexandru Chitea, Fabian Suchanek, Ingmar Weber

A Combined Component Approach for Finding Collection-Adapted Ranking Functions based on Genetic Prog
Humberto Almeida, Marcos Goncalves, Marco Cristo, Pavel Calado

Supporting Multiple Information Seeking Strategies in a Single System Framework
Xiaojun Yuan, Nicholas Belkin

Context Sensitive Stemming for Web Search
Fuchun Peng, Nawaaz Ahmed, Xin Li, Yumao Lu

Know your Neighbors: Web Spam Detection using the Web Topology
Carlos Castillo, Debora Donato, Aristides Gionis, Vanessa Murdock, Fabrizio Silvestri

Combining Content and Link for Classification using Matrix Factorization
Shenghuo Zhu, Kai Yu, Yun Chi, Yihong Gong

Evaluating sampling methods for uncooperative collections
Paul Thomas, David Hawking

An Exploration of Proximity Measures in Information Retrieval
Tao Tao, ChengXiang Zhai

Relaxed Online Support Vector Machines for Spam Filtering
D. Sculley, Gabriel Wachman (best student paper)

Robust Classification of Rare Queries Using Web Knowledge
Andrei Broder, Marcus Fontoura, Evgeniy Gabrilovich, Amruta Joshi, Vanja Josifovski, Tong Zhang

Multiple-signal duplicate detection for search evaluation
Scott Huffman, April Lehman, Alexei Stolboushkin, Howard Wong-Toi, Fan Yang, Hein Roehrig

Structured Retrieval for Question Answering
Matthew Bilotti, Paul Ogilvie, Jamie Callan, Eric Nyberg

Robust Evaluation of Information Retrieval Systems
Ben Carterette

On the Robustness of Relevance Measures with Incomplete Judgments
Tanuja Bompada, Chi-Chao Chang, John Chen, Ravi Kumar, Rajesh Shenoy

Cross-Lingual Query Suggestion Using Query Logs of Different Languages
Wei Gao, Cheng Niu, Jian-Yun Nie, Ming Zhou, Jian Hu, Kam-Fai Wong, Hsiao-Wuen Hon

Efficient Bayesian Hierarchical User Modeling for Recommendation Systems
Yi Zhang, Jonathan Koren

Studying the Use of Popular Destinations to Enhance Web Search Interaction
Ryen White, Mikhail Bilenko, Silviu Cucerzan (best paper)

Knowledge-intensive Conceptual Retrieval and Passage Extraction of Biomedical Literature
Wei Zhou, Clement Yu, Neil Smalheiser, Vetle Torvik, Jie Hong

The Impact of Caching on Search Engines
Ricardo Baeza-Yates, Aristides Gionis, Flavio Junqueira, Vanessa Murdock, Vassilis Plachouras, Fabrizio Silvestri

Heavy-Tailed Distributions and Multi-Keyword Queries
Arnd Konig, Surajit Chaudhuri, Liying Sui, Kenneth Church

Improving Text Classification for Oral History Archives with Temporal Domain Knowledge
James Olsson, Douglas Oard

Estimation and Use of Uncertainty in Pseudo-relevance Feedback
Kevyn Collins-Thompson, Jamie Callan

Term Feedback for Information Retrieval with Language Models
Bin Tan, Atulya Velivelli, Hui Fang, ChengXiang Zhai

Enhancing Relevance Scoring With Chronological Term Rank
Adam Troy, Guo-Qiang Zhang

Inverted Index Pruning with Correctness Guarantee
Alexandros Ntoulas, Junghoo-John Cho

A Study of Poisson Query Generation Model for Information Retrieval
Qiaozhu Mei, Hui Fang, ChengXiang Zhai

ARSA: A Sentiment-Aware Model for Predicting Sales Performance Using Blogs
Yang Liu, Jimmy Huang, Aijun An, Xiaohui Yu

A Music Search Engine Built upon Audio-based and Web-based Similarity Measures
Peter Knees, Tim Pohle, Markus Schedl, Gerhard Widmer

Learn from Web Search Logs to Organize Search Results
Xuanhui Wang, ChengXiang Zhai

Using Query Contexts in Information Retrieval
Jing Bai, Jian-Yun Nie, Hugue Bouchard, Guihong Cao

Measuring the Spatial Correlation of Retrieval Functions for Zero- Judgment Performance Prediction
Fernando Diaz

Towards Musical Query-by-Semantic-Description using the CAL500 Data Set
Douglas Turnbull, Luke Barrington, David Torres, Gert Lanckriet

Web Text Retrieval with a P2P Query-Driven Index
Gleb Skobeltsyn, Toan Luu, Ivana Podnar, Martin Rajman, Karl Aberer

Analyzing Feature Trajectories for Event Detection
Qi He, Kuiyu Chang, Ee-Peng Lim

Broad Expertise Retrieval in Sparse Data Environments
Krisztian Balog, Maarten de Rijke, Leif Azzopardi

英美人名有不少源自英美文学作品，其喻义在英美等国已是家喻户晓，即使没有读过该作品的人们，也会明白这些人名的喻义。其用法在写作与日常生活中也屡见不鲜，本文举例如下：

1．James Bond詹母斯·邦德；（喻）神通广大的人

源自英国著名悬念小说作家伊恩·弗莱明（Ian Fleming, 1908-1964）的长篇侦探小说。弗莱明以塑代号007的英国间谍詹母斯·邦德（James Bond）而蜚声全球，以邦德为主人公的长篇小说共13部，每一部都充满惊险、恐怖和国际间谍的阴谋。小说中的詹母斯·邦德机智英勇，武艺高超，神通广大，无所不能。任何大案、难案他都能一一破获。James Bond现喻指“神通广大的人”。如：

(1) During the war he was sent on dangerous secret missions abroad. Very exciting! He was a sort of James Bond.战争期间他被派往国外执行危险而秘密的任务。真令人兴奋！他就像是个詹姆斯·邦德。

(2)Most of the applicants were weeded out early, including one 13-year-old aspiring James Bond.多数申请人早已被筛掉，其中包括一位年仅13岁雄心勃勃的神童。

2．Jekyll and Hyde哲基尔和海德；（喻）有善恶双重人格者

源自英国著名冒险故事和散文作家斯蒂文森（Robert Louis Stevenson, 1850-1894）所著的道德寓意深刻的中篇小说《化身博士》（The Strange Case of Dr. Jekyll and Mr. Hyde）。哲基尔和海德（Jekyll and Hyde）为该小说中的主人公，服用自配药物可使自己在原来善良绅士Jekyll与凶残暴的Hyde之间往复蜕变。Jekyll and Hyde现喻指“有善恶双重人格者”。如：

（1）I’d never have expected him to behave like that; he’s a real Jekyll and Hyde.我从来没有想到他会那样，他确实有善恶双重人格。

（2）He’s a strange chap. Usually he’s very pleasant and reasonable, but there are times when he gets very bad-tempered and almost violent. He’s got a Jekyll and Hyed personality.他这个家伙很怪。平常他十分友善讲理，但有时脾气很坏甚至粗暴。他具有善恶双重人格的个性。

3．Man Friday星期五来的人；（喻）忠实的仆人；得力的助手

源自英国小说家笛福（Daniel Defoe, 1669-1731）所著的长篇小说《鲁滨逊漂流记》（The Adventures of Robinson Grusoe）。由于船在海上失事，该小说的主人公鲁滨逊一个人在荒岛上度过了20多个春秋。在一个星期五，他救了一个土人俘虏，并收留他为佣人，取名为“星期五”。此后，土人星期五成了鲁滨逊的忠实仆人和助手。Man Friday现喻指“忠仆”。如：

（1）He’s very practical. What he needs is someone to look after him and do everything for him. He needs a Man Friday.他很讲实用。他就是需要人照顾他，并且为他做一切。他需要一个忠实的仆人。

（2）I could never have started this business if my friend John had not been willing to act as my Man Friday. 如果没有我的朋友约翰心甘情愿地做我的忠实帮手，这个商店我是办不起来的。

4．Mrs Grundy格伦迪太太；（喻）苛求、挑剔之人

源自英国剧作家托马斯·莫顿（Thomas Morton, 1764-1838）所著的喜剧《加快耕耘》（Speed the Plough）。格伦迪太太（Mrs Grundy）是虚构的人物，在剧中从未出过场，但其邻居阿希斐尔德（Ash field）太太经常念叨，事事怕她挑剔，现喻指“拘泥世俗、事事挑剔他人的人”。如：

（1）What will Mrs Grundy say?人家会怎么说呢？

（2）He decided to carry on his plan in spite of what Mrs Grundy will say.他不管人家会说什么，他决意按自己的计划干。

5．Paul pry保罗·普赖；（喻）非常爱打听别人隐私的人

源自英国作家约翰·蒲尔（John Poole, 1786-1872）所作的同名喜剧《保罗·普赖》（Paul pry）。剧中主人公保罗·普赖（Paul pryk）没有职业，整日无所事事，游手好闲，好管闲事，尤其爱打听别人的隐私。英语中Pry—词常含贬义，意为“打听、探听（他人的私事）”。Paul Pry现喻指“非常爱打听别人隐私的人”。如：

（1）They don’t want any Paul Prys.他们不要任何“包打听”。

（2）Don’t say too much in the club about your affairs, there are one or two of the Paul Pry type here.在俱乐部里对自己的事别说得太多，因为这里有那么一、两个好干涉他人私事的保罗·普赖式的人物。

6．Peter Pan彼得·潘；（喻）不肯长大的男孩；天真而幼稚的成年人

源自英国剧作家和小说家巴里（James M. Barrie, 1860-1937）所著的同名剧《彼得·潘》（Peter Pan）。剧中主人公彼得·潘（Peter Pan）是一个跑人了人迹罕至的仙境而永不长大的少年，又称“一个永远长不大的孩子”，他是不能适应成人世界的人。Peter Pan现喻指“不肯长大的男孩”或“天真无邪的成人”。如：

（1）He still has very youthful enthusiasms, and he’s as slim and fit as he was 20 years ago. He’s a Peter Pan indeed.他仍然具有年轻人的热情，并且像20年前一样身材修长而结实。他真是个永远长不大的男孩。

（2）You’re married to a Peter Pan who absolutely will refuse to escape from the comfortable irresponsible stage of childhood.你和一个彼得·潘式的人物结了婚，他将坚决拒绝脱离无忧无虑、不承担责任的童年时代。

7．Pip Van Winkle瑞普·凡·温克尔；（喻）落后、守旧的人；嗜睡的人

源自美国作家华盛顿·欧文（Washington Lrving, 1783-1859）所著的同名小说《瑞普·凡·温克尔》（Rip Van Winkle）。主人公瑞普·凡·温克尔（Rip Van Winkle）。主人公瑞普·凡·温克尔（Rip Van Winkle）为避开性格凶焊的妻子藏身在卡茨基尔（Catskill）山中，一睡就是20年，醒来后却发现一切面目全非，妻子已故，住屋成为废墟。Rip Van Winkle现喻指“落后、守旧的人”或“嗜睡的人”。如：

（1）This is the opinion of some Rip van Winkle.这是一些不识时务者的意见。

（2）Come on, Rip Van Winkle, wake up! It’s nearly lunch-time.快点，瑞普·凡·温克尔，醒醒吧！几乎是吃午饭的时间了。

8．Robin Hood罗宾汉；（喻）急公好义者

源自英国中世纪的民间传说。罗宾汉（Robin Hood）盘踞森林，以抑强扶弱及清除贪污吏为宗旨。他对穷苦人和被压迫者及妇女能以礼相待，见义勇为，是个扶危救困、劫富济贫的绿林好汉。Robin Hook现喻指“急公好义者”。如：

（1）Well, yes, he was a criminal and he stole a lot of money, but he helped a lot of people with it. He was a bit of a Robin Hood.暖，是的，他是个罪犯，偷了很多钱。但是他用那些钱帮助了不少人。他多少像个罗宾汉。

（2）But don’t conclude from this that OPEC has become an international Robin Hood, robbing the wealthy in New York, Paris and Tokyo so that hungry nations may eat.但不要由此得出结论，认为石油输出国组织已变成国际罗宾汉，抢掳纽约、巴黎和东京的富者，好让饥饿的国家吃个饱。

9．Robinson Crusce鲁滨逊；（喻）离群索居的人

源自英国小说家笛福（Daniel Defoe, 1669-1731）所著的长篇小说《鲁滨逊漂流记》（The Adventures of Robinson Crusoe）。小说中的主人公鲁滨逊（Robinson Crusoe）厌恶平庸的生活，到海外去冒险闯荡而遇险

自然语言理解技术及其应用探讨随着社会的日益信息化，人们越来越强烈地希望用自然语言同计算机交流。自然语言理解是计算机科学中的一个引人入胜的、富有挑战性的课题。从计算机科学特别是从人工智能的观点看，自然语言理解的任务是建立一种计算机模型，这种计算机模型能够给出象人那样理解、分析并回答自然语言（即人们日常使用的各种通俗语言）的结果。 现在的计算机的智能还远远没有达到能够象人一样理解自然语言的水平，而且在可预见的将来也达不到这样的水平。因此，关于计算机对自然语言的理解一般是从实用的角度进行评判的。如果计算机实现了人机会话，或机器翻译，或自动文摘等语言信息处理功能，则认为计算机具备了自然语言理解的能力。 第一部分 了解自然语言理解技术 自然语言处理就是研究如何能让计算机理解并生成人们日常所使用的(如汉语、英语)语言，使得计算机懂得自然语言的含义，并对人给计算机提出的问题，通过对话的方式，用自然语言进行回答。目的在于建立起一种人与机器之间的密切而友好的关系，使之能进行高度的信息传递与认知活动。自然语言理解系统可以用作专家系统、知识工程、情报检索、办公室自动化的自然语言人机接口，有很大的实用价值。 自然语言处理研究在电子计算机问世之初就开始了，并于 50年代初开展了机器翻译试验。当时的研究方法还不能称作带有”智能”。到了60年代乔姆斯基的转换生成语法得到广泛的认可，生成语法的核心是短语结构规则，分析句子结构的过程就是利用规则自顶向下或自底向上的句法树生成过程。 由于认识到生成语法缺少表示语义知识的手段，在70年代随着认知科学的兴盛，研究者又相继提出了语义网络、CD理论、格框架等语义表示理论。这些语法和语义理论经过各自的发展，逐渐开始趋于相互结合。到80年代一批新的语法理论脱颖而出，具有代表性的有词汇功能语法(LFG)、功能合一语法(FUG)和广义短语结构语法(GPSG) 等。 这些基于规则的分析方法可以称之为自然语言处理中的”理性主义”。现有的手段虽然基本上掌握了单个句子的分析技术，但是还很难覆盖全面的语言现象，特别是对于整个段落或篇章的理解还无从下手。 与”理性主义”相对的是”经验主义”的研究思路，主要是指针对大规模语料库的研究。语料库是大量文本的集合。计算机出现后，语料可以被方便地存贮起来，利用计算机查找也很容易。随着电子出版物的出现，采集语料也不再成为困难。最早于60年代编制的Brown和LOB两个计算机语料库，分别具有100万词次的规模。进入90 年代可以轻易列举出的语料库有几十个之多，象DCI、ECI、ICAME、BNC、LDC、 CLR等，其规模最高达到109数量级。 对语料库的研究分成3个方面：工具软件的开发、语料库的标注、基于语料库的语言分析方法。采集到以后未经处理的生语料不能直接提供有关语言的各种知识，只有通过词法、句法、语义等多层次的加工才能使知识获取成为可能。加工的方式就是在语料中标注各种记号，标注的内容包括每个词的词性、语义项、短语结构、句型和句间关系等。随着标注程度的加深语料库逐渐熟化，成为一个分布的、统计意义上的知识源。利用这个知识源可以进行许多语言分析工作，如根据从已标注语料中总结出的频度规律可以给新文本逐词标注词性，划分句子成分等。 语料库提供的知识是用统计强度表示的，而不是确定性的，随着规模的扩大，旨在覆盖全面的语言现象。但是对于语言中基本的确定性的规则仍然用统计强度的大小去判断，这与人们的常识相违背。这种”经验主义”研究中的不足要靠”理性主义” 的方法来弥补。两类方法的融合也正是当前自然语言处理发展的趋势。 自然语言理解系统的发展阶段 自然语言理解系统的发展可以分为第一代系统和第二代系统两个阶段。第一代系统建立在对词类和词序分析的基础之上，分析中经常使用统计方法；第二代系统则开始引进语义甚至语用和语境的因素，几乎完全抛开了统计技术。 第一代自然语言理解系统又可分为四种类型： （1）特殊格式系统 早期的自然语言理解系统大多数是特殊格式系统，根据人机对话内容的特点，采用特殊的格式来进行人机对话。1963年，林德赛（R.Lindsay）在美国卡内基技术学院用IPL－V表处理语言设计了SAD－SAM系统，就采用了特殊格式来进行关于亲属关系方面的人机对话，系统内建立了一个关于亲属关系的数据库，可接收关于亲属关系方面的问题的英语句子提问，用英语作出回答。1968年，波布洛（D.Bobrow）在美国麻省理工学院设计了STUDENT系统，这个系统把高中代数应用题中的英语句子归纳为一些基本模式，由计算机来理解这些应用题中的英语句子，列出方程求解，并给出答案。六十年代初期，格林（B.Green）在美国林肯实验室建立了BASEBALL系统，也使用IPL－V表处理语言，系统的数据库中存贮了关于美国1959年联邦棒球赛得分记录的数据，可回答有关棒球赛的一些问题。该系统的句法分析能力较差，输入句子十分简单，没有连接词，也没有比较级形式的形容词和副词，主要靠一部机器词典来进行单词的识别，使用了14个词类范畴，所有的问题都采用一种特殊的规范表达式回答。 （2）以文本为基础的系统 某些研究者不满意在特殊格式系统中的种种格式限制，因为就一个专门领域来说，最方便的还是使用不受特殊格式结构限制的系统来进行人机对话，这就出现了以文本为基础的系统，1966年西蒙（R.F.Simmons）、布尔格（J.F. Burger）和龙格（R.E. Long）设计的PROTOSYNTHEX－I系统，就是以文本信息的存贮和检索方式工作的。 （3）有限逻辑系统 有限逻辑系统进一步改进了以文本为基础的系统。在这种系统中，自然语言的句子以某种更加形式化的记号来替代，这些记号自成一个有限逻辑系统，可以进行某些推理。1968年，拉菲尔（B.Raphael）在美国麻省理工学院用LI SP语言建立了SIR系统，针对英语提出了24个匹配模式，把输入的英语句子与这些模式相匹配，从而识别输入句子的结构，在从存贮知识的数据库到回答问题的过程中，可以处理人们对话中常用的一些概念，如集合的包含关系、空间关系等等，并可进行简单逻辑推理，机器并能在对话中进行学习，记住已学过的知识，从事一些初步的智能活动。1965年，斯莱格勒（J.R. Slagle）建立了DEDUCOM系统，可在情报检索中进行演绎推理。1966年，桑普逊（F.B.Thompson）建立了DEACON系统，通过英语来管理一个虚构的军用数据库，设计中使用了环结构和近似英语的概念来进行推理。1968年，凯罗格（C.Kellog）在IBM360/67计算机上，建立了CONVERSE系统，该系统能根据关于美国120个城市的1000个事实的文件来进行推理。 （4）一般演绎系统 一般演绎系统使用某些标准数学符号（如谓词演算符号）来表达信息。逻辑学家们在定理证明工作上取得的全部成就，就可以用来作为建立有效的演绎系统的根据，从而能够把任何一个问题用定理证明的方式表达出来，并实际地演绎出所需要的信息，用自然语言作出回答。一般演绎系统可以表达那些在有限逻辑系统中不容易表达出来的复杂信息，从而进一步提高了自然语言理解系统的能力。1968－1969年，格林和拉菲尔建立的的QA2,QA3系统，采用谓词演算的方式和格式化的数据（formated data）来进行演绎推理，解答问题，并用英语作出回答，这是一般演绎系统的典型代表。 1970年以来，出现了一定数量的第二代自然语言理解系统，这些系统绝大多数是程序演绎系统，大量地进行语义、语境以至语用的分析。其中比较有名的系统是LUNAR 系统、SHRDLU系统、MARGIE系统、SAM系统、PAM系统。 LUNAR系统是伍兹（W.Woods）于1972年设计的一个自然语言情报检索系统。这个系统采用形式提问语言（formal query language）来表示所提问的语义，从而对提问的句子作出语义解释，最后把形式提问语言执行于数据库，产生出对问题的回答。 SHRDLU系统是维诺格拉德（T.Winograd）于1972年在美国麻省理工学院建立了一个用自然语言指挥机器人动作的系统。该系统把句法分析、语义分析、逻辑推理结合起来，大大地增强了系统在语言分析方面的功能。该系统对话的对象是一个具有简单的 “手”和”眼”的玩具机器人，它可以操作放在桌子上的具有不同颜色、尺寸和形状的玩具积木，如立方体、棱锥体、盒子等，机器人能够根据操作人员的命令把这些积木捡起来，移动它们去搭成新的积木结构，在人机对话过程中，操作人员能获得他发给机器人的各种视觉反馈，实时地观察机器人理解语言、执行命令的情况。在电视屏幕上还可以显示出这个机器人的模拟形象以及它同一个真正的活人在电传机上自由地用英语对话的生动情景。 MARGIE系统是杉克（R.Schank）于1975年在美国斯袒福人工智能实验室研制出来的。该系统的目的在于提供一个自然语言理解的直观模型。系统首先把英语句子转换为概念依存表达式，然后根据系统中有关信息进行推理，从概念依存表达式中推演出大量的事实。由于人们在理解句子时，总要牵涉到比句子的外部表达多得多的内容，因此，该系统的推理有16种类型，如原因、效应、说明、功能等等，最后，把推理的结果转换成英语输出。 SAM系统是阿贝尔森（R.Abelson）于1975年在美国耶鲁大学建立的。这个系统采用”脚本”（script）的办法来理解自然语言写的故事。所谓脚本，就是用来描述人们活动（如上饭馆、看病）的一种标准化的事件系列。 PAM系统是威林斯基（R.Wilensky）于1978年在美国耶鲁大学建立的另一个理解故事的系统。PAM系统也能解释故事情节，回答问题，进行推论，作出摘要。它除了 “脚本”中的事件序列之外，还提出了”计划”（plan）作为理解故事的基础。所谓” 计划”，就是故事中的人物为实现其目的所要采取的手段。如果要通过”计划”来理解故事，就要找出人物的目的以及为完成这个目的所采取的行动。系统中设有一个”计划库”（plan box），存贮着有关各种目的的信息以及各种手段的信息。这样，在理解故事时，只要求出故事中有关情节与计划库中存贮的信息相重合的部分，就可以理解到这个故事的目的是什么。当把一个一个的故事情节与脚本匹配出现障碍时，由于”计划库”中可提供关于一般目的的信息，就不致造成故事理解的失败。例如，营救一个被暴徒抢走的人，在”营救”这个总目的项下列若干个子目的，包括到达暴徒的巢穴以及杀死暴徒的各种方法，就可以预期下一步的行为。同时能根据主题来推论目的。例如，输入故事：”约翰爱玛丽。玛丽被暴徒抢走了。”PAM 系统即可预期约翰要采取行动营救玛丽。故事中虽然没有这样的内容， 但是， 根据计划库中的”爱情主题”，可以推出 “约翰要采取行动营救玛丽”的情节。 上述的系统都是书面的自然语言理解系统，输入输出都是用书面文字。口头的自然语言理解系统，还牵涉到语音识别、语音合成等复杂的技术，显然是更加困难的课题，口头自然语言理解系统的研究近年来也有进展。 我国的发展状况 我国自然语言理解的研究起步较晚，比国外晚了17年。国外在1963年就建成了早期的自然语言理解系统，而我国直到1980年才建成了两个汉语自然语言理解模型，都以人机对话的方式来实现。 八十年代中期，在国际新一代计算机激烈竞争的影响下，自然语言理解的研究在国内得到了更多的重视，”自然语言理解和人机接口”列入了新一代计算机的研制规划，研究单位增多了，研究队伍也壮大了。 关于HNC理论 HNC理论是”Hierarchical Network of Concepts（概念层次网络）”的简称，是关于自然语言理解处理的一个理论体系。它以概念化、层次化、网络化的语义表达为基础，所以称它为概念层次网络理论。HNC理论把人脑认知结构分为局部和全局两类联想脉络，认为对联想脉络的表达是语言深层（即语言的语义层面）的根本问题。 HNC理论的中心目标是建立自然语言的表述和处理模式，使计算机能够模拟人脑的语言感知功能。该理论使自然语言理解获得了突破性的进展，它所蕴涵的精深丰富的思想对人工智能、语言学、计算机科学和认知科学等都具有重要的理论和应用价值，对中文信息处理和汉语研究尤其具有实际意义。 HNC理论完全摆脱了我国现有的这套语法学的束缚，而从语言的深层入手，以语义表达为基础，为汉语理解开辟了一条新路。HNC理论提出了可供工程实现的完整的自然语言理解的理论框架，它是一个面向整个自然语言理解的强大而完备的语义描述体系，包括语句处理、句群处理、篇章处理、短时记忆向长时记忆扩展处理、文本自动学习处理。HNC理论的出发点就是运用两类联想脉络来”帮助”计算机理解自然语言。自然语言的词汇是用来表达概念的，因此，HNC建立的词汇层面的局部联想脉络体现为一个概念表达体系。概念分为抽象概念与具体概念。HNC理论的概念表达体系侧重于抽象概念的表达。对具体概念采取挂靠近似表达方法。HNC理论认为应该从多元性表现和内涵两个方面来描述概念。 它创立了五元组用来表达抽象概念的多元性表现，对抽象概念的内涵采用网络层次符号来表达。其网络层次符号包含三大语义网络：基元概念语义网络、基本概念语义网络和逻辑概念语义网络。HNC的五元组符号和三大语义网络的层次符号组合起来就可完成对抽象概念的完整表达，从而为计算机理解自然语言的语义提供了有力的手段。 自然语言理解技术大致可分为机器翻译、语义理解及人机会话技术几个方面。其中机器翻译(machine translation)，又称机译(MT)，是利用计算机把一种自然语言转变成另一种自然语言的过程。智能搜索引擎在这一领域的研究将使得用户可以使用母语搜索非母语的网页，并以母语浏览搜索结果。语义理解通过将语言学的研究成果和计算机技术结合在一起，实现了对词语在语义层次上的理解。人机会话技术可以为计算机提供下一代的人机交互接口，实现从文字接口、图形接口到自然语言接口的革命，同时在家用电器的人性化设计方面有着广泛的应用前景，其技术内涵主要包括语音识别、语音合成两个核心部分。 在语义理解的整个过程中，智能分词技术是最初的一个环节，它将组成语句的核心词提炼出来供语义分析模块使用。在分词的过程中，如何能够恰当地提供足够的词来供分析程序处理，并且过滤掉冗余的信息，这是后期语义分析的质量和速度的重要前提。尤里卡的智能分词避免了传统分词技术在拆分时产生的歧义组合。从而为语义理解的处理提供了良好的原始材料。同时，在分词的过程中，知识库当中的同义词会被逐个匹配并同时提交给语义理解模块使用，这样处理过的句子，不仅提供了原始的句型，还同时搭载了语句的概念部分。 第二部分 在搜索技术中的应用 众所周知，随着互联网的迅速发展和广泛普及而导致网上信息爆炸性增长。如何在庞大的互联网上获得有价值的信息已成为网民日益关注的问题。这种以一定的策略在互联网中搜集、发现信息，对信息进行理解、提取、组织和处理，并为用户提供检索服务，从而起到信息导航的目的的搜索技术的出现为网民快速找到所需信息带来了福音。 但是，2001年，Roper Starch的调查指出，36%的互联网用户一个星期花了超过2个小时时间在网上搜索；71%的用户在使用搜索引擎的时候遇到过麻烦；平均搜索12分钟以后发现搜索受挫；搜索受挫中46%都是因为链接错误；绝大部分(86%)的互联网用户感到应当出现更有效的、准确的信息搜索技术。另一项由Keen所做的调查显示，人们平均每天有四个问题需要从外界获取答案；其中31%的人使用搜索引擎寻找答案；平均每周花费8.75个小时找寻答案；53.3%时间花在从旁人那里获得答案，29%的时间花在亲戚朋友身上，24.3%的是时间花在销售商那里；网上查找答案的，半数以上都不成功；他们每周将花费14.5美元以上，以获取正确的信息。 从这些调查数据中不难看出，尽管搜索服务提供者在研发搜索技术方面已经花费了大量的时间和精力，但是目前的搜索引擎仍然存在不少的局限性，比如信息丢失、返回信息太多、信息无关，这使得网民对于现有的搜索技术仍然不满，期盼更完美的搜索技术的出现。 由于自然语言理解技术的三方面功能，即机器翻译、语义理解及人机会话技术能够赋予搜索技术更具人性化、方便易用的特点。因此，近年来在搜索界得到了广泛的应用。无论是国内外的搜索引擎，都可以寻觅到语义理解、机器翻译的踪迹。 目前在搜索引擎方面主要应用的自然语言理解技术是机器翻译与语义理解技术。应用了这些技术的搜索引擎我们称之为智能搜索引擎。由于它将信息检索从目前基于关键词层面提高到基于知识（或概念）层面，对知识有一定的理解与处理能力，因而具有信息服务的智能化、人性化特征。它允许网民采用自然语言进行信息的检索，为他们提供更方便、更确切的搜索服务。 与传统的目录查询、关键词查询模式相比，自然语言查询的优势体现在：一是使网络交流更加人性化；二是使信息查询变得更加方便、快速和准确。现在，已经有越来越多的搜索引擎宣布支持自然语言搜索特性。比如国外的搜索引擎Google,，AskJeeves；国内的搜索引擎网易、尤里卡、问一问、21世纪互联、孙悟空、悠游等。在这里我们将重点介绍应用语义理解技术的中文智能搜索引擎。 首先以尤里卡搜索引擎为例简要说明一下这种智能搜索的过程。 实现智能搜索的过程主要分三部分：语义理解、知识管理和知识检索。其中，知识库是实现智能搜索的基础和核心。知识库提供的是语义理解中最终将要提供给用户的结果，同互联网的状况相同，人类的知识结构和容量都在飞速膨胀，所以知识库也需要有良好的适应能力。在语义理解的整个过程中，智能分词技术是最初的一个环节，它将组成语句的核心词提炼出来供语义分析模块使用。在分词的过程中，如何能够恰当地提供足够的词来供分析程序处理，并且过滤掉冗余的信息，这是后期语义分析的质量和速度的重要前提。 加入了知识库处理技术的智能分词能够避免了传统分词技术在拆分时产生的歧义组合。从而为语义理解的处理提供了良好的原始材料。知识检索可以利用语义分析的结果，对知识库进行概念级的检索，对用户提出问题给出准确度最高、相关度最强的检索结果。比如：”我想在北京找工作？”。首先进行语义理解，在知识库中”找工作”属于求知招聘的范畴，所以分析出用户想查询”在北京求职”。然后利用”在北京求职”这个概念查询知识库，得出答案。 下面我们再来看看各家宣称应用了自然语言理解的搜索技术有哪些特点。 问一问（www.weniwen.com）自然语言检索 问一问是由闻易网科技有限公司（Weniwen Technologies, Inc.）开发的智能搜索引擎。它允许用户以自然的、整句的方式、以汉语或英语发出查询请求。易于快速地、以比较经济的方式扩展到不同的语言。 并可以同时从两种语言中识别出词汇。使用自然语言处理（NLP）技术，与传统的、基于关键词匹配的搜索技术相比，NLP技术可使问一问”理解”请求中的上下文和含义。通过使用NLP技术，问一问可以更准确地检索出适当的信息。尤其适用于旅游/休闲、金融以及消费品工业的、正在寻求可增强消费者通过Internet来访问其信息或进行自动交易的途径的大企业或门户。 21ilink（www.21ilink.com）中文智能搜索引擎 世纪讯联公司开发的基于自然语言处理和人工神经网络的智能互动技术解决了传统信息分类中的一些语意交叉词汇抽象概念、边缘类别的信息查询问题实现了模糊查询。查询过程突出了个性化、人性化。采用了自然语言的语句单元，还可设定地方语言特色。界面更加友好，能够满足不同层次，不同查询目的客户的特殊需求。并能引导查询者快速准确地找到所需要的信息。此项智能搜索技术采用国内独创的中文问答方式，并兼容了其他传统的搜索引擎的查询方式。支持基于概念的信息搜索、行业化、专业化的智能搜索、客户定制的商务模型，还可完成管理、追踪、支付等一系列的供应链的分析、行业研究等咨询项目。实现了多方协作,业务拓展的无缝结合。 此项智能搜索系统是将现代智能计算技术、交换技术、网络技术、数据库技术融为一体，而建成的一个面向客户的，全方位高质量的服务体系。采用了独有的Smart Hit（智能语义）、和Kengine（知识引擎）。开放性、先进性和超前性均大大领先于同类系统。全套系统拥有完整的智能网络接入服务功能，支持各网络平台的语音文字、数据及图像，是一种智能多媒体平台。平台无中断，支持宽频网络，满足对数据库全内容覆盖要求。支持概念检索、动态页面检索。 孙悟空（search.chinaren.com）搜索引擎 孙悟空搜索引擎是ChinaRen开发并拥有自主版权的产品,能按照用户的需求，搜索大陆和港澳台的中文网页。孙悟空搜索不仅可用传统的关键词搜索方式，更是在所有中文搜索引擎里率先采用了提问式搜索，这是ChinaRen研究并实现的一种智能中文处理技术。通过该技术，您可以直接通过提出问题的方式搜索您想要找的内容，这样不仅更符合我们平时的习惯，而且准确率更高。孙悟空搜索引擎拥有强大的搜索能力，提高搜索的智能性和准确性；智能的评价体系，保证检索结果高度相关。 悠游（www.goyoyo.com.cn）中文智能搜索引擎 北京悠游科技开发有限公司（Beijing Goyoyo）成立于1998年10月，是一个以中文自然语言处理技术为基础建立的互联网信息咨询及技术服务网站（www.goyoyo.com）。悠游中文智能搜索引擎通过www.goyoyo.com 提供主要服务。为了更贴近用户的语言使用习惯，凭借先进的自然语言处理技术，悠游中文智能搜索引擎充分考虑到中文语句的表达结构以及丰富多样的词语表达形式，通过”口语化的提问，智能化的结果” ，让用户在查询时只需用口语化的表达方式输入欲查询的关键词、自然语句甚至输入中英文混合语句，选择要查询的网站或网页，单击”搜索”按纽，悠游中文智能搜索引擎就会根据您的查询请求自动分析语句，并且提炼主题，找到满意的答案，满足了广大用户的各种查询需求，使您能够悠闲自得的在网上畅游。 下面举例说明应用了语义理解技术的搜索引擎与传统搜索引擎相比的优势。 1、更高的搜索的易用性 由于智能搜索引擎具有智能分词功能，因此使得查询变得更为简单、易于操作。以网易为例说明：需要搜索”刘德华的最新个人专辑”，只需要将整个搜索内容全部输入到搜索框中就可以找到相关的内容；而在传统的搜索引擎中则必须遵守搜索的基本数学规则，输入”刘德华 最新 个人专辑”才能够找到搜索的内容。显然在搜索的易用性方面智能搜索引擎具有明显的优势。 2、搜索结果的范围定位准确 由于采用知识（概念）检索技术，明确和缩小的搜索范围，减少对无用信息的搜索。以尤里卡为例说明：要查找”北京的天气”只需要输入”北京天气”就可以找到相关程度甚高的北京的天气预报，同时还会给出相关的天气的内容。而在传统搜索引擎的查询结果中不但有北京天气的内容，还会给出所有与北京天气字样有关的各种内容，增大了用户查找搜索结果的难度。 3、搜索结果的智能性 由于智能搜索引擎有综合知识库为背景，使得信息检索与导航服务更具有智能性。知识库中的知识有助于解决表达差异的问题。所谓表达差异就是用户使用不同的词表达同一概念。而知识库中关于同义词的定义正好可以消除这种表达差异带来的检索困难。 从上面的示例及比较不难看出运用了先进的自然语言理解技术后，搜索引擎可以识别并回答用户的问题，使用户摆脱了传统搜索引擎基于关键字的束缚，指引用户更有效更快捷地寻找到所需的资料，同时为用户提供相关的有参考价值的其他内容。由于这些特点，使得智能搜索技术能够在互联网信息检索的各个方面得到广泛的应有。它可以为大型综合搜索引擎提供后台支持，使之具有人性化、交互性的特点。它能够方便的实现垂直搜索引擎的专业类别内搜索。当然它也可以为信息门户网站提供方便快捷的站内信息搜索服务。

Trackback: http://tb.blog.csdn.net/TrackBack.aspx?PostId=550607

1 ∥　用于单行注释。注释从∥开始,终止于行尾。

2 /* … */ 用于多行注释。注释从/*开始,到*/结束,且这种注释不能互相嵌套。

3 /** … */ 是Java所特有的doc注释。它以/**开始,到*/结束。这种注释主要是

为支持JDK工具javadoc而采用的。javadoc能识别注释中用标记@标识的一些特殊变量,并把

doc注释加入它所生成的HTML文件。对javadoc的详细讲述可参见附录。

　　Are you by yourself？你一个人来吗？

　　All right with you？你没有问题吧？

　　Are you free tomorrow？明天有空吗？

　　Are you kidding me？你在跟我开玩笑吧？

　　As soon as possible！尽可能快！

　　Back in a moment！马上回来！

　　Believe it or not！信不信由你！

　　Better luck next time！下次会更好！

　　Boy will be boys本性难移！

　　Come to the point！有话直说！

　　Do you accept plastic？收不收行用卡？

　　Does it keep long？可以保存吗？

　　Don’t be so fussy！别挑剔了！

　　Don’t count to me！别指望我！

　　Don’t fall for it！不要上当！

　　Don’t get me wrong！你搞错了！

　　Don’t give me that！少来这套！

　　Don’t let me down！别让我失望！

　　Don’t lose your head！别乐昏了头！

　　Don’t over do it！别做过头了！

　　Don’t sit there daydreaming！别闲着做白日梦！

　　Don’t stand on ceremony！别太拘束！

　　Drop me a line！要写信给我！

　　Easy come easy go！来得容易去得也快！

　　First come first served！先到先得！

　　Get a move on！快点吧！

　　Get off my back！不要嘲笑我！

　　Give him the works！给他点教训！

　　Give me a break！饶了我吧！

　　Give me a hand！帮我一个忙！

　　Great minds think alike！英雄所见略同！

　　I’ll treat you to lunch.午餐我请你！

　　In one ear，out the other ear.一耳进，一耳出！

　　I’m spaced-out！我开小差了！

　　I beg your pardon！请你再说一遍！

　　I can’t afford that！我付不起！

　　I can’t follow you！我不懂你说的！

　　I can’t help it！我情不自禁！

　　I couldn’t reach him！我联络不上他！

　　I cross my heart！我发誓是真的！

    I don’t mean it！我不是故意的！

　　I feel very miserable！我好沮丧！

　　I have no choice！我别无选择了！

　　I watch my money！视财如命！

　　I’ll be in touch！保持联络！

　　I’ll check it out！我去看看！

　　I’ll show you around！我带你四处逛逛！

　　I’ll see to it！我会留意的！

　　I’m crazy for you！我为你疯狂！

　　You make me jump！你下了我一跳！

　　Make up your mind.作个决定吧！

　　Make yourself at home！就当在家一样！

　　My mouth is watering！我要流口水了！

　　Never heard of it！没听说过！

　　Nice talking to you！很高兴和你聊天！

　　No doubt about it！勿庸置疑！

　　No pain no gain！不经一事，不长一智！

　　None of your business！要你管？

　　There is nothing on your business！这没你的事！

　　Now you are really talking！说得对！

　　Please don’t rush me！请不要吹促我！

　　Please keep me informed！请一定要通知我！

　　She looks blue today.她今天很忧郁！

　　She is under the weather.她心情不好！

　　So far，so good.过得去。

　　Speaking of the devil！一说曹操，曹操就到！

　　Stay away from me！离我远一点！

　　Stay on the ball！集中注意力！

　　That makes no difference.不都一样吗？

　　That’s a touchy issue！这是个辣手得问题！

　　That’s always the case！习以为常！

　　That’s going too far！这太离谱了！

　　That’s more like that！这才象话嘛！

　　The answer is zero！白忙了！

　　The dice is cast！已成定局了！

　　The same as usual！一如既往！

　　The walls have ears！隔墙有耳！

　　There you go again！你又来了！

　　Time is running out！没有时间了！

　　We better get going！最好马上就走