String(bytes[,encode])中，系统认为输入的是编码为encode的字节流，换句话说，如果按encode来翻译bytes才能得到正确的结果，这个结果最后要在JAVA中保存，它还是要从这个encode转换成Unicode，也就是说有bytes-->encode字符-->Unicode字符的转换；而在String.getBytes([encode])中，系统要做一个Unicode字符-->encode字符-->bytes的转换。
在这个例子中，除那个英文窗口编码的时候除外，其实情形下默认编码都是GBK（在本例中，我们暂且把GBK和GB2312等同看待）。
2.4）由于在未指明在上面的两个用代码实现的转换中，如果未指定encode，系统将采用默认的编码（这里为GBK），我们认为上面的5,6,7和8,9,10是一样的，8和9、11和12也是一样的，所以我们在讨论中将只讨论1,9,10,12,13。其中的2,3,4只是用于测试，不在我们的讨论范围之内。
2.5）下面我们来跟踪程序中的“中”字的转换历程，我们先说在中文窗口下作的编译和运行过程，注意在下面的字母下标中，我有意识地使用了一些数字，以表示相同，相异还是相关2.5.1)我们先以上面的13个代码段中的的代码9为例：
步骤 内容 地点 说明
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所做的操作，我们只有进入到源代码内部才能清楚，不是吗？
在这个例子中，除那个英文窗口编码的时候除外，其实情形下默认编码都是GBK（在本例中，我们暂且把GBK和GB2312等同看待）。
2.4）由于在未指明在上面的两个用代码实现的转换中，如果未指定encode，系统将采用默认的编码（这里为GBK），我们认为上面的5,6,7和8,9,10是一样的，8和9、11和12也是一样的，所以我们在讨论中将只讨论1,9,10,12,13。其中的2,3,4只是用于测试，不在我们的讨论范围之内。
2.5）下面我们来跟踪程序中的“中”字的转换历程，我们先说在中文窗口下作的编译和运行过程，注意在下面的字母下标中，我有意识地使用了一些数字，以表示相同，相异还是相关2.5.1)我们先以上面的13个代码段中的的代码9为例：
步骤 内容 地点 说明
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所做的操作，我们只有进入到源代码内部才能清楚，不是吗？
相关文章
 我来说两句 |
对此文章发表了评论 |
评论列表 （最新 评论仅限网友观点！）
推荐文章
