说说多种字符编码的统一处理

　　学校目前有几台阵列，几台linux服务器，几台windows服务器，还有一台FreeBSD服务器，各种服务器之间存储文件使用的编码是不一样的，而且这些服务器上挂的不同站点使用的字符编码也是不一样的。早期没有按照统一的标准制作，结果现在酿下的苦果就是我们这些继承人在处理问题的时候常常被编码问题所困扰。也许你也遇到了这种情况。最近正好搜了一些资料。了解了一些东西。共享出来。

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
预备知识：

1. 字符集和编码

　　在Linux上经常使用的字符集是ISO 8859系列的字符集．它包含了10个 多语言的单字节编码字符集．它们分别是，

字符集	涵盖语言
ISO 8859-1（Latin1）	拉丁一字符集， 包含绝大多数的欧洲语言， 例如French（fr）， Spanish （es）， Catalan （ca）， Basque （eu）， Portuguese （pt）， Italian （it）， Albanian （sq）， Rhaeto-Romanic （rm）， Dutch （nl）， German （de）， Danish （da）， Swedish （sv）， Norwegian （no）， Finnish （fi）， Faroese （fo）， Icelandic （is）， Irish （ga）， Scottish （gd）， English （en）， Afrikaans （af） 和 Swahili （sw）．影响了美洲， 澳洲和非洲．
ISO 8859-2（Latin2）	拉丁二字符集， 包含了中欧和东欧的语言：Czech （cs）， Hungarian （hu）， Polish （pl）， Romanian （ro）， Croatian （hr）， Slovak （sk）， Slovenian （sl）， Sorbian．
ISO 8859-3（Latin3）	拉丁三字符集， 包括： Esperanto （eo） and Maltese （mt）
ISO 8859-4（Latin4）	拉丁四字符集， 包括： Estonian （et）， 巴尔地克 Latvian （lv） 和 Lithuanian （lt）， Greenlandic （kl） ， Lappish．
ISO 8859-5（西里尔语）	Bulgarian （bg）， Byelorussian （be）， Macedonian （mk）， Russian （ru）， Serbian （sr）
ISO 8859-6（阿拉伯语）	阿拉伯语（ar）
ISO 8859-7（希腊语）	希腊语（el）
ISO 8859-8（希伯来语）	Hebrew （iw） 和Yiddish （ji）
ISO 8859-9（Latin5）	重排了Latin1， 用土耳其语的几个字母做了替换
ISO 8859-9（Latin6）	重排了Latin4， 去掉了某些符号， 增加了Inuit等
ISO 8859-11（泰国语）	泰国语（th）
ISO 8859-12	Celtic
ISO 8859-13（Latin7）	Baltic Rim 和 Lativian（lv）
ISO 8859-14（Latin8）	Gaelic 和 Welsh （cy）
ISO 8859-15（Latin9）	Latin1的变种， 修改了某些字母

　　双字节字符集主要包含中文，日文和韩文．它由前导字节（Lead Byte） 和尾部字节（Trail Byte）构成， 由于一个字符采用了两个字节， 在软件的 国际化方面又增加了一些麻烦， 比如在显示上， 光标的位置不能位于汉字 之间， 删除和移动时必须是整字操作等， 在输入上， 一般需要预编辑服务器 才能输入汉字． 下表列出了中日韩语言编码的有关信息：

语言	字符集	代码页	前导字节范围	尾部字节范围
简体中文	GB2312-1980	CP936	0xA1-0xF7	0xA1-0xFE
	GBK	无	0x81-0xFE	0x40-0x7E， 0x80-0xFE
中文繁体	BIG-5	CP950	0x81-0xFE	0x40-0x7E， 0xA1-0xFE
日文	Shift-JIS	CP932	0x81-0x9F， 0xE0-0xFC	0x40-0xFC（0x7F除外）
韩文	KSC-5601-1987	CP949	0x81-0xFE	0x41-0x5A，0x61-0x7A，0x81-0xFE
	KSC-5601-1992	CP1361	0x84-0xD3 0xD8 0xD90-0xDE 0xE0-0xF9 0x41，0xFE	0x41-0x7E 0x81-0xFE 0x31-0x7E

