基础入门－JAVA字符集详解

建议 
1、数据库编码为GB2312 
2、web容器编码为UTF-8 
3、页面编码为UTF-8 
4、增加一个过滤器，编码为UTF-8（若为struts2则不用） 
5、请求为POST 

对于URL传参，需要修改Web服务器设置或者增加过滤器。

 

1. 概述

本文主要包括以下几个方面：编码基本知识，java，系统软件，url，工具软件等。

在下面的描述中，将以"中文"两个字为例，经查表可以知道其GB2312编码是"d6d0 cec4"，Unicode编码为"4e2d 6587"，UTF编码就是"e4b8ad e69687"。注意，这两个字没有iso8859-1编码，但可以用iso8859-1编码来"表示"。

2. 编码基本知识

最早的编码是iso8859-1，和ascii编码相似。但为了方便表示各种各样的语言，逐渐出现了很多标准编码，重要的有如下几个。

2.1. iso8859-1

属于单字节编码，最多能表示的字符范围是0-255，应用于英文系列。比如，字母"a"的编码为0x61=97。

很明显，iso8859-1编码表示的字符范围很窄，无法表示中文字符。但是，由于是单字节编码，和计算机最基础的表示单位一致，所以很多时候，仍旧使用iso8859-1编码来表示。而且在很多协议上，默认使用该编码。比如，虽然"中文"两个字不存在iso8859-1编码，以gb2312编码为例，应该是"d6d0 cec4"两个字符，使用iso8859-1编码的时候则将它拆开为4个字节来表示："d6 d0 ce c4"（事实上，在进行存储的时候，也是以字节为单位处理的）。而如果是UTF编码，则是6个字节"e4 b8 ad e6 96 87"。很明显，这种表示方法还需要以另一种编码为基础。

2.2. GB2312/GBK

这就是汉子的国标码，专门用来表示汉字，是双字节编码，而英文字母和iso8859-1一致（兼容iso8859-1编码）。其中gbk编码能够用来同时表示繁体字和简体字，而gb2312只能表示简体字，gbk是兼容gb2312编码的。

2.3. unicode

这是最统一的编码，可以用来表示所有语言的字符，而且是定长双字节（也有四字节的）编码，包括英文字母在内。所以可以说它是不兼容iso8859-1编码的，也不兼容任何编码。不过，相对于iso8859-1编码来说，uniocode编码只是在前面增加了一个0字节，比如字母"a"为"00 61"。

需要说明的是，定长编码便于计算机处理（注意GB2312/GBK不是定长编码），而unicode又可以用来表示所有字符，所以在很多软件内部是使用unicode编码来处理的，比如java。

2.4. UTF

考虑到unicode编码不兼容iso8859-1编码，而且容易占用更多的空间：因为对于英文字母，unicode也需要两个字节来表示。所以unicode不便于传输和存储。因此而产生了utf编码，utf编码兼容iso8859-1编码，同时也可以用来表示所有语言的字符，不过，utf编码是不定长编码，每一个字符的长度从1-6个字节不等。另外，utf编码自带简单的校验功能。一般来讲，英文字母都是用一个字节表示，而汉字使用三个字节。

注意，虽然说utf是为了使用更少的空间而使用的，但那只是相对于unicode编码来说，如果已经知道是汉字，则使用GB2312/GBK无疑是最节省的。不过另一方面，值得说明的是，虽然utf编码对汉字使用3个字节，但即使对于汉字网页，utf编码也会比unicode编码节省，因为网页中包含了很多的英文字符。

3. java对字符的处理

在java应用软件中，会有多处涉及到字符集编码，有些地方需要进行正确的设置，有些地方需要进行一定程度的处理。

3.1. getBytes(charset)

这是java字符串处理的一个标准函数，其作用是将字符串所表示的字符按照charset编码，并以字节方式表示。注意字符串在java内存中总是按unicode编码存储的。比如"中文"，正常情况下（即没有错误的时候）存储为"4e2d 6587"，如果charset为"gbk"，则被编码为"d6d0 cec4"，然后返回字节"d6 d0 ce c4"。如果charset为"utf8"则最后是"e4 b8 ad e6 96 87"。如果是"iso8859-1"，则由于无法编码，最后返回 "3f 3f"（两个问号）。

3.2. new String(charset)

这是java字符串处理的另一个标准函数，和上一个函数的作用相反，将字节数组按照charset编码进行组合识别，最后转换为unicode存储。参考上述getBytes的例子，"gbk" 和"utf8"都可以得出正确的结果"4e2d 6587"，但iso8859-1最后变成了"003f 003f"（两个问号）。

