Java中的字符集编码入门(5)Java代码中的字符编码转换Part1.docVIP

如果你是JVM的设计者，让你来决定JVM中所有字符的表示形式，你会不会允许使用各种编码方式的字符并存？我想你的答案是不会，如果在内存中的Java字符可以以GB2312,UTF-16,BIG5等各种编码形式存在，那么对开发者来说，连进行最基本的字符串打印、连接等操作都会寸步难行。例如一个GB2312的字符串后面连接一个UTF-8的字符串，那么连接后的最终结果应该是什么编码的呢？你选哪一个都没有道理。因此牢记下面这句话，这也是Java开发者的共同意志：在Java中，字符只以一种编码形式存在，那就是UTF-16。但“在Java中”到底是指在哪里呢？就是指在JVM中，在内存中，在你的代码里声明的每一个char，String类型的变量中。例如你在程序中这样写 char han=汉; 在内存的相应区域，这个字符就表示为0x6C49。可以用下面的代码证明一下： char han=汉;System.out.format(%x,(short)han); 输出是：6c49反过来用UTF-16编码来指定一个字符也可以，像这样： char han=0x6c49;System.out.println(han); 输出是：汉这其实也是说，只要你正确的读入了“汉”这个字，那么它在内存中的表示形式一定是0x6C49，没有任何其他的值能代表这个字（当然，如果你读错了，那结果是什么就不知道了，范伟说：读，读错了呀，那还等于好几亿呢；本山大哥说：好几亿你也没答上，请听下一题）。JVM的这种约定使得一个字符存在的世界分为了两部分：JVM内部和OS的文件系统。在JVM内部，统一使用UTF-16表示，当这个字符被从JVM内部移到外部（即保存为文件系统中的一个文件的内容时），就进行了编码转换，使用了具体的编码方案（也有一种很特殊的情况，使得在JVM内部也需要转换，不过这个是后话）。因此可以说，所有的编码转换就只发生在边界的地方，JVM和OS的交界处，也就是你的各种输入输出流（或者Reader，Writer类）起作用的地方。话头扯到这里就必须接着说Java的IO系统。尽管看上去混乱繁杂，但是所有的IO基本上可以分为两大阵营：面向字符的Reader啊Wrtier啊，以及面向字节的输入输出流。下面我来逐一分解，其实一点也不难。面向字符和面向字节中的所谓“面向”什么，是指这些类在处理输入输出的时候，在哪个意义上保持一致。如果面向字节，那么这类工作要保证系统中的文件二进制内容和读入JVM内部的二进制内容要一致。不能变换任何0和1的顺序。因此这是一种非常“忠实于原著”的做法（偶然间让我想起郭敬明抄袭庄羽的文章，那家伙，太忠实于原著了，笑）。这种输入输出方式很适合读入视频文件或者音频文件，或者任何不需要做变换的文件内容。而面向字符的IO是指希望系统中的文件的字符和读入内存的“字符”（注意和字节的区别）要一致。例如我们的中文版WindowsXP系统上有一个GBK的文本文件，其中有一个“汉”字，这个字的GBK编码是0xBABA（而UTF-16编码是0x6C49），当我们使用面向字符的IO把它读入内存并保存在一个char型变量中时，我希望IO系统不要傻傻的直接把0xBABA放到这个char型变量中，我甚至都不关心这个char型变量具体的二进制内容到底是多少，我只希望这个字符读进来之后仍然是“汉”这个字。从这个意义上也可以看出，面向字符的IO类，也就是Reader和Writer类，实际上隐式的为我们做了编码转换，在输出时，将内存中的UTF-16编码字符使用系统默认的编码方式进行了编码，而在输入时，将文件系统中已经编码过的字符使用默认编码方案进行了还原。我两次提到“默认”，是说Reader和Writer的聪明也仅此而已了，它们只会使用这个默认的编码来做转换，你不能为一个Reader或者Writer指定转换时使用的编码。这也意味着，如果你使用中文版WindowsXP系统，而上面存放了一个UTF-8编码的文件，当你使用Reader类来读入的时候，它会傻傻的使用GBK来做转换，转换后的内容当然驴唇不对马嘴！这种笨，有时候其实是一种傻瓜式的功能提供方式，对大多数初级用户（以及不需要跨平台的高级用户）来说反而是件好事。但我们不一样啦，我们都是国家栋梁，肩负着赶英超美的责任，必须师夷长技以治夷，所以我们总还要和GBK编码以外的文件打交道。说了上面这些内容，想必聪明的读者已经看出来，所谓编码转换就是一个字符与字节之间的转换，因此Java的IO系统中能够指定转换编码的地方，也就在字符与字节转换的地方，那就是（读者：InputSteamReader和OutputStreamWriter！作者：太强了，都会抢答了！）这两个类是字节流和字符流之间的适配器类，因此他们