步骤 内容 地点 说明
01： C1 HelloWorld.java C1泛指一个GBK字符
02： U1 JAVAC读取 U1泛指一个Unicode字符
03： C1 getBytes()第一步 JAVA先和操作系统交流
04： B1,B2 getBytes()第二步 然后返回字节数组
05： C1 new String()第一步 JAVA先和操作系统交流
06： U1 new String()第二步 然后返回字符
07： C1 println(String) 能显示“中”字，内容和原来的相同

　　2.5.2）然后再以代码段10为例，我们注意到只是：

步骤 内容 地点 说明
01： C1 HelloWorld.java C1泛指一个GBK字符
02： U1 JAVAC读取 U1泛指一个Unicode字符
03： C1 getBytes()第一步 JAVA先和操作系统交流
04： B1,B2 getBytes()第二步 然后返回字节数组
05： C3,C4 new String()第一步 JAVA先和操作系统交流，这时解析错误
06： U5,U6 new String()第二步 然后返回字符
07： C3,C4 println(String) 由于中字给分成了两半，在ISO8859_1中刚好也没有字符

　　能映射上，所以显示为“??”。在上面的示例中，
　　“中文”两个字就显示为“？？？？”
　　2.5.3）在完全中文模式下的其它情形类似，我就不多说了

　　2.6）我们接着看为什么在西文DOS窗口下编译出来的类在中文窗口下也出现类似情形，特别是为什么居然有的情形下还能正确显示汉字。

　　2.6.1）我们还是先以代码段9为例：

步骤 内容 地点 说明
01： C1C2 HelloWorld.java C1C2分别泛指一个ISO8859_1字符，“中”字被拆开
02： U3U4 JAVAC读取 U1U2泛指一个Unicode字符
03： C5C6 getBytes()第一步 JAVA先和操作系统交流，这时解析错误
04： B5B6B7B8 getBytes()第二步 然后返回字节数组
05： C5C6 new String()第一步 JAVA先和操作系统交流
06： U3U4 new String()第二步 然后返回字符
07： C5C6 println(String) 虽然同是两个字符，但已不是最初的“两个ISO8859_1字符”，而是“两个BGK字符”，“中”显示成了“？？”而“中文”就显示成了“？？？？”

　　2.6.2）下面我们以代码段12为例，因为它能正确显示汉字

步骤 内容 地点 说明

01： C1C2 HelloWorld.java C1C2分别泛指一个ISO8859_1字符，“中”字被拆开
02： U3U4 JAVAC读取 U1U2泛指一个Unicode字符
03： C1C2 getBytes()第一步 JAVA先和操作系统交流（注意还是正确的哦！）
04： B5B6 getBytes()第二步 然后返回字节数组（这是很关键的一步！）
05： C12 new String()第一步 JAVA先和操作系统交流（这是更关键的一步，JAVA已经知道B5B6要解析成一个汉字！）
06： U7 new String()第二步 然后返回字符（真是一个项两！U7包含了U3U4的信息）
07： C12 println(String) 这就原来的“中”字，很委屈被JAVAC冤枉了一回，不过被程序员拨乱反正了一下！当然，“中文”两个字都能正确显示了！

　　3）那为什么有的时候用JDBC的
new String(Recordset.getBytes(int)[,encode])
Recordset.getSting(int)
Recordset.setBytes(String.getBytes([encode]))
和
Recordset.setString(String)
的时候会出现乱码了呢？

　　其实问题就出现在编写JDBC的的也考虑了编码问题，它从数据库读取数据后，可能自作主张做了一个从GB2312（默认编码）到Unicode的转换，我的这个WebLogic For SQL Server的JDBC Driver就是这样的，当我读字串的时候，发出读到的不是正确的汉字，可恨的是我却可以直接写汉字字串，这让人多少有点难以接受！
　　也就是说，我们不得不在读或写的时候进行转码，尽管这个转码有的时候不是那么明显，这是因为我们使用了默认的编码进行转码。JDBC Driver所做的操作，我们只有进入到源代码内部才能清楚，不是吗？