　　信息产业部和国家质量技术监督局联合制定了两项中文信息处理基础性国家标准，为解决偏、生汉字的输入提供了方案。其中GB18030- 2000《信息技术和信息交换用汉字编码字符集、基本集的扩充》，为强制性 国家标准．它收录了2.7万多个汉字，总编码空间超过150万个码位，为彻底 解决邮政、户政、金融、 地理信息系统等迫切需要的人名、地名用字问题 提供了解决方案，也为汉字研究、古籍整理等领域提供了统一的信息平台基础。 这项标准还同时收录了藏文、蒙文、维吾尔文等主要的少数民族文字．字符 集编码范围是：

字节数	编码空间	码位数目
单字节	0x00-0x80	129
双字节	第一字节：0x81-0xFE 第二字节：0x40-0x7E，0x80-0xFE	23940
四字节	四字节范围分别是： 0x80-0xFE，0x30-0x39，0x81-0xFE，0x30-0x39	1587600

　　香港特别行政区也对Big5编码提出了"香港增补字符集"， 其目的，是 收纳香港特区政府及市民在中文电子通讯中有需要使用的字符，来补充目前 大五码和ISO10646编码标准内并未包含的字符，以作为一个通用的中文界面， 方便大家能准确地以中文进行电子通讯。香港增补字符集有两套编码方案， 一套适用於大五码系统，另一套适用於ISO10646平台。香港增补字符集的大 五码版本，实际上是政府通用字库的增订版。ISO10646国际编码标准目前并 未包含香港增补字符集内的所有字符。目前尚未收纳在ISO10646内的香港增 补字符集字符，均已提交国际标准化组织管辖下的表意文字小组，以考虑是 否纳入ISO10646日后的新增版本内．

2. 多字节字符（Multibyte）和宽字符（WideChar）的使用

　　我们平时见到的以文本方式存在的字符都是多字节字符， 它主要用于文件存储和网络上的以流（Stream）的方式传输．一个GB编码的汉字需要两个字节．多字节字符的缺点是在中文处理上不方便， 比如汉字的删除和光标的移动都会有半汉字问题．为了文本处理的方便，在内部操作上通常是把汉字 与英文的混和字符串先转换成等宽度的字符串， 即宽字符，为软件的内部处理 提供方便．

　glibc2.1.x中多字节字符串和宽字符串的转换有时有问题．在X下还可以 使用另外一种方式完成转换， 即使用XmbTextListToTextProperty（）和 XwcTextPropertyToTextList（） 联合完成转换．

3. Unicode

　　目前所使用的Unicode 是一种16位字宽的字符编码， 它由非赢利的计算机 组织Unicode研讨会维护和改进．它起源于Xerox和Apple之间的合作研究．几 个公司组成了一个非正式的论坛， 接着IBM， Microsoft等公司迅速加入． Unicode研讨会在1990年发表了Unicode标准版本1， 同时国际标准化组织完成 了一种类似的编码----ISO 10646．因为没有必要存在两套标准， 所以Unicode 研讨会和国际标准化组织在1991到1992合二为一． 1994年， 中国和日本开始了基于ISO10646上的国家标准进行工作．现在， Unicode 开始用在许多产品中．

　　Unicode包含了当今计算机领域中广泛使用的所由字符， 如世界上大部分 的书面语言， 印刷字符， 数字和技术符号， 地理图形和标点符号．由于Unicode 的一致性， 它在大多数情况下都可能简化软件的国际化过程．它取消了处理多种代码页的必要， 并且由于是16位编码， 因此由双字节字符集所引起的额外处理也不必要了．

　　但是， Unicode作为一种编码也有它的缺陷， 比如编码的位置与排序无关， 所以使软件支持Unicode仅仅是国际化的第一步， 实际情况中还需要与语言相关的信息和规则．所以Unicode一般作为程序的内部处理编码， 必须提供与其它编码的双向转换表．

　　最后需要说明的是，虽然使用Unicode会使普通的英文文本大两倍， 但是使用Unicode的整个系统却不会增加太大，因为系统存放的文件大部分是二进制文件格式， 同时， 使用针对Unicode的压缩方式，可以把文件压缩成和使用对应的8位正文一样大小。

-----------------------------------------------------------------------------　　

UCS 和 ISO 10646?

国际标准 ISO 10646 定义了 通用字符集 (Universal Character Set, UCS). UCS 是所有其他字符集标准的一个超集. 它保证与其他字符集是双向兼容的. 就是说, 如果你将任何文本字符串翻译到 UCS格式, 然后再翻译回原编码, 你不会丢失任何信息.

