Hello Unicode —— JAVA的中文处理学习笔记

不知道你有没有这样的感受：为什么PHP很少有乱码问题而用Java做WEB应用却这么麻烦呢？为什么在Google上能用简体中文查到繁体中文，甚至日文的结果？而且用Google的时候发现它居然能自动根据我使用浏览器的语言选择自动调出中文界面？

很多国际化应用的让我理解了这么一个道理：Unicode是为更方便的做国际化应用设计的，而Java核心的字符是基于UNICODE的，这一机制为应用提供了对中文“字”的控制（而不是字节）。但如果不仔细理解其中的规范，这种自由反而会成为累赘，从而导致更多的乱码问题：

关于字符集的一些基本概念；
试验1：显示系统的环境设置和支持的编码方式；
试验2：系统缺省编码方式对Java应用的输入输出影响；
试验3：在WEB应用中输出和输出中的字符集问题；

关于字符集的准备知识：ISO-8859-1 GB2312 BIG5 GBK GB18030 UNICODE 为什么会有这么多字符集编码方式？

注意：以下说明不是严格定义，一些比喻仅作为方便理解使用。

假设一个字符就是棋盘上的一个棋子，有其固定的坐标，如果需要区别所有的字符，就需要有足够的棋格容纳不同的“字符”。　

英文和欧洲其他语言的单字节字符集(SingleByte Charsets)：

首先对于ISO-8859系列的字符集都想象成一个：2^8 = 16 * 16 = 256个格子的棋盘，这样所有的西文字符（英文）用这样一个16×16的坐标系就基本可以覆盖全了。而英文实际上只用其中小于128(\x80)的部分就够了。利用大于128部分的空间的不同定义规则形成了真对其他欧洲语言的扩展字符集：ISO-8859-2 ISO-8859-4等……

ISO-8859-1：英文（低128格） + 其他西欧字符（高128格）
ISO-8859-7：英文（低128格） + 希腊字符（高128格）
其他语言：英文（低128格） + 其他单字节字符集（高128格）

GB2312 BIG5 SJIS等多字节字符集（MultiByte Charsets）：

对于亚洲语言来说：汉字这么多，用这么一个256格的小棋盘肯定放不下，所以要区别成千上万的汉字解决办法就是用2个字节（坐标）来定位一个“字”在棋盘上的位置，将以上规则做一个扩展：

如果第1个字符是小于128(\x80)的仍和英文字符集编码方式保持兼容；
如果第1个字符是大于128(\x80)的，就当成是汉字的第1个字节，这个自己和后面紧跟的1个字节组成一个汉字；

其结果相当于在位于128以上的小棋格里每个小棋格又划分出了一个16×16的小棋盘。这样一个棋盘中的格子数（可能容纳的字符数）就变成了128 + 128 * 256。按照类似的方式有了简体中文的GB2312标准，繁体中文的BIG5字符集和日文的SJIS字符集等，GB2312字符集包含大约有六仟多个常用简体汉字。

简体中文：英文部分（兼容ASCII）+ 简体中文字符（GB2312编码）
日文SJIS：英文部分（兼容ASCII）+ 日文字符（SJIS编码）
繁体中文：英文部分（兼容ASCII）+ 繁体中文字符（BIG5编码）

由此可以看出，所有这些从ASCII扩展式的编码方式中：英文部分都是兼容的，但扩展部分的编码方式是不兼容的，虽然很多字在3种体系中写法一致（比如“中文”这2个字）但在相应字符集中的坐标不一致，所以GB2312编写的页面用BIG5看就变得面目全非了。而且有时候经常在浏览其他非英语国家的页面时（比如包含有德语的人名时）经常出现奇怪的汉字，其实就是扩展位的编码冲突造成的。

我把GBK和GB18030理解成一个小UNICODE：GBK字符集是GB2312的扩展(K)，GBK里大约有贰万玖仟多个字符，除了保持和GB2312兼容外，繁体中文字，甚至连日文的假名字符也能显示。而GB18030-2000则是一个更复杂的字符集，采用变长字节的编码方式，能够支持更多的字符。关于汉字的编码方式比较详细的定义规范可以参考： http://www.unihan.com.cn/cjk/ana17.htm

