Java与字符编码问题详谈

一、字符集和字符编码方式 

计算机只懂得0/1两种信号，而人类所使用的符号却无法尽数。要让计算机能够表示大千世界的符号，就一定要为每个符号指定一个唯一的整数。而这一套符号与整数的对应集合，就是我们经常谈论的字符集 。而且，每一个字符所对应的整数用多少个计算机字节表示，也就涉及到了字符编码方式 的问题。我们用比较规范的语言来定义这两个概念：

(1) 字符集：抽象字符集合和整数集合之间的映射关系。US-ASCII、ISO 8859-1、JIS X 0201 和与 ISO 10646-1 都是字符集示例。 
(2) 字字符编码方式：字符集和八位组（8 bits）序列集合之间的映射关系。UTF-8、UCS-2、UTF-16、ISO 2022 和 EUC 是一些字符编码方案示例。编码方案通常与特定的编码字符集相关联；例如，UTF-8 只用来编码 Unicode。但是，一些方案与多个字符集相关联；例如，EUC 可用于编码各种亚洲字符集中的字符 

在Unicode字符集规范出现之前，计算机在处理字符的问题上经历过ASCII和ANSI两种编码类型(【见附1】)两个阶段，在ASCII时代，计算机只能处理英文数字以及几个基本符号，当时使用的是单字节字符集（SBCS）。其中ASC就是7bits的编码，ISO-8859-1是8bits的编码。各国为了能在计算机上处理本国的文字，制订了相应的字符集国家标准(如支持中文简体的GBK字符集；支持中文繁体的BIG5字符集；支持日文使用Shift_JIS字符集等)。在ANSI编码时代，计算机使用多字节字符集（MBCS） 处理文字。如在GB2312标准中，"中国"两个字符分别使用两个字节表示，而"ABC"三个英文字符又分别使用一个字节表示。但是层出不穷的字符集标准造成的一种非常糟糕的问题：
(1) 相同形状的字符可能对应完全不同的整数。
(2) 相同的字符集也可能因为不同的编码方式而导致严重的分歧。
为了解决这些问题，国际组织根据各国语言的特点，使用两个字节的数据量将大部分国家的文字信息整合到一个字符集中，这就是Unicode编码，也称万国码。然后各个国家制定的字符集标准并非是Unicode的子集。换句话说，Unicode的存在只是多了一种新的标准而已。字符编码的冲突愈演愈烈。

我们用一个典型例子来看看计算机符号的乱码是如何产生的？

在Unicode字符集标准中，汉字字符[我]对应的Unicode码为整数25105(Ox6211)。这个数正常情况下在计算机中的存储用2个字节就可以表示：01100010 00010001。而这种编码方式也正是UTF-16算法的编码结果(实际上UTF-16为了扩展的Unicode字符集采用的算法还要复杂一些【见附2】)。然而还有一种很常用的编码方式是UTF-8，这种编码算法会用三个字节来表示[我]的Unicode码：11100110 10001000 10010001。
这个时候，如果计算机中存储的[我]是UTF-8编码的，而显示的时候我们用UTF-16来解码，我们看到的必定是一堆乱七八糟的字符。

在许多软件的应用过程中，乱码问题屡见不止。特别是Web应用程序，更是伤透了脑筋。特别是Java要做到平台无关性，编码问题就是一个重大的挑战。

 

 

二、Java对字符编码的支持 

(1) 字符类型char 
char是Java的字符类型。每char有2个字节，采用Unicode字符集标准，并在计算机中用UTF-16编码算法存储。 我们用下面两行代码来证实一下：

 char c='我';
 System.out.println(" 0x"+Integer.toHexString(Integer.valueOf((int)c)));
 //打印结果: 0x6211

 也就是说在Java程序运行的过程中，内存中用双字节0x6211来表示字符'我'。

 

(2) java.nio.charset.* 
【java.nio.charset.Charset】是Java的字符集类型。它可以实现不同字节集之间的相互编码和解码功能。 
● ByteBuffer encode(String str) 
   将内存中str的UTF-16编码字节序列转化成指定编码方式的字节序列。

 //转化字符串str为指定编码方式cstr的存储字节组
 public void transfer(String str,String cstr){
  Charset cs=Charset.forName(cstr);
  byte[] bs=cs.encode(CharBuffer.wrap(str)).array();
  printBytes(bs); //打印字节序列
 }

 transfer("我","UTF-16"); //utf-16编码字节序列：0x62 0x11
 transfer("我","UTF-8"); //utf-8编码字节序列：0xe6 0x88 0x91
 transfer("我","GBK"); //gbk编码字节序列：0xce 0xd2
 transfer("我","GB2312"); //gb2312编码字节序列：0xce 0xd2
 transfer("我","ISO-8859-1"); //iso 8859-1编码字节序列：0x3f