UCS 包含了用于表达所有已知语言的字符. 不仅包括拉丁语,希腊语, 斯拉夫语,希伯来语,阿拉伯语,亚美尼亚语和乔治亚语的描述, 还包括中文, 日文和韩文这样的象形文字, 以及 平假名, 片假名, 孟加拉语, 旁遮普语果鲁穆奇字符(Gurmukhi), 泰米尔语, 印.埃纳德语(Kannada), Malayalam, 泰国语, 老挝语, 汉语拼音(Bopomofo), Hangul, Devangari, Gujarati, Oriya, Telugu 以及其他数也数不清的语. 对于还没有加入的语言, 由于正在研究怎样在计算机中最好地编码它们, 因而最终它们都将被加入. 这些语言包括 Tibetian, 高棉语, Runic(古代北欧文字), 埃塞俄比亚语, 其他象形文字, 以及各种各样的印-欧语系的语言, 还包括挑选出来的艺术语言比如 Tengwar, Cirth 和 克林贡语(Klingon). UCS 还包括大量的图形的, 印刷用的, 数学用的和科学用的符号, 包括所有由 TeX, Postscript, MS-DOS，MS-Windows, Macintosh, OCR 字体, 以及许多其他字处理和出版系统提供的字符.

ISO 10646 定义了一个 31 位的字符集. 然而, 在这巨大的编码空间中, 迄今为止只分配了前 65534 个码位 (0x0000 到 0xFFFD). 这个 UCS 的 16位子集称为 基本多语言面 (Basic Multilingual Plane, BMP). 将被编码在 16 位 BMP 以外的字符都属于非常特殊的字符(比如象形文字), 且只有专家在历史和科学领域里才会用到它们. 按当前的计划, 将来也许再也不会有字符被分配到从 0x000000 到 0x10FFFF 这个覆盖了超过 100 万个潜在的未来字符的 21 位的编码空间以外去了. ISO 10646-1 标准第一次发表于 1993 年, 定义了字符集与 BMP 中内容的架构. 定义 BMP 以外的字符编码的第二部分 ISO 10646-2 正在准备中, 但也许要过好几年才能完成. 新的字符仍源源不断地加入到 BMP 中, 但已经存在的字符是稳定的且不会再改变了.

UCS 不仅给每个字符分配一个代码, 而且赋予了一个正式的名字. 表示一个 UCS 或 Unicode 值的十六进制数, 通常在前面加上 "U+", 就象 U+0041 代表字符"拉丁大写字母A". UCS 字符 U+0000 到 U+007F 与 US-ASCII(ISO 646) 是一致的, U+0000 到 U+00FF 与 ISO 8859-1(Latin-1) 也是一致的. 从 U+E000 到 U+F8FF, 已经 BMP 以外的大范围的编码是为私用保留的.

什么是 Unicode?

历史上, 有两个独立的, 创立单一字符集的尝试. 一个是国际标准化组织(ISO)的 ISO 10646 项目, 另一个是由(一开始大多是美国的)多语言软件制造商组成的协会组织的 Unicode 项目. 幸运的是, 1991年前后, 两个项目的参与者都认识到, 世界不需要两个不同的单一字符集. 它们合并双方的工作成果, 并为创立一个单一编码表而协同工作. 两个项目仍都存在并独立地公布各自的标准, 但 Unicode 协会和 ISO/IEC JTC1/SC2 都同意保持 Unicode 和 ISO 10646 标准的码表兼容, 并紧密地共同调整任何未来的扩展.

那么 Unicode 和 ISO 10646 不同在什么地方?

　　Unicode 协会公布的 Unicode 标准 严密地包含了 ISO 10646-1 实现级别3的基本多语言面. 在两个标准里所有的字符都在相同的位置并且有相同的名字.

　　Unicode 标准额外定义了许多与字符有关的语义符号学, 一般而言是对于实现高质量的印刷出版系统的更好的参考. Unicode 详细说明了绘制某些语言(比如阿拉伯语)表达形式的算法, 处理双向文字(比如拉丁与希伯来文混合文字)的算法和排序与字符串比较所需的算法, 以及其他许多东西.

　　另一方面, ISO 10646 标准, 就象广为人知的 ISO 8859 标准一样, 只不过是一个简单的字符集表. 它指定了一些与标准有关的术语, 定义了一些编码的别名, 并包括了规范说明, 指定了怎样使用 UCS 连接其他 ISO 标准的实现, 比如 ISO 6429 和 ISO 2022. 还有一些与 ISO 紧密相关的, 比如 ISO 14651 是关于 UCS 字符串排序的.