ASCII（英文） ==> 西欧文字 ==> 东欧字符集（俄文，希腊语等） ==> 东亚字符集（GB2312 BIG5 SJIS等）==> 扩展字符集GBK GB18030这个发展过程基本上也反映了字符集标准的发展过程，但这么随着时间的推移，尤其是互联网让跨语言的信息的交互变得越来越多的时候，太多多针对本地语言的编码标准的出现导致一个应用程序的国际化变得成本非常高。尤其是你要编写一个同时包含法文和简体中文的文档，这时候一般都会想到要是用一个通用的字符集能够显示所有语言的所有文字就好了，而且这样做应用也能够比较方便的国际化，为了达到这个目标，即使应用牺牲一些空间和程序效率也是非常值得的。UNICODE就是这样一个通用的解决方案。

UNICODE双字节字符集

所以你可以把UNICODE想象成这样：让所有的字符（包括英文）都用2个字节（2个8位）表示，这样就有了一个2^(8*2) = 256 * 256 = 65536个格子的大棋盘。在这个棋盘中，这样中（简繁）日韩（还包括越南）文字作为CJK字符集都放在一定的区位内，为了减少重复，各种语言中写法一样的字共享一个“棋格”。

Unicode：(DoubleByte Charsets)

西欧（蓝）、英文（绿）、CJK（黄：中、日、韩）、其他语言（青）

什么还要有UTF-8？毕竟互联网70％以上的信息仍然是英文。如果连英文都用2个字节存取(UCS-2)，空间浪费不就太多了？所谓UTF-8就是这样一个为了提高英文存取效率的字符集转换格式：Unicode Transformation Form 8-bit form。用UTF-8，UNICODE的2字节字符用变长个（1－3个字节）表示：

对英文，仍然和ASCII一样用1个字节表示，这个字节的值小于128(\x80)；
对其他语言的用一个值位于128-256之间的字节开始，再加后面紧跟的2个字节表示，一个字符一共是3个字节；

因此，在应用中程序处理过程中所有字符都是16位（双字节），但在存取转换成字节流时使用UTF-8格式转换，对于英文字符来说和原来用ASCII方式存取时相比大小仍然是一样的，而对中文来说和原来的GB2312编码方式相比，大小为：(3字节/2字节)=1.5倍

小节：

假设英文字符集是一个16×16的棋盘，么其他语言的字符集就是把高位区重新分割的(> 128)的中等棋盘，多种字符集之间互不兼容而UNICODE本身就相当于一个256×256的大棋盘，通过一定规则将英文和其他所有语言的字符都包含在内。

试验1：操作系统语言环境设置对Java应用缺省编码方式的影响

为了了解Java应用的编码处理的机制，首先要了解操作系统对JVM缺省编码方式的影响，因此我做了一个Env.java，用于打印显示不同系统下JVM的属性和系统支持的LOCALE。程序很简单：

/*
 * Copyright (c) 2002 Email: chedongATbigfoot.com/chedongATchedong.com
 * $Id: hello_unicode.html,v 1.6 2003/11/09 07:57:11 chedong Exp $
 */

import java.util.*;
import java.text.*;

/**
 * 目的：
 *     显示环境变量和JVM的缺省属性
 * 输入：无
 * 输出：
 *     1 支持的LOCALE
 *     2 JVM的缺省属性
 */

public class Env {
    /**
     *  main entrance
     */
    public static void main(String[] args) {
    	
        System.out.println("Hello, it's: " +  new Date());

        //print available locales
        Locale list[] = DateFormat.getAvailableLocales();
        System.out.println("======System available locales:======== ");
        for (int i = 0; i < list.length; i++) {
            System.out.println(list[i].toString() + "\t" + list[i].getDisplayName());
        }

        //print JVM default properties
        System.out.println("======System property======== ");
        System.getProperties().list(System.out);
    }
}

最需要注意的是JVM的file.encoding属性，这个属性确定了JVM的缺省的编码/解码方式：从而影响应用中所有字节流==>字符流的解码方式，字符流==>字节流的编码方式。

LINUX下的LOCALE可以通过 LANG=zh_CN; LC_ALL=zh_CN.GBK; export LANG LC_ALL 设置。locale 命令可以显示系统当前的环境设置 Windows的LOCALE可以通过控制面板==>区域设置设置实现

GNU/Linux 2.4.x (J2SE1.3.1) LANG=en_US LC_ALL=en_US

