Download: decompress.sh

#!/bin/bash

#set -x
echo “Handy Extract Program”

extract () {
if [ -f $1 ] ; then
case $1 in
*.tar.bz2) tar xvjf $1 ;;
*.tar.gz) tar xvzf $1 ;;
*.bz2) bunzip2 $1 ;;
*.rar) unrar x $1 ;;
*.gz) gunzip $1 ;;
*.tar) tar xvf $1 ;;
*.tbz2) tar xvjf $1 ;;
*.tgz) tar xvzf $1 ;;
*.zip) unzip $1 ;;
*.Z) uncompress $1 ;;
*.7z) 7z x $1 ;;
*) echo “‘$1′ cannot be extracted via >extract<” ;;
esac
else
echo “‘$1′ is not a valid file”
fi
}

extract $1

The fast answer to tackle this problem is to add the lucene-core*.jar to the libaries of your project, and make sure that the file /META-INF/services/org.apache.lucene.index.codecs.Codec is included in lucene-core*.jar. 

The problem is caused by the class of java.util.ServiceLoader used in NamedSPILoader of Solr. When ServiceLoader creates a new service provider, it will extract some information from /META-INF/services/org.apache.lucene.index.codecs.Codec. Therefore when you use build classes rather than the lucene-core*.jar file, the needed information can not be obtained. By now, I think you can handle this problem yourself. 

For more information about How ServiceLoader work, please refer to: 

http://jcs.mobile-utopia.com/jcs/19273_ServiceLoader.java In English

http://mxdxm.iteye.com/blog/1059300 In Chinese

汉字编码问题
下面是搜集的多篇关于汉字编码问题文章的合集，相信你的问题一定包含在其中，如果没有请留言，一起把这方面的内容补充全。一、汉字编码的种类
汉字编码中现在主要用到的有三类，包括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

HashMap ssMap = new HashMap(); 

Counter counters[] = new Counter[ssMap.size()];
ssMap.values().toArray(counters); //转化，counters不需实例化
Arrays.sort(counters,new DfComparator());//排序

2. Comparator 实例

继承Comparator也可以实现排序，但相对Comparable接口更加灵活，用不同的Comparator实例可以实现不同的排序方法

class DfComparator implements Comparator
{
public int compare(Object o1, Object o2) {
// TODO Auto-generated method stub
Counter c1 = (Counter)o1;
Counter c2 = (Counter)o2;

  return c2.df – c1.df;
}
public boolean equals(Object obj)
{
return true;
}

}

3.Map访问语句备忘

 public static void print(Map map)
{
Set set = map.entrySet();
Iterator iter = set.iterator();
while(iter.hasNext())
{
Map.Entry entry = (Map.Entry)iter.next();
entry.getKey();
entry.getValue();
}
}

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。

Sent to you by jeffye via Google Reader:

房地产救市岂能不择手段?

via 曹建海的博客 by 曹建海 on 2/18/09

房地产救市岂能不择手段?

——从“购房退个税”
和“购房落户”政策说起

   
在经历了2008年的金融海啸冲击之后，中国城市的房价仍然居高不下。国家统计局发布的2008年国民经济数据显示，全国70个大中城市房屋销售价格比上年上涨6.5%。在房价从2008年的顶点滑落之后，中央和各地方政府出台了密集的房地产救市政策，其目的在于防止房价大落，并寄望房地产业继续发挥其经济增长、促进金融业稳定和发展的作用。

央视也真像是一条变色龙，为了响应国务院“维稳”房地产市场的号召，最近频频邀请前一阶段被媒体批得抬不起头的伪劣教授董藩。说起来也该董藩出头了，在国内大学科研院所拥有教授、研究员职称的人当中，
董先生是鼓吹高房价最响、也最为开发商卖命的。我确实没有看到有谁像他那样把开发商的事业看得如此神圣的。由于很长时间批判高房价、批判开发商的思想洗礼，多数学者开始同情普通百姓，能和国务院、住房和建设部、房地产开发商保持高度一致的，也确实有些凤毛麟角了。央视要寻找这样的“专家”，想来找得很辛苦。还好，董藩教授被北师大公共管理学院像“国宝”一样养着，虽然“荒凉”了几年，终于再被请到了央视，而且一发而不可收啦。

对于“购房退个税”、“购房落户”，这些颇具争议性的房地产救市政策，在落座的众人中，只有董藩“斩钉截铁”地肯定；其他人如提出不同意见，则被董“专家”责为不是搞房地产研究的，不了解情况而哑口无言。董藩的滔滔不绝和斩钉截铁，引得主持人李小萌无比的崇拜，也尽量把发言的机会留了董藩——董藩啊，这几天真的好得意呢！

