：java与编码问题串讲

转自这个博客：http://blog.csdn.net/shijinupc/

一、

我们知道，在计算机内部，所有的信息最终都表示为一个二进制的字符串。每一个二进制位（bit）有0和1两种状态，因此八个二进制位就可以组合出256种状态，这被称为一个字节（byte）。也就是说，一个字节一共可以用来表示256种不同的状态，每一个状态对应一个符号，就是256个符号，从0000000到11111111。

ANSI编码

（American National Standards Institute,美国国家标准学会的标准码）

上个世纪60年代，美国制定了一套字符编码，对英语字符与二进制位之间的关系，做了统一规定。这被称为ASCII码，一直沿用至今。

ASCII码一共规定了128个字符的编码，比如空格“SPACE”是32（二进制00100000），大写的字母A是65（二进制01000001）。这128个符号（包括32个不能打印出来的控制符号），只占用了一个字节的后面7位，最前面的1位统一规定为0。

英语用128个符号编码就够了，但是用来表示其他语言，128个符号是不够的。比如，在法语中，字母上方有注音符号，它就无法用ASCII码表示。于是，一些欧洲国家就决定，利用字节中闲置的最高位编入新的符号。比如，法语中的的编码为130（二进制10000010）。这样一来，这些欧洲国家使用的编码体系，可以表示最多256个符号。

但是，这里又出现了新的问题。不同的国家有不同的字母，因此，哪怕它们都使用256个符号的编码方式，代表的字母却不一样。比如，130在法语编码中代表了é，在希伯来语编码中却代表了字母Gimel（），在俄语编码中又会代表另一个符号。但是不管怎样，所有这些编码方式中，0—127表示的符号是一样的，不一样的只是128—255的这一段。

至于亚洲国家的文字，使用的符号就更多了，汉字就多达10万左右。一个字节只能表示256种符号，肯定是不够的，就必须使用多个字节表达一个符号。比如，简体中文常见的编码方式是GB2312，使用两个字节表示一个汉字，所以理论上最多可以表示256x256=65536个符号。

后来不同的国家和地区根据ANSI制定了不同的标准，由此产生了GB2312, BIG5, JIS 等各自的编码标准。这些使用2 个字节来代表一个字符的各种汉字延伸编码方式，称为ANSI 编码。

在简体中文系统下，ANSI 编码代表GB2312编码，在日文操作系统下，ANSI 编码代表JIS 编码。不同ANSI 编码之间互不兼容，当信息在国际间交流时，无法将属于两种语言的文字，存储在同一段ANSI编码的文本中。

当然对于ANSI编码而言，0x00~0x7F之间（ASCII码）的字符，依旧是1个字节代表1个字符。这一点是ASNI编码与Unicode编码之间最大也最明显的区别。

Unicode

正如上一节所说，世界上存在着多种编码方式，同一个二进制数字可以被解释成不同的符号。因此，要想打开一个文本文件，就必须知道它的编码方式，否则用错误的编码方式解读，就会出现乱码。为什么电子邮件常常出现乱码？就是因为发信人和收信人使用的编码方式不一样。

可以想象，如果有一种编码，将世界上所有的符号都纳入其中。每一个符号都给予一个独一无二的编码，那么乱码问题就会消失。这就是Unicode，就像它的名字都表示的，这是一种所有符号的编码。

Unicode当然是一个很大的集合，现在的规模可以容纳100多万个符号。每个符号的编码都不一样，比如，U+0639表示阿拉伯字母Ain，U+0041表示英语的大写字母A，U+4E25表示汉字“严”。具体的符号对应表，可以查询unicode.org，或者专门的汉字对应表。

需要注意的是，Unicode只是一个符号集，它只规定了符号的二进制代码，却没有规定这个二进制代码应该如何存储。

比如，汉字“严”的unicode是十六进制数4E25，转换成二进制数足足有15位（100111000100101），也就是说这个符号的表示至少需要2个字节。表示其他更大的符号，可能需要3个字节或者4个字节，甚至更多。

这里就有两个严重的问题，第一个问题是，如何才能区别unicode和ascii？计算机怎么知道三个字节表示一个符号，而不是分别表示三个符号呢？第二个问题是，我们已经知道，英文字母只用一个字节表示就够了，如果unicode统一规定，每个符号用三个或四个字节表示，那么每个英文字母前都必然有二到三个字节是0，这对于存储来说是极大的浪费，文本文件的大小会因此大出二三倍，这是无法接受的。