因为utf8可以用来表示/编码所有字符，所以new String( str.getBytes( "utf8" ), "utf8" ) === str，即完全可逆。

3.3. setCharacterEncoding()

该函数用来设置http请求或者相应的编码。

对于request，是指提交内容的编码，指定后可以通过getParameter()则直接获得正确的字符串，如果不指定，则默认使用iso8859-1编码，需要进一步处理。参见下述"表单输入"。值得注意的是在执行setCharacterEncoding()之前，不能执行任何getParameter()。java doc上说明：This method must be called prior to reading request parameters or reading input using getReader()。而且，该指定只对POST方法有效，对GET方法无效。分析原因，应该是在执行第一个getParameter()的时候，java将会按照编码分析所有的提交内容，而后续的getParameter()不再进行分析，所以setCharacterEncoding()无效。而对于GET方法提交表单是，提交的内容在URL中，一开始就已经按照编码分析所有的提交内容，setCharacterEncoding()自然就无效。

对于response，则是指定输出内容的编码，同时，该设置会传递给浏览器，告诉浏览器输出内容所采用的编码。

3.4. 处理过程

下面分析两个有代表性的例子，说明java对编码有关问题的处理方法。

3.4.1. 表单输入

User input *(gbk:d6d0 cec4) browser *(gbk:d6d0 cec4) web server iso8859-1(00d6 00d 000ce 00c4) class，需要在class中进行处理：getbytes("iso8859-1")为d6 d0 ce c4，new String("gbk")为d6d0 cec4，内存中以unicode编码则为4e2d 6587。

l 用户输入的编码方式和页面指定的编码有关，也和用户的操作系统有关，所以是不确定的，上例以gbk为例。

从browser到web server，可以在表单中指定提交内容时使用的字符集，否则会使用页面指定的编码。而如果在url中直接用?的方式输入参数，则其编码往往是操作系统本身的编码，因为这时和页面无关。上述仍旧以gbk编码为例。

Web server接收到的是字节流，默认时（getParameter）会以iso8859-1编码处理之，结果是不正确的，所以需要进行处理。但如果预先设置了编码（通过request. setCharacterEncoding ()），则能够直接获取到正确的结果。

在页面中指定编码是个好习惯，否则可能失去控制，无法指定正确的编码。

 

 

 

关键字： Unicode, Character Set, 字符集, UTF-8, ANSI, ASCII, UTF-7 

原文标题： The Absolute Minimum Every Software Developer Absolutely, Positively Must Know

About Unicode and Character Sets（No Excuses!）

原文链接： www.joelonsoftware.com/printerFriendly/articles/Unicode.html

作者： Joel Spolsky

翻译、摘要： 木野狐（ChenRong2003[at]hotmail.com）

日期： 2004-11-29 

 

 

 

ASCII 码

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

7 位（00～7F）。 32 ~ 127 表示字符。32 是空格， 32 以下是控制字符（不可见）。

第8位没有被使用。全世界很多人同时对这个位的含义发展了不同的用处。比如 IBM PC 中的 OEM 字符集。

最后就 128 位以下的用处达成共识，制定了 ASCII 标准。

而 128 位以上的可能有不同的解释，这些不同的解释就叫做 code pages.

甚至有用于在同一台电脑上解释多种语言的 code page.

 

同时，在亚洲发生了更加疯狂的事情。亚洲语言的字符集通常数以千计， 8 位已经不足以表达，这通常用一种

很凌乱的，叫做 DBCS（双字节字符集,double byte character set） 的系统来解决。

这种系统中，有些字符占用 1 字节，有些 2 字节。这样一来，在字符串中向前解析很容易，而倒退却很麻烦。

程序员们被建议，不要使用 s++ 或 s-- 来前进和后退，而使用一些函数，比如 Windows 的 AnsiNext 和

AnsiPrev. 因为这些函数知道是怎么回事。

 

这些不同的假设（code page）在单个的机器上没有问题。而随着 Internet 的发展，字符串要从一个机器上移到

另一个机器上，这就产生了问题。于是， Unicode 出现了。

 

Unicode

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

Unicode 是一个勇敢的成就。它把在这个星球上的每一个合理的文字系统整合成了一个单一的字符集。

很多人还存在这样的误解： Unicode 仅仅是 16 位的这么简单，每个字符占 16 位，所以一共有 65536 个可能的字符。

然而，这是错误的。不过不要紧，因为这是大部分人都会犯的一个普遍的错误。

 

实际上，Unicode 理解字符的方式是截然不同的，而这是我们必须了解的。

到目前为止，我们都曾经认为：一个字符对应到一些在磁盘上或内存中储存的位（bits）. 如： A -> 0100 0001