Hello, it's: Tue Jul 30 11:05:44 CST 2002
======System available locales:======== 
en English
en_US English (United States)
ar Arabic
...
zh Chinese
zh_CN Chinese (China)
zh_HK Chinese (Hong Kong)
zh_TW Chinese (Taiwan)
======System property======== 
-- listing properties --
java.runtime.name=Java(TM) 2 Runtime Environment, Stand...
...
file.encoding=ISO-8859-1
...
user.language=en
...
user.region=US
...

GNU/Linux 2.4.x (J2SE1.3.1) LANG=zh_CN LC_ALL=zh_CN.GBK

Hello, it's: Tue Jul 30 11:07:34 CST 2002
======System available locales:======== 
en 英文
en_US 英文 (美国)
...
zh 中文
zh_CN 中文 (中国)
zh_HK 中文 (香港)
zh_TW 中文 (台湾)
======System property======== 
-- listing properties --
...
file.encoding=GBK
...
user.language=zh
...
user.region=CN
...

Windows 2000(J2SE1.3.0) 区域设置:中国中文

Hello, it's: Tue Jul 30 11:49:36 CST 2002
======System available locales:======== 
...
zh 中文
zh_CN 中文 (中华人民共和国)
zh_HK 中文 (香港)
zh_TW 中文 (台湾)
======System property======== 
-- listing properties --
...
file.encoding=GBK
...
user.language=zh
...
user.region=CN
...

Windows 2000(J2SE1.3.0) 区域设置:英国英文

Hello, it's: Tue Jul 30 11:53:27 CST 2002
======System available locales:======== 
...
zh Chinese
zh_CN Chinese (China)
zh_HK Chinese (Hong Kong)
zh_TW Chinese (Taiwan)
======System property======== 
-- listing properties --
...
file.encoding=Cp1252
...
user.language=en
...
user.region=GB
...

JVM的缺省编码方式由系统的“本地语言环境”设置确定，和操作系统的类型无关。所以当设置成相同的LOCALE时，Linux和Windows下的缺省编码方式是没有区别的（可以认为cp1252=ISO-8859-1都是一样的西文编码方式，只包含255以下的拉丁字符），因此后面的测试2我只列出了GNU/Linux下LOCALE分别设置成zh_CN和en_US的测试结果输出。以下测试如果在Windows下分别按照不同的区域和字符集设置后试验的输出是一样的。

试验2：Java的输入输出过程中的字节流到字符流的转换过程

通过这个HelloUnicode.java程序，演示说明"Hello world 世界你好"这个字符串（16个字符）在不同缺省系统编码方式下的处理效果。在编码/解码的每个步骤之后，都打印出了相应字符串每个字符(Charactor)的byte值，short值和所在的UNICODE区间。

环境：LANG=en_US LC_ALL=en_US

========testing1: write hello world to files========
[test 1-1]: with system default encoding=ISO-8859-1
string=Hello world 世界你好     length=20
char[0]='H'     byte=72 \u48    short=72 \u48   BASIC_LATIN
...
char[12]='?    byte=-54 \uFFFFFFCA     short=202 \uCA  LATIN_1_SUPPLEMENT
...
char[19]='?    byte=-61 \uFFFFFFC3     short=195 \uC3  LATIN_1_SUPPLEMENT

第1步：在英文编码环境下，虽然屏幕上正确的显示了中文，但实际上它打印的是“半个”汉字，将结果写入第1个文件 hello.orig.html

[test 1-2]: getBytes with platform default encoding and decoding as gb2312:
string=Hello world ???? length=16
...
char[12]='?'    byte=22 \u16    short=19990 \u4E16      CJK_UNIFIED_IDEOGRAPHS
char[13]='?'    byte=76 \u4C    short=30028 \u754C      CJK_UNIFIED_IDEOGRAPHS
char[14]='?'    byte=96 \u60    short=20320 \u4F60      CJK_UNIFIED_IDEOGRAPHS
char[15]='?'    byte=125 \u7D   short=22909 \u597D      CJK_UNIFIED_IDEOGRAPHS