它们造成的结果是：1）出现了unicode的多种存储方式，也就是说有许多种不同的二进制格式，可以用来表示unicode。2）unicode在很长一段时间内无法推广，直到互联网的出现。

UTF-8

Unicode编码字符集只是统一定义了所有字符和它对应Unicode编码值，而我们的程序中怎么去存储和读取这个Unicode编码值呢？显然，你可以直接统一规定所有Unicode编码值用四个字节来存储。但是这样的话，对于Unicode编码字符集中的与ASCII码表对应的那部分字符(只需要一个字节来表示的Unicode编码值)就有点浪费了。这样，utf-8也就粉墨登场了。

UTF-8最大的一个特点，就是它是一种变长的编码方式。它可以使用1~4个字节表示一个符号，根据不同的符号而变化字节长度。

Unicode符号范围 | UTF-8编码方式
(十六进制) | （二进制）
--------------------+---------------------------------------------
0000 0000 ~ 0000 007F | 0xxxxxxx --------7bit
0000 0080 ~ 0000 07FF | 110xxxxx 10xxxxxx -------11bit
0000 0800 ~ 0000 FFFF | 1110xxxx 10xxxxxx 10xxxxxx -----16bit
0001 0000 ~ 0010 FFFF | 11110xxx 10xxxxxx 10xxxxxx 10xxxxxx ----21bit

UTF-8编码规则：

1> 对于Unicode编码值的二进制位数小于等于7的情况，用一个字节来表示这个Unicode编码值，字节的第一位设为0，后面7位为这个符号的unicode码。因此对于英语字母，UTF-8编码和ASCII码是相同的。

2> 对于Unicode编码值的二进制位数大于等于8并且小于等于11的情况，用两个字节来表示，第一个字节的前两位都设为1，第两+1位设为0，第二个字节的前两位设为10。剩下的没有提及的二进制位，全部填充这个符号对应的unicode码。

3> 以此类推，对于需要n个utf-8 字节来表示的的符号（n>1），第一个字节的前n位都设为1，第n+1位设为0，后面字节的前两位一律设为10。剩下的没有提及的二进制位，全部填充这个符号对应的unicode码。

utf-8编码长度最大为四个字节，所以最多只能表示Unicode编码值的二进制数为21位的Unicode字符。但是已经能表示所有的Unicode字符，因为Unicode的最大码位0x10FFFF也只有21位。

UTF-8的特点是对不同范围的字符使用不同长度的编码。对于0x00-0x7F之间的字符，UTF-8编码与ASCII编码完全相同。UTF-8编码的最大长度是4个字节。从上表可以看出，4字节模板有21个x，即可以容纳21位二进制数字。Unicode的最大码位0x10FFFF也只有21位。

下面，还是以汉字“严”为例，演示如何实现UTF-8编码。

已知“严”的unicode是4E25（100111000100101），根据上表，可以发现4E25处在第三行的范围内（0000 0800-0000 FFFF），因此“严”的UTF-8编码需要三个字节，即格式是“1110xxxx 10xxxxxx 10xxxxxx”。然后，从“严”的最后一个二进制位开始，依次从后向前填入格式中的x，多出的位补0。这样就得到了，“严”的UTF-8编码是“11100100 10111000 10100101”，转换成十六进制就是E4B8A5。

Little endian和Big endian

在windows记事本中，Unicode码可以采用UCS-2格式直接存储。以汉字“严”为例，Unicode码是4E25，需要用两个字节存储，一个字节是4E，另一个字节是25。存储的时候，4E在前，25在后，就是Big endian方式；25在前，4E在后，就是Little endian方式。

这两个古怪的名称来自英国作家斯威夫特的《格列佛游记》。在该书中，小人国里爆发了内战，战争起因是人们争论，吃鸡蛋时究竟是从大头(Big-Endian)敲开还是从小头(Little-Endian)敲开。为了这件事情，前后爆发了六次战争，一个皇帝送了命，另一个皇帝丢了王位。

因此，第一个字节在前，就是“大头方式”（Big endian），第二个字节在前就是“小头方式”（Little endian）。

那么很自然的，就会出现一个问题：计算机怎么知道某一个文件到底采用哪一种方式编码？