写上面这段话，意在立此存照。当小丑都被奉为国师、英雄，真正智慧的声音和人民的呼声都被淹没了。可见当前的中国，正是一个指鹿为马、不辨是非、黑白颠倒的时代。不仅体现在房地产领域，还体现在固定资产投资、股票市场等领域：当某政府领导人在星期天还在国外关心中国的股市涨了没有时，政府希望借助股市上涨刺激消费的目的，也就昭然若揭了；全然不顾由此引起的更严重的恶果。于是，1月份银行体系新增的1.6亿贷款当中，一大部分涌入了股市，加上所谓“产业振兴计划”的频频利好，失去增长动力的中国经济，其股票市场却呈现了匪夷所思的“繁荣”景象。

房地产是政府“保增长”的“桥头堡”。尽管暴利的房地产被批臭了，然而，当一位受人尊重的老人，亲自为房地产商说话、要求大家顾全“保增长”的大局时，批评的声音终于被压制了。由此，“万众萧疏鬼唱歌”的景象，又重新回到了中国大地。在上述唱将当中，董藩无疑是开发商们比较欣赏的一位。尽管忽悠的水平还不如任志强，考虑到“自卖自唱”毕竟不能服人，还得由不是开发商身份的董教授出面较好。

政府官员队伍中开发商的同情者实在太多。这些人虽然也披着“共产党员”的外衣，但是当房地产市场发展威胁到地方政府财政收入，从而不能乱花钱时，人民的利益算得了什么，没有什么比金钱更重要的了。于是，我们看到了正在上演的由各级政府官员们出演的，有史以来最丑陋的话剧。

   
各地出台的房地产救市政策中，目前最受房地产开发商们青睐和赞赏的，当属“购房落户”
和“购房个退税”政策。根据“购房落户”政策，卖房的同时，政府还顺手送一个户口，对于一些有钱人来说，房价高一些又算什么呢？有中央领导压阵的重庆市政府更是不甘落后，“购房退个税”政策，市内购买住房的个人按揭贷款本息，可抵扣产权人个人所得税的地方提留部分；同时该市还包括减免部分契税，营业税，交易税，同时放宽主城区购房的入户限制等等。

   
重庆市政策出台以后，一定刺激了低迷的房市。今年2月2日，有媒体公开报道国务院下发紧急通知，要求该市暂停“购房退个税”政策；其后重庆市的辟谣和报道媒体的致谦，使得这个政策能否实施，更加具有戏剧性。虽然“购房退个税”政策被暂停了，但“购房落户”政策，却在全国多个城市轰轰烈烈地展开了，大有一举扭转房地产市场的态势。

  
各地政府在房地产救市时理直气壮的态度，似乎在表明一种立场：政府就是要全力拯救房地产，在“保增长”的大局面前，希望人们不要说三道四，同时没有什么办法是不能尝试的。

   
政府房地产救市的一个主要措施，是政府从房地产利益链当中退出一部分，这有利于完全房价水平的降低，本是无可厚非的。但是，为了刺激房地产市场，政府动用公共权力，为购房者提供房地产税费之外的利益，例如购房退个税、购房落户等，希望借此维持房价和成交量，则有违政府的公平原则了。

   
在笔者看来，各地推进的“购房落户”、“购房退个税”诸政策，至少存在以下两个致命缺点：

   
一是不利于房价水平的合理下降。众所周知，我国房地产市场低迷的根本原因，在于高涨房价脱离了绝大部分家庭的收入水平。如果政府的救市举措就是为了维护高房价，

保持房地产价格水平的虚高，要想保证住房消费增长的可持续性，是根本不可能的。因此，拉动经济扩大内需，不能依靠刺激国内居民购房。在现有房价虚高的情况下，鼓励老百姓买得太多，必然会挤压了其他的消费，并且透支了未来的消费。

二是严重损害了公平和正义，不利于社会和谐发展。税赋的前提就是公平，如果购房就可以避税，则高收入者可以通过购房，规避应该缴纳的个人所得税，虽然可以起到刺激房市的目的，但公平和正义被侵犯；户籍制度改革的方向是城乡一体化、登记制，政府“购房落户”政策实际上在给户口定价，用户口的市场价格冲减购房者的负担，这将给本地居民、租住住房的外地劳动者带来巨大的不公平，而且不利于打破城乡封锁。这种政策的本质，在于维护社会不平等，必然亵渎了公众赋予政府的权利。