按系统缺省编码重新变成字节流，然后按照GB2312方式解码，这里虽然打印出的是问号（因为当前的英文环境下系统对于255以上的字符是不知道用什么字符表示的，因此全部用?显示）但从相应的UNICODE MAPPING和SHORT值我们可以知道字符是正确的中文。但下一步的写入第2个文件html.gb2312.html，没有指定编码方式（按系统缺省的ISO-8859-1编码方式），因此从后面的测试2－2读取的结果是真的'？'了

[test 1-3]: convert string to UTF8
string=Hello world 涓栫晫浣犲ソ length=24
...

第3个试验，将字符流按照UTF8方式编码后，写入第3个测试文件hello.utf8.html，我们可以看到UTF8对英文没有影响，但对于其他文字使用了3字节编码方式，因此比GB2312编码方式的存储要大50%，

========Testing2: reading and decoding from files========
[test 2-1]: read hello.orig.html: decoding with system default encoding
string=Hello world 世界你好     length=20
...
按系统从中间存储hello.orig.html文件中读取相应文件，虽然是按字节方式（半个“字”）读取的，但由于能完整的还原，因此输出显示没有错误。其实PHP等应用很少出现字符集问题其实就是这个原因，全程都是按字节流方式处理，很好的还原了输入，但这样处理的同时也失去了对字符的控制

[test 2-2]: read hello.gb2312.html: decoding as GB2312
string=Hello world ???? length=16
...
char[12]='?'    byte=63 \u3F    short=63 \u3F   BASIC_LATIN
...
最惨的就是输出的时候这些'?'真的是问号char(63)了，数据如果是这样就真的没救了

[test 2-3]: read hello.utf8.html: decoding as UTF8
string=Hello world ???? length=16
...
char[12]='?'    byte=22 \u16    short=19990 \u4E16      CJK_UNIFIED_IDEOGRAPHS
...
great! 字符虽然显示为'?'，但实际上字符的解码是正确的，从相应的UNICODE MAPPING就可以看的出来。

环境：LANG=zh_CN LC_ALL=zh_CN.GBK

========Testing1: write hello world to files========
[test 1-1]: with system default encoding=GBK
string=Hello world 世界你好     length=16
...
char[12]='世'   byte=22 \u16    short=19990 \u4E16      CJK_UNIFIED_IDEOGRAPHS
char[13]='界'   byte=76 \u4C    short=30028 \u754C      CJK_UNIFIED_IDEOGRAPHS
char[14]='你'   byte=96 \u60    short=20320 \u4F60      CJK_UNIFIED_IDEOGRAPHS
char[15]='好'   byte=125 \u7D   short=22909 \u597D      CJK_UNIFIED_IDEOGRAPHS

注意：在新的语言环境中做以上测试需要将源程序重新编译，最早的字节流到字符流的解码过程从JavaC编译源文件就开始了，这个测试和刚才最大的不同在于源文件中的“世界你好”这4个字是否按中文编码方式编译导程序里的，而不是按字节方式编译成8个字符（实际上对应的是8个字节）在程序里。

[test 1-2]: getBytes with platform default encoding and decoding as gb2312:
string=Hello world 世界你好     length=16
...
在中文环境下，解码和上面缺省的编码是一致的，因此输出一致

[test 1-3]: convert string to UTF8
string=Hello world 涓栫晫浣犲ソ length=18
...
其实我们用于测试的终端窗口就是一个GBK字符集的应用，这个输出其实都是把UNICODE按GBK字符集解码的效果。

========Testing2: reading and decoding from files========
[test 2-1]: read hello.orig.html: decoding with system default encoding
string=Hello world 世界你好     length=16
...
[test 2-2]: read hello.gb2312.html: decoding as GB2312
string=Hello world 世界你好     length=16
...
[test 2-3]: read hello.utf8.html: decoding as UTF8
string=Hello world 世界你好     length=16
...
结论：如果后台数据采用UNICODE方式的存储然后根据需要指定字符集编码、解码方式，则应用几乎可以不受前端应用所处环境字符集设置的影响

试验2的一些结论：

所有的应用都是按照字节流=>字符流=>字节流方式进行的处理的：byte_stream ==[input decoding]==> unicode_char_stream ==[output encoding]==> byte_stream；
在Java字节流到字符流（或者反之）都是含有隐含的解码处理的（缺省是按照系统缺省编码方式）；
最早的字节流解码过程从javac的代码编译就开始了；
Java中的字符character存储单位是双字节的UNICODE；