Unicode规范中定义，每一个文件的最前面分别加入一个表示编码顺序的字符，这个字符的名字叫做”零宽度非换行空格“（ZERO WIDTH NO-BREAK SPACE），用FEFF表示。这正好是两个字节，而且FF比FE大1。

如果一个文本文件的头两个字节是FE FF，就表示该文件采用大头方式；如果头两个字节是FF FE，就表示该文件采用小头方式。

例如：

打开”记事本“程序Notepad.exe，新建一个文本文件，内容就是一个”严“字，依次采用ANSI，Unicode，Unicode big endian 和 UTF-8编码方式保存。

然后，用文本编辑软件UltraEdit中的”十六进制功能“，观察该文件的内部编码方式。

1）ANSI：文件的编码就是两个字节“D1 CF”，这正是“严”的GB2312编码，这也暗示GB2312是采用大头方式存储的。

2）Unicode：编码是四个字节“FF FE 25 4E”，其中“FF FE”表明是小头方式存储，真正的编码是4E25。

3）Unicode big endian：编码是四个字节“FE FF 4E 25”，其中“FE FF”表明是大头方式存储。

4）UTF-8：编码是六个字节“EF BB BF E4 B8 A5”，前三个字节“EF BB BF”表示这是UTF-8编码，后三个“E4B8A5”就是“严”的具体编码，它的存储顺序与编码顺序是一致的。

UTF-16

16进制编码范围	UTF-16表示方法（二进制）	10进制码范围	字节数量
U+0000---U+FFFF	xxxxxxxx xxxxxxxx	0-65535	2
U+10000---U+10FFFF	110110yyyyyyyyyy 110111xxxxxxxxxx	65536-1114111	4

UTF-16比起UTF-8，好处在于大部分字符都以固定长度的字节（2字节）储存----0号平面(包含所有基本的字符)都在此表示范围，但UTF-16却无法相容于ASCII编码.

UTF-16编码以16位无符号整数为单位。我们把Unicode 编码记作U。编码规则如下：

　　如果U<0x10000，U的UTF-16编码就是U对应的16位无符号整数（为书写简便，下文将16位无符号整数记作WORD）。

　　如果U≥0x10000，我们先计算U'=U-0x10000，然后将U'写成二进制形式：yyyy yyyy yyxx xxxx xxxx，U的UTF-16编码（二进制）就是：110110yyyyyyyyyy 110111xxxxxxxxxx。

　　为什么U'可以被写成20个二进制位？Unicode的最大码位是0x10ffff，减去0x10000后，U'的最大值是0xfffff，所以肯定可以用20个二进制位表示。例如：Unicode编码0x20C30，减去0x10000后，得到0x10C30，写成二进制是：0001 0000 1100 0011 0000。用前10位依次替代模板中的y，用后10位依次替代模板中的x，就得到：1101100001000011 1101110000110000，即0xD843 0xDC30。

　　按照上述规则，Unicode编码0x10000-0x10FFFF的UTF-16编码有两个WORD，第一个WORD的高6位是110110，第二个WORD的高6位是110111。可见，第一个WORD的取值范围（二进制）是11011000 00000000到11011011 11111111，即0xD800-0xDBFF。第二个WORD的取值范围（二进制）是11011100 00000000到11011111 11111111，即0xDC00-0xDFFF。

　　为了将一个WORD的UTF-16编码与两个WORD的UTF-16编码区分开来，Unicode编码的设计者将0xD800-0xDFFF保留下来，并称为代理区（Surrogate）：

　　D800－DB7F　║　High Surrogates　║　高位替代

　　DB80－DBFF　║　High Private Use Surrogates　║　高位专用替代

　　DC00－DFFF　║　Low Surrogates　║　低位替代

　　高位替代就是指这个范围的码位是两个WORD的UTF-16编码的第一个WORD。低位替代就是指这个范围的码位是两个WORD的UTF-16编码的第二个WORD。那么，高位专用替代是什么意思？我们来解答这个问题，顺便看看怎么由UTF-16编码推导Unicode编码。

　　如果一个字符的UTF-16编码的第一个WORD在0xDB80到0xDBFF之间，那么它的Unicode编码在什么范围内？我们知道第二个WORD的取值范围是0xDC00-0xDFFF，所以这个字符的UTF-16编码范围应该是0xDB80 0xDC00到0xDBFF 0xDFFF。我们将这个范围写成二进制：