● CharBuffer decode(ByteBuffer bb)  
   将指定编码方式的字节序列转化成UTF-16编码的字节序列：

【java.nio.charset.CharsetDecoder】能够把特定 charset 中的字节序列转换成 UTF-16编码的字符序列的解码器。 也就是可以实现将其他字符编码转化成java能够处理的字符串。
● CoderResult decode(ByteBuffer in,CharBuffer out,boolean endOfInput)
   从给定的输入缓冲区中解码尽可能多的字节，把结果写入给定的输出缓冲区。除了从输入缓冲区读取字节和向输出缓冲区写入字符，此方法还返回一个 CoderResult 对象来描述它终止的原因：
   CoderResult.OVERFLOW 指示该输出缓冲区中没有足够空间来解码任何更多字节。
   CoderResult.isError() 表明解码失败，可能是因为指定的charset字节集无法解码当前的InputStream字节流。

 

【 java.nio.charset.CharsetEncoder】够把 16 位 Unicode 字符序列转换成特定 charset 中字节序列的编码器。

 

(3) String 类 
String是char[]数组，因此String类型数据在内存中也是UTF-16编码的字节序列。但在具体编程中，有时需要将字符串对象保存到持久化资源（文件或数据库）或将其通过网络传输时，通常是以某种编码的字节序列方式进行处理。事实上Charset类已经提供了不同编码方式的字节序列相互编码解码的功能。这里我们提到两外一个更加常用的String方法getBytes(Charset cs)也能解决这个问题：

 String str = "我";
 printBytes(str.getBytes(Charset.forName("UTF-16")));
 printBytes(str.getBytes(Charset.forName("UTF-8")));

 getBytes(Charset cs)方法可以用指定的cs编码方式来转化UTF-16编码的字节序列。

注意：实际上，我们用UTF-16编码查看字符串"我"的字节序列。发现有4个字节0xe 0xff 0x62 0x11来表示。其实前两个字节是一个BOM（ByteOrderMark），用于指明高低字节排列顺序的几个字符，。一般情况下，该 BOM值为0xFE 0xFF，即大端字节序（BIG_ENDIAN）。如果BOM值为0xFF 0xFE则为小端字节序（LITTLE_ENDIAN）。

另外，可以利用String类的构造方法String(byte[] bytes, Charset charset)，用指定的 charset解码指定的 byte 数组，构造一个新的String。其本质是从其它字符集编码向Unicode字符集编码转换的过程。 例如：

 //'我'的UTF-8编码的字符序列
 byte[] utf8Bytes = {(byte)0xe6,(byte)0x88,(byte)0x91};
 //采用平台的默认编码方式解码指定的utf8Bytes数组，形成一个新的String
 System.out.println(new String(utf8Bytes));
 //采用UTF-8编码方式解码指定的utf8Bytes数组，形成一个新的String
 System.out.println(new String(utf8Bytes,Charset.forName("UTF-8")));

 在Windows OS汉化版环境下，第一个打印结果将会是乱码，因为Windows平台默认的汉字编码方式是gbk。第一个打印语句相当于用gbk来解码utf-8编码出的字符，绝对的办不到的。第二个打印结果将打印出"我"。

总之：
(1) String对象数据一定是UTF-16编码的字节序列。即便下面的语句从文件中读取一行字符串：String line=new BufferedReader(new InputSteamReader(new FileInputStream(file),"gb2312").readLine();也是从文件中读取的字节序列用gb2312解码之后，转变成UTF-16编码的字节序列再存储到Java运行程序使用的内存中。
(2) 我们可以通过getBytes(Charset)和new String(bytes[],Charset)来进行Java的UTF-16编码字节序列与其他编码的字节序列进行转换。

 

 

三、Windows OS 记事本的字符编码问题 
     
Windows OS的默认字符集类型是ANSI类型(双字节类型)，中文版是gb2312/gbk编码方式 【见附1】。也就是说新建一个没有任何内容的记事本程序，其缺省的编码方式是gb2312编码方式。此时我们输入"联通"两个字，保存以后再打开，看看是不是变成乱码了。然后点另存为，注意看编码方式里是不是由"gb2312"变成"UTF8"了。哈哈，这就是一个比较有名的微软和联通有仇的笑话。

实际上，Windows OS记事本软件还是非常强大的。当我们用记事本打开一个未知编码方式的文本文件时，记事本会首先判断文档头部有无BOM（ByteorderMark，字节序标记，长度为２-３字节)。如有则根据其内容判断编码类型，FF、FE（UTF-16）,FE、FF（Unicodebig endian）,EF、BB、BF（UTF-8)。

