从JavaString实例来理解ANSI、Unicode、BMP、UTF等编码概念

运行结果如下图

从结果可以发现，只要指定了正确的字符集（代码页），String就可以解码出正确的Unicode，最后可以试试println(“\u4f60\u597d”)，输出的就是“你好”。

2.Unicode转换到各种编码——getBytes

String拥有了Unicode序列，想要转换到其它编码就易如反掌了，根据你参数指定的字符集，去相应的代码页查找就可以转换过去了，当然如果该字符集不支持某字符（也就是没有这条Unicode记录），那就会导致编码丢失，再也不能还原到原来的Unicode序列了。

这里，我们和第1节的做法相反，我们把Unicode序列转换到其它各种编码，如下所示。

public class Test {

    public static void main(String[] args) throws IOException {
        //字符串"你好"
        String str = "\u4f60\u597d";

        //转换到各种编码

        showBytes(str, "GBK");
        showBytes(str, "BIG5");
        showBytes(str, "UTF-8");
    }

    public static void showBytes(String str, String charset) throws IOException {
        for (byte b : str.getBytes(charset))
            System.out.printf("0x%x ", b);
        System.out.println();
    }
}

运行结果如下图

可以发现，由于String掌握了Unicode码，要转换到其它编码so easy！

3.以Unicode为桥梁，实现编码互转

有了上面两部分的基础，要实现编码互转就很简单了，只需要把他们联合使用就可以了。先new String把原编码数据转换为Unicode序列，再调用getBytes转到指定的编码就OK。

比如一个很简单的GBK到Big5的转换代码如下

public static void main(String[] args) throws UnsupportedEncodingException {
        //假设这是以字节流方式从文件中读取到的数据（GBK编码）
        byte[] gbkData = {(byte) 0xc4, (byte) 0xe3, (byte) 0xba, (byte) 0xc3};

        //转换到Unicode
        String tmp = new String(gbkData, "GBK");

        //从Unicode转换到Big5编码
        byte[] big5Data = tmp.getBytes("Big5");

        //后续操作……
    }

4.编码丢失问题

上面已经解释了，JSP框架采用ISO-8859-1字符集来解码的原因。先用一个例子来模拟这个还原过程，代码如下

public class Test {

    public static void main(String[] args) throws UnsupportedEncodingException {
        //JSP框架收到6个字节的数据
        byte[] data = {(byte) 0xe4, (byte) 0xbd, (byte) 0xa0, (byte) 0xe5, (byte) 0xa5, (byte) 0xbd};
        //打印原始数据
        showBytes(data);
        //JSP框架假设它是ISO-8859-1的编码，生成一个String对象
        String tmp = new String(data, "ISO-8859-1");

        //**************JSP框架部分结束********************

        //开发者拿到后打印它发现是6个欧洲字符，而不是预期的"你好"
        System.out.println("  ISO解码的结果：" + tmp);

        //因此首先要得到原始的6个字节的数据（反查ISO-8859-1的代码页）
        byte[] utfData = tmp.getBytes("ISO-8859-1");

        //打印还原的数据
        showBytes(utfData);

        //开发者知道它是UTF-8编码的，因此用UTF-8的代码页，重新构造String对象
        String result = new String(utfData, "UTF-8");
        //再打印，正确了！
        System.out.println("  UTF-8解码的结果：" + result);
    }

    public static void showBytes(byte[] data) {
        for (byte b : data)
            System.out.printf("0x%x ", b);
        System.out.println();
    }
}

运行结果如下，第一次输出是不正确的，因为解码规则不对，也查错了代码页，得到的是错误的Unicode。然后发现通过错误的Unicode反查ISO-8859-1代码页还能完美的还原数据。

然后我们尝试把ISO-8859-1替换为ASCII，结果就会变成这样子

这是因为，ASCII虽然也是每字节对应一个字符，但是它只对0~127这个空间进行了编码，也就是说每个字节的最大值只能为0x7F，而上面的6个字节全部都大于这个数值，因此在ASCII的代码页中是找不到这6个字节的，于是Java就搞了一个缺省值。我用如下的代码测试发现，当通过编码数据在代码页中查不到对应的Unicode时，就返回缺省值\ufffd（对应图中第一种问号），反过来，当通过Unicode在代码页中查不到对应的编码数据时，就返回缺省值0x3f（ASCII，对应图中第二种问号）。由此，这个输出结果也就可以解释清楚了。

public static void main(String[] args) throws IOException {
        //输出结果全为\ufffd
        byte[] data = {(byte) 0x80};
        showUnicode(new String(data, "UTF-8"));
        showUnicode(new String(data, "GBK"));
        showUnicode(new String(data, "Big5"));

        //输出结果全为0x3f
        String str = "\uccdd";
        showBytes(str, "GBK");
        showBytes(str, "BIG5");
        showBytes(str, "ISO-8859-1");
    }

5.Java源文件的编码问题

这就是开头所提到的那个问题，把问题描述一下先。就如下这么一小段代码，源文件使用UTF-8编码保存。（注意别用Windows的记事本，因为它会在UTF-8文件最前面加入一个3字节的BOM头，而很多程序都不兼容这一点）

public class Test {

    public static void main(String[] args) {
        System.out.println("中");
    }
}

然后在Windows中使用默认参数编译该文件（系统区域设置为简体中文，即默认使用GBK字符集解码），然后会得到如下错误

这不是重点，重点如果把“中”换成“中国”，编译就会成功，运行结果如下图。另外进一步可发现，中文字符个数为奇数时编译失败，偶数时通过。这是为什么呢？下面详细分析一下。

因为Java String内部使用的是Unicode，所以在编译的时候，编译器就会对我们的字符串字面量进行转码，从源文件的编码转换到Unicode（维基百科说用的是与UTF-8稍微有点不同的编码）。编译的时候我们没有指定encoding参数，所以编译器会默认以GBK方式去解码，对UTF-8和GBK有点了解的应该会知道，一般一个中文字符使用UTF-8编码需要3个字节，而GBK只需要2个字节，这就能解释为什么字符数的奇偶性会影响结果，因为如果2个字符，UTF-8编码占6个字节，以GBK方式来解码恰好能解码为3个字符，而如果是1个字符，就会多出一个无法映射的字节，就是图中问号的地方。

再具体一点的话，源文件中“中国”二字的UTF-8编码是 e4 b8 ad e5 9b bd，编译器以GBK方式解码，3个字节对分别查cp936得到3个Unicode值，分别是6d93 e15e 6d57，对应结果图中的三个奇怪字符。如下图所示，编译后这3个Unicode在.class文件中实际以类UTF-8编码存储，运行的时候，JVM中存储的就是Unicode，然而最终输出时，还是会编码之后传递给终端，这次约定的编码就是系统区域设置的编码，所以如果终端编码设置改了，还是会乱码。我们这里的e15e在Unicode标准中并没有定义相应的字符，所以在不同平台不同字体下显示会有所不同。

可以想象，如果反过来，源文件以GBK编码存储，然后骗编译器说是UTF-8，那基本上是无论输入多少个中文字符都无法编译通过了，因为UTF-8的编码很有规律性，随意组合的字节是不会符合UTF-8编码规则的。

当然，要使编译器能正确的把编码转换到Unicode，最直接的方法还是老老实实告诉编译器源文件的编码是什么。

四、总结

经过这次收集整理和实验，了解了很多与编码相关的概念，也熟悉了编码转换的具体过程，这些思想可以推广到各种编程语言去，实现原理都类似，所以我想以后再遇到这类问题，应该不会再不知所以然了。