　　1101101110000000 11011100 00000000 - 1101101111111111 1101111111111111

　　按照编码的相反步骤，取出高低WORD的后10位，并拼在一起，得到

　　1110 0000 0000 0000 0000 - 1111 1111 1111 1111 1111

即0xe0000-0xfffff，按照编码的相反步骤再加上0x10000，得到0xf0000-0x10ffff。这就是UTF-16编码的第一个WORD在0xdb80到0xdbff之间的Unicode编码范围，即平面15和平面16。因为Unicode标准将平面15和平面16都作为专用区，所以0xDB80到0xDBFF之间的保留码位被称作高位专用替代。

二、如何理解java采用Unicode编码

Java开发者必须牢记：在Java中字符仅以一种形式存在，那就是Unicode（不选择任何特定的编码，直接使用他们在字符集中的编号，这是统一的唯一方法）。由于java采用unicode编码，char 在java中占2个字节。2个字节（16位）来表示一个字符。

这里的Java中是指在JVM中、在内存中、在代码里声明的每一个char、String类型的变量中。

例如：

[java] view plain copy

System.out.println(System.getProperty("file.encoding"));
char han = '永';
System.out.format("%x", (short)han);//对第二个参数（短整型）格式化为十六进制输出，0x开头
//输出6c38
char han1 = 0x6c38;
System.out.println(han1);
//输出永

也就是说，只要我们正确地读入了汉字“永”字，那么它在内存中的表示形式一定是0x6c38，没有其他任何值能替代这个字。

JVM的折中约定使得一个字符分为两部分：JVM内部和OS的文件系统。在JVM内部，统一使用Unicode表示，当这个字符被从JVM内部移到外部（即保存为文件系统中的一个文件的内容时），就进行了编码转换，使用了具体的编码方案。因此可以说所有的编码转换只发生在边界的地方，JVM和OS的交界处，也就是各种输入/输出流（或者Reader，Writer类）起作用的地方。

所有的I/O基本上可以分为两大阵营：面向字符的输入/输出流；面向字节的输入/输出流。这个“面向”是指这些类在处理输入/输出的时候，在哪个意义上保持一致。

如果面向字节，那么这类工作要保证系统中的文件二进制内容和读入JVM内部的二进制内容一致，不能变换任何0和1的顺序。这种输入/输出方式很适合诸如视频文件或者音频文件，因为不需要变换任何文件内容。

而面向字符的I/O是指希望系统中的文件的字符和读入内存的“字符”要一致。例如：我们的中文版XP系统上有一个GBK的文本文件，其中有一个“永”字，我们不关心这个字的GBK编码是什么，只希望在使用面向字符的I/O把它读入内存并保存在一个char型变量中时，I/O系统不要直接把“永”字的GBK编码放到这个字符（char）型变量中，我们不关心这个char型变量具体的二进制内容到底是多少，只希望这个字符读进来之后仍然是“永”字。

从这个意义上可以看出，面向字符的I/O类，也就是Reader和Writer类，实际上隐式做了编码转换，在输出时，将内存中的Unicode字符使用系统默认编码方式进行了编码，而在输入时，将文件系统中已经编码过的字符使用默认编码方案进行了还原。这里要注意，Reader和Writer只会使用这个默认的编码来做转换，而不能为一个Reader和Writer指定转换时使用的编码。这也意味着，如果使用中文版WindowsXP系统，其中存放了一个UTF8编码的文件，当采用Reader类来读入的时候，它还会用GBK来转换，转换后的内容当然不对。这其实是一种傻瓜式的功能提供方式，对大多数初级用户（以及不需要跨平台的高级用户，windows一般采用GBK，linux一般采用UTF8）来说反而是一件好事。

如果用到GBK编码以外的文件，就必须采用编码转换：一个字符与字节之间的转换。因此，Java的I/O系统中能够指定转换编码的地方，也就是在字符与字节转换的地方，那就是InputStremReader与OutputStreamWriter。这两个类是字节流和字符流的适配器类，它们承担编码转换的任务。

既然java是用unicode来编码字符，"我"这个中文字符的unicode就是2个字节。String.getBytes(encoding)方法是获取指定编码的byte数组表示，通常gbk/gb2312是2个字节，utf-8是3个字节。如果不指定encoding则取系统默认的encoding。

例如