　　考虑到 Unicode 标准有一个易记的名字, 且在任何好的书店里的 Addison-Wesley 里有, 只花费 ISO 版本的一小部分, 且包括更多的辅助信息, 因而它成为使用广泛得多的参考也就不足为奇了. 然而, 一般认为, 用于打印 ISO 10646-1 标准的字体在某些方面的质量要高于用于打印 Unicode 2.0的. 专业字体设计者总是被建议说要两个标准都实现, 但一些提供的样例字形有显著的区别. ISO 10646-1 标准同样使用四种不同的风格变体来显示表意文字如中文, 日文和韩文 (CJK), 而 Unicode 2.0 的表里只有中文的变体. 这导致了普遍的认为 Unicode 对日本用户来说是不可接收的传说, 尽管是错误的.

什么是 UTF-8?

首先 UCS 和 Unicode 只是分配整数给字符的编码表. 现在存在好几种将一串字符表示为一串字节的方法. 最显而易见的两种方法是将 Unicode 文本存储为 2 个 或 4 个字节序列的串. 这两种方法的正式名称分别为 UCS-2 和 UCS-4. 除非另外指定, 否则大多数的字节都是这样的(Bigendian convention). 将一个 ASCII 或 Latin-1 的文件转换成 UCS-2 只需简单地在每个 ASCII 字节前插入 0x00. 如果要转换成 UCS-4, 则必须在每个 ASCII 字节前插入三个 0x00.

在 Unix 下使用 UCS-2 (或 UCS-4) 会导致非常严重的问题. 用这些编码的字符串会包含一些特殊的字符, 比如 '\0' 或 '/', 它们在 文件名和其他 C 库函数参数里都有特别的含义. 另外, 大多数使用 ASCII 文件的 UNIX 下的工具, 如果不进行重大修改是无法读取 16 位的字符的. 基于这些原因, 在文件名, 文本文件, 环境变量等地方, UCS-2 不适合作为 Unicode 的外部编码.

在 ISO 10646-1 Annex R 和 RFC 2279 里定义的 UTF-8 编码没有这些问题. 它是在 Unix 风格的操作系统下使用 Unicode 的明显的方法.

UTF-8 有一下特性:

• UCS 字符 U+0000 到 U+007F (ASCII) 被编码为字节 0x00 到 0x7F (ASCII 兼容). 这意味着只包含 7 位 ASCII 字符的文件在 ASCII 和 UTF-8 两种编码方式下是一样的.
• 所有 >U+007F 的 UCS 字符被编码为一个多个字节的串, 每个字节都有标记位集. 因此, ASCII 字节 (0x00-0x7F) 不可能作为任何其他字符的一部分.
• 表示非 ASCII 字符的多字节串的第一个字节总是在 0xC0 到 0xFD 的范围里, 并指出这个字符包含多少个字节. 多字节串的其余字节都在 0x80 到 0xBF 范围里. 这使得重新同步非常容易, 并使编码无国界, 且很少受丢失字节的影响.
• 可以编入所有可能的 2³¹个 UCS 代码
• UTF-8 编码字符理论上可以最多到 6 个字节长, 然而 16 位 BMP 字符最多只用到 3 字节长.
• Bigendian UCS-4 字节串的排列顺序是预定的.
• 字节 0xFE 和 0xFF 在 UTF-8 编码中从未用到.

下列字节串用来表示一个字符. 用到哪个串取决于该字符在 Unicode 中的序号.

U-00000000 - U-0000007F:	0xxxxxxx
U-00000080 - U-000007FF:	110xxxxx 10xxxxxx
U-00000800 - U-0000FFFF:	1110xxxx 10xxxxxx 10xxxxxx
U-00010000 - U-001FFFFF:	11110xxx 10xxxxxx 10xxxxxx 10xxxxxx
U-00200000 - U-03FFFFFF:	111110xx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx
U-04000000 - U-7FFFFFFF:	1111110x 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx

xxx 的位置由字符编码数的二进制表示的位填入. 越靠右的 x 具有越少的特殊意义. 只用最短的那个足够表达一个字符编码数的多字节串. 注意在多字节串中, 第一个字节的开头"1"的数目就是整个串中字节的数目.