而在 Unicode 中， 一个字符实际上对应一种叫做 code point 的东西。

比如 A 这个字符，是抽象的（原文：platonic,柏拉图式的，理想的）一个概念。

无论是 Times New Roman 或者 Helvetica 或者其他的什么字体中，都代表同一个字符。但是它和小写的字母 a 不同。

但是在其他的语言，比如希伯莱语（Hebrew） 或者德语（German）, 阿拉伯语（Arabian） 中，同一个字母的不同的字形代表的含义是否

相同，是有争议的。经过长时间的争论，这些也终于被确定了。

 

每一个字母表中的每一个抽象的字母，都被赋予了一个数字，比如 U+0645. 这个叫做 code point.

U+ 表示： Unicode, 数字是 16 进制的。

你可以通过 charmap 命令来查看所有这些编码。（Windows 2000/XP 中）. 或者访问 Unicode 的网站（http://www.unicode.org）

Unicode 中 code point 的数字的大小是没有限制的，而且也早就超过了 65535. 所以不是每个字符都能存储在两个字节中。

那么，一个字符串 "Hello"， 在 Unicode 中会表示成 5 个 code points :

U+0048 U+0065 U+006C U+006C U+006F

只不过是一些数字。但我们现在还没有提到如何在磁盘或者 Email 中表示这些信息，这就是我们下面要提到的编码（Encoding） 干的事情。

 

Encodings （编码）

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

最初的 Unicode Encoding, 使用两个字节表示一个字符。那么 "Hello" 表示为：

00 48 00 65 00 6C 00 6C 00 6F

实际上，还有一种表示方式：

48 00 65 00 6C 00 6C 00 6F 00

到底高位字节在前还是低位字节在前面，是两种不同的模式。这要看特定的 CPU 在何种模式下工作的更快。 所以这两种都有。

这就有了两种不同的 Unicode 表示方式了，为了区分，人们又采用了一种奇异的方式：

在每一个 Unicode 字符串的前面，加上 FEFF （这称为 Unicode 字节顺序标志，Unicode Byte Order Mark）.

如果你交换高位和低位次序，那么会加上一个 FFFE. 这样，读这个字符串的人才知道要对每两个相邻的字节进行交换。

但在最初的时候，并不是每一个 Unicode 字符串都有这个标志的。

 

这看起来很不错。可程序员们开始抱怨了，“看看那些零！”。因为有些是美国人，他们使用英语。而英语中很少需要使用 U+00FF 以上的

字符， 有些人无法忍受采用双倍的存储空间来存储每个字符。

基于这些原因，很多人决定忽视 Unicode, 而同时，事情变得更糟了。

 

然后人们制定了 UTF-8. UTF-8 是用于保存 Unicode code points 的另一套系统。

每一个 U+ 数字，在内存中占用 8 bit. 在 UTF-8 中，任何一个 0~127 的 code point 占用一个字节。

只有 128 以及更大的才占用 2, 3, 直到 6 个字节。

具体如下图所示：

 

16进制的最小的数 16进制的最大的数 内存中的字节序列

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

00000000 0000007F 0vvvvvvv

00000080 000007FF 110vvvvv 10vvvvvv

00000800 0000FFFF 1110vvvv 10vvvvvv 10vvvvvv

00010000 001FFFFF 11110vvv 10vvvvvv 10vvvvvv 10vvvvvv

00200000 03FFFFFF 111110vv 10vvvvvv 10vvvvvv 10vvvvvv 10vvvvvv

04000000 7FFFFFFF 1111110v 10vvvvvv 10vvvvvv 10vvvvvv 10vvvvvv 10vvvvvv

 

这看起来很不错，其中的英文字符和 ASCII 中一样。所以美国人根本没意识到有什么错误。只有世界上的其他国家需要使用高位的字节。

特别的，"Hello" 这个字符串，Unicode code point 为 U+0048 U+0065 U+006C U+006C U+006F， 会被存储为 48 65 6C 6C 6F。

和 ASCII, ANSI, 以及在这个星球上的任何一个 OEM 的字符集中表示的含义都一样。

现在，如果你需要表示重音的字符，或者希腊语，你需要使用多个字节来表示一个 code point. 但美国人不会介意这些。

（UTF-8 还有一个好处就是，老的字符串处理程序使用一个为 0 的字节来表示 null-terminator, 不会截断字符串）

 

到目前为止已经介绍了三种 Unicode 的表示方法：

 

传统的双字节表示方法， 称为 UCS-2（因为有 2 个字节） 或者 UTF-16（因为有 16 个位）

而且你还要搞清楚是高位在前的，还是高位在后的 UCS-2.

 

