Java字符编码根本原理

一、

由于JDK是国际版的，在对程序进行编译的时候，如果我们没有用-encoding参数指定我们的Java源程序的编码格式，则javac.exe首先获得我们操作系统默认采用的编码格式，即：在编译.java文件时，若我们不指定源程序文件的编码格式，JDK首先获得操作系统的file.encoding参数（它保存的就是操作系统默认的编码格式，如果是WIN2k，则它的值为GBK）。然后JDK就把我们的Java源程序从file.encoding编码格式，转化为Java内部默认的Unicode编码格式放入内存中。然后，javac.exe把转换后的Unicode编码格式的文件进行编译，使之成.class类文件，此时的.class文件是Unicode编码的，它暂放在内存中。紧接着，JDK将此以Unicode编码的编译后的.class文件保存到我们的操作系统中，形成我们见到的.class文件。对我们来说，我们最终获得的.class文件是内容以Unicode编码格式保存的类文件，它内部包含我们源程序中的中文字符串，只不过此时它已经由file.encoding格式转化为Unicode格式了。当我们不加设置就对程序进行编译时，相当于使用了参数：javac -encoding gbk XX.java，当然就会出现不兼容的情况。

由于JDK是国际版的，在对程序进行编译的时候，如果我们没有用-encoding参数指定我们的Java源程序的编码格式，则javac.exe会首先获得我们操作系统默认采用的编码格式，也即在编译Java程序时，若我们不指定源程序文件的编码格式，JDK首先获得操作系统的file.encoding参数（它保存的就是操作系统默认的编码格式，如果是WIN2k，则它的值为GBK），然后JDK就把我们的Java源程序从file.encoding编码格式，转化为Java内部默认的Unicode格式放入内存中。然后，javac.exe把转换后的Unicode格式的文件进行编译，使之成.class类文件，此时的.class文件是Unicode编码的，它暂放在内存中。紧接着，JDK将此以Unicode编码的编译后的.class 文件保存到我们的操作系统中，形成我们见到的.class文件。对我们来说，我们最终获得的.class文件是内容以Unicode编码格式保存的类文件，它内部包含我们源程序中的中文字符串，只不过此时它己经由file.encoding格式转化为Unicode格式了。当我们不加设置就对程序进行编译时，相当于使用了参数：

javac -encoding gbk XX.java，当然就会出现不兼容的情况。

二、

Java开发中，常常会遇到乱码的问题，一旦遇到这种问题，常常就很扯蛋，每个人都不愿意承认是自己的代码有问题。其实编码问题并没有那么神秘，那么不可捉摸，搞清Java的编码本质过程就真相大白了。

其实，编码问题存在两个方面：JVM之内和JVM之外。

1、Java文件编译后形成class

这里Java文件的编码可能有多种多样，但Java编译器会自动将这些编码按照Java文件的编码格式正确读取后产生class文件，这里的class文件编码是Unicode编码（具体说是UTF-16编码）。

因此，在Java代码中定义一个字符串：

String s="汉字";

不管在编译前Java文件使用何种编码，在编译成class后，他们都是一样的----Unicode编码表示。

2、JVM中的编码

JVM加载class文件读取时候使用Unicode编码方式正确读取class文件，那么原来定义的String

s="汉字";在内存中的表现形式是Unicode编码。

当调用String.getBytes()的时候，其实已经为乱码买下了祸根。因为此方法使用平台默认的字符集来获取字符串对应的字节数组。在WindowsXP中文版中，使用的默认编码是GBK，不信运行下：

public class Test {    public static void main(String[] args) {        System.out.println("当前JRE："System.getProperty("java.version"));        System.out.println("当前JVM的默认字符集："Charset.defaultCharset());    }}

当前JRE：1.6.0_16

当前JVM的默认字符集：GBK

当不同的系统、数据库经过多次编码后，如果对其中的原理不理解，就容易导致乱码。因此，在一个系统中，有必要对字符串的编码做一个统一，这个统一模糊点说，就是对外统一。比如方法字符串参数，IO流，在中文系统中，可以统一使用GBK、GB13080、UTF-8、UTF-16等等都可以，只是要选择有些更大字符集，以保证任何可能用到的字符都可以正常显示，避免乱码的问题。（假设对所有的文件都用ASCII码）那么就无法实现双向转换了。

要特别注意的是，UTF-8并非能容纳了所有的中文字符集编码，因此，在特殊情况下，UTF-8转GB18030可能会出现乱码（文末有阐述），然而一群傻B常常在做中文系统喜欢用UTF-8编码而说不出个所以然出来！最傻B的是，一个系统多个人做，源代码文件有的人用GBK编码，有人用UTF-8，还有人用GB18030。FK，都是中国人，也不是外包项目，用什么UTF-8啊，神经！源代码统统都用GBK18030就OK了，免得ANT脚本编译时候提示不可认的字符编码。

因此，对于中文系统来说，最好选择GBK或GB18030编码（其实GBK是GB18030的子集），以便最大限度地避免乱码现象。

3、内存中字符串的编码

内存中的字符串不仅仅局限于从class代码中直接加载而来的字符串，还有一些字符串是从文本文件中读取的，还有的是通过数据库读取的，还有可能是从字节数组构建的，然而他们基本上都不是Unicode编码的，原因很简单，存储优化。

因此就需要处理各种各样的编码问题，在处理之前，必须明确“源”的编码，然后用指定的编码方式正确读取到内存中。如果是一个方法的参数，实际 上必须明确该字符串参数的编码，因为这个参数可能是另外一个日文系统传递过来的。当明确了字符串编码时候，就可以按照要求正确处理字符串，以避免乱码。

在对字符串进行解码编码的时候，应该调用下面的方法：

getBytes(String charsetName)   String(byte[] bytes, String charsetName)

而不要使用那些不带字符集名称的方法签名，通过上面两个方法，可以对内存中的字符进行重新编码。

UTF-8并非能容纳了所有的中文字符集编码

在Windows下用editPlus编写一段Java代码，里面含有中文的文档注释。结果在编译时出现了“编码GBK的不可映射字符”。若此时保存的时候用的是UTF-8编码，在cmd命令行编译的时候写

javac -encoding UTF8 XXX.java，但是编译仍然会报错，只是关于字符的报错减少了，说明UTF-8并非容纳了所有的中文字符集编码。