例如: Unicode 字符 U+00A9 = 1010 1001 (版权符号) 在 UTF-8 里的编码为:

11000010 10101001 = 0xC2 0xA9

而字符 U+2260 = 0010 0010 0110 0000 (不等于) 编码为:

11100010 10001001 10100000 = 0xE2 0x89 0xA0

这种编码的官方名字拼写为 UTF-8, 其中 UTF 代表 UCS Transformation Format. 请勿在任何文档中用其他名字 (比如 utf8 或 UTF_8) 来表示 UTF-8, 当然除非你指的是一个变量名而不是这种编码本身.

//你看不懂这一段的话请看utf-8官方解释：

What is UTF-8?

UTF-8 stands for Unicode Transformation Format-8. It is an octet (8-bit) lossless encoding of Unicode characters.

UTF-8 encodes each Unicode character as a variable number of 1 to 4 octets, where the number of octets depends on the integer value assigned to the Unicode character. It is an efficient encoding of Unicode documents that use mostly US-ASCII characters because it represents each character in the range U+0000 through U+007F as a single octet. UTF-8 is the default encoding for XML.

所以，其实说白了。unicode仅仅是表示了字符的编码表，但是没有指定如何编码，而UTF-8是一种unicode的八字节编码格式。

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

好了，有了预备知识之后，就可以去了解如何解决这种问题了。给了我最大启发的就是下面这两篇文章了：


　　设想一下如何设计一个全球的论坛系统：可以让中文和日文的用户都可以方便的浏览发表呢？在数据中间处理阶段应该以那种字符集存储呢？答案很简 单：UniCode。以前很多文章都有关于如何设计一个国际化界面的介绍，只是应用的本地化界面输出，但很少提及数据在中间处理过程中如何适应国际化。

　　输入和存储阶段就用UniCode方式进行处理和存储，以方便应用以后的国际化。GOOGLE的设计就是一个非常好的国际化应用榜样，我以GOOGLE搜索引擎的国际化支持为例说明如何实现国际化应用的设计。

GOOGLE用户经常有这样的感觉：

1. 为什么我第一次去GOOGLE，出现的就是中文的界面？
2. 为什么在所有网站中查中文：有时候还会匹配到日文网站的结果？比如：就以"google 秘密"这个查询为例：我们在输入框输入"google 秘密"
   http://www.google.com/search?hl=zh-CN&newwindow=1&q=google+%C3%D8%C3%DC&btnG=Google%CB%D1%CB%F7&lr=

首先我将GOOGLE对查询的处理流程简单的说明如下：

1. 客户端浏览器输入；
2. 查询字符串按客户端系统编码方式（GBK）转换成字节流，并URL Encode后传给GOOGLE；
3. GOOLGE将输入的字符串URL Decode后，按照客户端的系统编码方式将这个字符串（字节串）解码成UniCode
4. 查询过程，完全是基于UniCode的匹配过程，比如对于“中文”这2个字在简体繁体中文和日文里都有，因此无论是何种语言的页面包含这2个字的页面都能匹配上。
5. 结果集输出：将查询结果集的内容（UNICODE）按客户端系统编码方式（GBK）“编码”成的字节流，返回给浏览器

具体说明：

• GOOGLE如何识别出浏览器使用的“界面语言”：GOOGLE获得这个查询字符串的同时，一般会根据hl=zh-CN这个参数， 知道了客户端使用的字符集编码方式，如果用户第一次访问：GOOGLE会根据浏览器的发送的请求中包含的Accept language: zh_cn这个头信息来判别，这就是为什么现在很多用户第一次去GOOGLE的时候它就能自动识别出来的原因。这个参数在之后的查询和翻页过程中通过 cookie保存，并通过get方式一直传递给GOOGLE（因此你也可以使用使用偏好设置界面语言），从而可靠地识别出客户端的编码方式。
• GOOGLE如何查询：也许从URL上你可以看到：传过去的“秘密”这个查询实际上是%C3%D8%C3%DC=>"秘密"这2个字按GBK（WINDOWS客户端缺省的编码方式）编码方式的4个字节然后再URLEncode后的形式（关于中文编码方式请参考：汉字的编码方式），GOOGLE 将查询字符串按这个编码方式解码并转成UniCode，然后用这个UniCode编码方式的字符串进行内部的查询操作。而任何语言的页面都是先转换成 UniCode后存储在GOOGLE的数据索引库里的。在UniCode中日文和中文写法一样的字，用的是同样的编码。因此，如果你没有指定语言过滤的话，日文网页的结果就首先被命中了；因此，对于中文客户端的查询：如果相应字符在UniCode中和繁体，日文映射的字一样，就可以匹配到相应的日文网页，繁体中文网页...，GOOGLE的查询结果也首先是UniCode的，最后将UniCode结果按照客户端的编码方式转换成字节流，返回到客户端。