还有一种就是新的 UTF-8. 如果你的程序只使用英文的话，它仍然会工作正常。

 

实际上还有一堆的其他办法对 Unicode 进行编码：

有 UTF-7，这种编码方式大部分和 UTF-8 相同，但保证高位一定为 0. 

所以如果你必须通过某种 Email 系统传送 Unicode，这些系统认为 7 位足够了，那使用 UTF-7 会正常。

还有 UCS-4, 储存每一个 code point 为 4 个字节。它的优点是每一个字符都保存为同样长的。但很明显，缺点是浪费太多存储空间了。

 

所以，现在你思考问题要把每一个字符想象成抽象的一个 unicode code point. 而它们同样可以使用任何旧的方式编码。

举例来说，你可以把 Unicode 字符串 Hello （U+0048 U+0065 U+006C U+006C U+006F） 编码（encode）为

ASCII, 或者古老的 OEM 希腊语编码，或者希柏莱 ANSI 编码，等等。而有些字符串不能显示！

也就是说，假如你要表示一个在某个编码中没有对应的 Unicode code point, 通常会显示为一个 ? 或者一个白色的小方框。

 

英文常用的一些编码有， Windows-1252（Windows 9x 标准 for 西欧语言）

以及 ISO-8859-1, aka Latin-1（对任何西欧语言也有效）

如果用这些编码来尝试存储俄文字符，你会得到一堆的 ?

 

UTF 7, 8, 16 以及 32 都有一个优点，能够正确的存储任何的 code point.

 

最简单，也是最重要的几个概念

====================================================================

一个字符串不指定它使用什么编码是没有意义的。

再也不要假定， “纯”文本（plain text） 是 ASCII.

没有 “纯文本” 这个东西。

 

如果你有一个字符串，在内存中，在文件中，或者在 Email 消息里，你必须知道它的编码是什么。否则你无法正确的解释或者显示给用户。

所有的诸如 “我的网页不能正常显示了”，或者 ”Email 消息不能正常显示了“ 之类的愚蠢问题， 都是因为， 没有告诉你到底是使用的那种编码，

UTF-8 还是 ASCII 还是 ISO 8859-1 或者 Windows 1252 ?? 那么自然无法正常的解释和显示，甚至不知道字符串该在哪里结束。

 

那么如何保留这样的编码标志，来表示字符串的编码？ 有一些基本的办法。

比如对于 Email 来说，在表单的 header 中加上：

 

Content-Type:text/plain;charset="UTF-8"

 

对于 Web 页面来说，原来的做法是， Web 服务器随着 web 页面本身一起，发送一个类似于 Content-Type 的 http header.

（不是在 HTML 里面，而是作为一个 response header 在 HTML 页之前发送）

 

这样做有一个问题。如果你的 Web 服务器同时有多个站点，站点由多个不同的人用不同的语言开发的程序混在一起。那么 Web 服务器将无从得知，

每一个文件是用什么编码方式写的。这样也就无法发送正确的 Content-Type header.

如果你能够在每一个 HTML 文件中记录 Content-Type 信息，那么就很方便了。可这念头似乎也很疯狂，因为你还没有知道用什么编码方式去

读取这个文件，又怎么能读出编码信息呢？

幸好，几乎每一种编码中，对 32~127 的字符都解释的相同。所以你可以在每一个 html 文件中这么写：

 

<html>

<head>

<meta http-equiv="Content-Type" content="text/html;charset=utf-8">

 

但是要注意， 这个 meta 标签必须放在 head 中靠前面的位置才能保证不会出问题。 因为 Web 服务器读到这里的时候，就会停止解析，

然后用读到的这个编码方式重新解析页面。

 

那么，作为 Web 浏览器来说，如果没有在 meta 标签中或者 http headers 中发现 Content-Type, 会怎么样呢？

IE 是这么做的：

先尝试去猜，根据特定的字节出现在各种语言的典型的编码中的频率。

如果编码设定不正常，用户可以通过 View|Encoding 菜单来尝试不同的编码方式。（当然，不是每个人都知道该这样做）

 

在 VB, COM, Windows NT/2000/XP 中，默认的字符串类型是 UCS-2（2字节）的。

在 C++ 代码中， 我们可以定义字符串为 wchar_t（wide char），同时用 wcs 系列的函数代替 str 系列的函数。

如 wcscat, wcslen, 而不是 strcat, strlen.

在 C 代码中，要创建 UCS-2 字符串的话，只要在前面加一个 "L", 如 L"Hello"

 

对于 Web 页面，最好统一为使用 UTF-8 编码。 这个编码已经被各种 web 浏览器支持了很多年了。