但是很多非ANSI编码的文档是没有任何BOM的纯文本，所以对这些文档不能简单的判断为ANSI编码。而需要使用一系列的统计学算法根据文档内容来猜测文档编码。记事本使用了IsTextUnicode 函数来判断是否为Unicode/Unicode bigendian 编码，使用 IsTextUTF8  判断是否为UTF8编码。但既然是统计学算法，就难免存在误判，尤其在文档内容过短时，由于样本的容量太小，这种误判的概率会显著增大。

那么上面的那个笑话显然就是误判的结果。
首先、创建一个新的文本文件，此时的编码方式为gb2312。当写入"联通"两个字，记录在硬盘中的是gb2312编码的"联通"的字节序列：0xc1 0xaa 0xcd 0xa8 。
然后、我们关闭记事本，重新打开。此时记事本的判断程序觉得存储在硬盘中的gb2312编码的字节序列误判成UTF-8编码的。因此就用UTF-8来解码字节序列，之后就是我们看到的乱码字符。
最后、我们再次另存为这个文本文件，发现程序要求我们按照UTF-8来存储这个乱码字符。覆盖存储之后，发现硬盘中字节序列已经变成了：0xcd 0xa8。

 

四、Java IO 读取文件的字符编码问题 
     
微软强大的记事本软件尚且有误判的可能性。我们用Java IO读取磁盘文件的时候，稍不小心就会出现乱码。因此，我们在用Java IO读取文件的时候，最好能够判断当前文件所使用的字符编码。目前网络上流传一个比较好的识别字符编码的Java源代码BytesEncodingDetect.java，大家可以在下面下载看看。

【附1】： 编码类型是编码方式的归纳。 

ACSII、ANSI和UNICODE一样都是字符代码的一种表示形式。通常使用 0x80~0xFF 范围的2个字节来表示1个字符。不同的国家和地区制定了不同的标准，由此产生了GB2312, BIG5, JIS等各自的编码方式标准。而这些编码方式都可以统称为 ANSI 编码类型。在简体中文系统下，ANSI 编码代表 GB2312 编码，在日文操作系统下，ANSI 编码代表 JIS 编码。 

[1]ASCII 是单字节字符编码类型，
[2]ANSI (如：GB2312, BIG5,Shift_JIS,ISO-8859-2等等），是多字节编码类型（英文单字节，中文多字节）；
[3]UNICODE 编码（UTF-8, UTF-7, UTF-16, UnicodeLittle, UnicodeBig....）,是宽字节编码类型（所有字符均是多字节） 

【附2】： UTF-16编码算法

Unicode编码表的专业术语：
代码点 (code point): 指在Unicode编码表中一个字符所对应的代码值。如汉字“一”的代码点是U+4E00，英文字母“A”的代码点是U+0041。
代码单元( code unit): 规定16bits的存储容量就是一个代码单元。
   
Unicode编码表 分为17个代码级别 (code plane)，其中代码点\u0000-\uFFFF为第一级别 ---基本多语言级别 (basic multilingual plane),可以用一个代码单元存储一个代码点。其余16个附加级别 从0x10000-0x10FFFF（需要两个代码单元）。其中需要指出的是在多语言级别中，U+D800-U+DFFF这2048值没有表示任何字符，被称为Unicode的替代区域(surrogate area)。UTF-16正是的运用了这一区域，用2个代码单元(2*16bits)巧妙的表示出20bits代码点的Unicode附加级别。
   
UTF-16编码算法
假设U是一个代码点，也就是Unicode编码表中一个字符所对应的Unicode值。
(1) 如果U (2) 如果U+10FFFF>U>=U+10000，也就是处于附加级别中。UTF-16用2个16位来表示出了，并且正好将每个16位都控制在替代区域U+D800-U+DFFF 中了,具体操作如下：

分别初始化2个16位无符号的整数 —— W1和W2。其中W1=110110yyyyyyyyyy（0xD800-0xDBFF）,W2 = 110111xxxxxxxxxx(0xDC00-OxDFFF)。然后，将U的高10位分配给W1的低10位，将U的低10位分配给W2的低10位。这样就可以将20bits的代码点U拆成两个16bits的代码单元。而且这两个代码点正好落在替代区域U+D800-U+DFFF中。

具体举个例子：代码点U+1D56B（一个整数集的算术符号Z）
0x1D56B= 0001 1101 0101 0110 1011
将0x1D56B的高10位0001 1101 01分配给W1的低10位组合成110110 0001 1101 01=0xD875
将0x1D56B的低10位01 0110 1011分配给W2的低10位组合成110111 01 0110 1011=0xDD6B
这样代码点U+1D56B采用UTF-16编码方式，用2个连续的代码单元U+D875和U+DD68表示出了。