如果为了房地产救市“保增长”，政府政策可以不择手段，追求公平可以被认为“不识大体”。那么，政府除了实施“住房退个税”、“购房落户”之外，还可以考虑尝试给购房者“奖励生育指标”、“给以行政级别和‘两会’代表资格”、“抵免刑罚”等政策。由于政府提供的标的具有相当的经济价值，购房者购买住房的价格，实际上是房价扣除政府优惠政策市场价值之后的余额，实际上是变相降价了。可以想象，这样的救市将导致社会价值体系的混乱，公平和正义将被践踏，这样的“救市”、“保增长”将带来什么样的社会后果？！

由此我想到了汉灵帝（156～189年）刘宏。在其统治期间，党锢之祸兴起，宦官把持大权，公开标价卖官，肆意大兴土木，百姓难以为生。中平元年（184年），爆发了声势浩大的黄巾起义。按照现行的标准，那些买官的人贡献了自己的财富，支持朝廷大兴土木，实际上为“保增长”做出了“杰出”的贡献，属于时代的英雄！随着基本建设的兴起，楼堂馆所工程所需要的木材、石料等生产也被拉动起来，成千上万的建筑工匠实现了就业，国家经济由此迅速增长起来了。让我百思不得其解的是：为什么汉灵帝扩大投资“保增长”的计划会导致黄巾军起义的暴利破坏。用现代观点看，这些农民不仅不设大局，更不懂得中央高层和官员们所共同拥有的，一颗拳拳爱民的心啊！

   
因此，要拯救房地产市场，需要思考以下重大问题：第一，要不要遵循经济规律，通过价格调整促进房地产市场的需求？第二，以侵犯公民公共权利、损害社会基本价值体系的做法“保增长”，算不算是一种“大局”？第三，经济增长的最终意义是什么？思考了再行动，即使是错误的，也不用后悔了，大不了上断头台！

Things you can do from here:

• Subscribe to 曹建海的博客 using Google Reader
• Get started using Google Reader to easily keep up with all your favorite sites

Microsoft Word文档中搜索替换时常用的特殊符号

via Pure Pleasure – Reborn by 李笑来 on 2/16/09

经常需要大量处理文本的读者，花一点时间学学MS Word中的“搜索替换通配符”是非常值得的。我经常看到身边的人因不懂这些基本“常识”而浪费大量时间，更有甚者，可能因为不懂这些而人为导致一些任务变成“不可完成、不可想象”的任务。

有些人（比如我）读写文档的时候，习惯于两个段落之间空一整行，因为这样可以方便阅读或者审阅。而遇到另外一些人编辑过的Word文档，其中的段落与段落紧挨着，由于习惯便觉得特别难以阅读，怎么办？只需要用CTRL+H呼出“查找和替换”对话框，搜索“^p”替换“^p^p”即可：

其中“^p”（不含引号）代表“段落标记”。

类似的特殊符号还有：

• “^l”代表“手动换行符”；
• “^m”代表“手动分页符”；
• “^s”代表“不间断空格”；
• “^+”代表“长划线”；
• “^=”代表“短划线”；
• “^~”代表“不间断连字符”；
• “^-”代表“可选连字符”；

如果你想把文章中所有的“全角空格”全部替换为“半角空格”，那么就要搜索“^u8195”替换“ ”：

如果你想把所有加重字体的文本全都换个颜色（比如蓝颜色），那么：

1. CTRL+H呼出“查找和替换”对话框；
2. 用鼠标在“查找内容（N）：”右边的输入框里点一下，而后按键盘“CTRL+b”；
3. 用鼠标在“替换为（I）：”右边的输入框里点一下，而后按键盘“CTRL+b”；
4. 点击“更多（M）”按钮；
5. 点击“格式（O）”按钮，选择“字体”，呼出“替换字体”对话框；在“字体颜色（C）”下的下拉框中选择蓝色之后按“确定”按钮关掉对话框；
6. 点击“查找和替换”对话框中的“替换（R）”或者“全部替换（A）”按钮……

参照以下两张图片：

读者需要需要举一反三的话，那么就在MS Word的帮助文件里搜索“查找和替换”，读一读帮助文档就好。

Things you can do from here:

• Subscribe to Pure Pleasure – Reborn using Google Reader
• Get started using Google Reader to easily keep up with all your favorite sites