从以上的分析中我们可以看出：UniCode非常漂亮的解决了应用的国际化问题。对于应用前端来说，剩下的工作就是根据本地编码环境进行本地化的过程了。

1. 数据从输入的开始，就全部先转换成UniCode，然后再进行处理，并按照UniCode方式集中存储(UniCode inside)
2. 数据输出过程中，只是在最后输出到客户端的时候，按照客户端的本地化设置将UniCode数据转换成本地字符集，并配以相应语言/字符的界面(Localization outside)

　　如果应用的开发只是满足于在国内市场自给自足，“汉化”的思路的大量出现是很自然的。但要是把“汉化”比作UCDOS和RichWin的话，那么这种汉化方式迟早要被内核汉化的WIN95淘汰的。毕竟核心级别对国际化的支持才是一个真正简化前端应用设计、通用的解决方案。Microsoft和Sun等国际化大公司的产品从一开始就是为全球市场设计的，因此对国际化的支持一致非常重视。相比之下国内软件行业对相应国际标准显然重视不足，也很少积极地参 与相关标准制定。
　　转自：http://www.chedong.com/tech/unicode_java.html#google

－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
据说Google修改过一次它的编码处理方式：

　　GOOGLE的国际化做得很好。我们知道，你在www.google.com里面输入一个检索词，然后便会生成一个HTTP的GET请求。这个请求一般有几个参数，以前的http://www.google.com/search?q=%s就是最简单的一个，%s就是用来代替你输入的值的。但GOOGLE是一个面对全球服务的站点。它收到请求后会解释q的值。如果大家写过JSP或者JAVA程序，就会经 常陪到getParameter得到的中文是乱码。这里面就是一个编码问题。浏览器的地址栏内的URL，一切非正常字符（A- z,0-9,:,.等)都会进行编码（Encode，一个%号，然后加上它的ASCII内码，一个中文一般会编码成为两个，如“中 文”两个字会编码为：%D6%D0%CE%C4，然后程序收到请求后会进行相应的解码。
　　GOOGLE近期改进了它的编码方案，即是在生成URL的时候，由客户端按照指定的编码进行Encode,查看 www.google.com主页的源文件，你会发觉encodeURIComponent这个Javascript的函数。默认情况下，会用Javascript的 功能，把输入的检索词进行UTF-8编码，“中文”两个字就会编码成：%E4%B8%AD%E6%96%87，一共六个字节。这时如果还是按照四个字节进行解码，就会出错，也就是乱码。可以对比默认情况下的编码，是四个字节。具体关于字符编码的内容，就不在这里讨论。

再来看Google配置检索式的时候的几个参数：

[*]ACTION地址： http://www.google.com/search?
[*]q 检索的词，即你在输入框内输入的内容，会进行URL Encode编码
[*]lr 检索范围。如“lr=”表示检索所有的网站，lr=lang_zh-CN表示检索中文简体，lr=lang_zh-CN|lang_zh-TW表示 中文网页（简繁）
[*]ie 指示浏览器URL的编码，Google会将q的值按照这个编码来进行解码（这个最重要）
[*]oe Outlook的编码？？（这个参数暂不清楚什么意思，目前对检索没有影响，直接给一个值，或者不要也行


这时就可以按需进行组合了，名和值之前为“=”，每个之间以“&”进行连接
如：http://www.google.com/search?q=%s&ie=GB2312&lr=lang_zh-CN
意思为：浏览器的URL编码为GB2312，检索范围为“中文网页”

http://www.google.com/search?q=%s&ie=UTF-8&lr=lang_zh-CN
意思为：浏览器的URL编码为UTF-8，检索范围为“简体中文网页”

如果是检索图像，把search换成images就行了，其它不变。
http://images.google.com/images?q=%s&ie=UTF-8&lr=lang_zh-CN

//关于这篇文章的内容，我们其实可以测试一下就能了解了。在google搜索两个中文，之后添加一个&ie=gb2312结果就会出现乱码。


================================================================================待续。。。