java字符编码..doc

java 字符编码.txt等待太久得来的东西多半已经不是当初自己想要的了。一层秋雨一阵凉，一瓣落花一脉香，一样流年自难忘，一把闲愁无处藏。幸福生活九字经：有希望，有事干，有人爱。女人和女人做朋友，要之以绿叶的姿态，同时也要暗藏红花的心机。 String newStr = new String(oldStr.getBytes(), UTF-8); java中的String类是按照unicode进行编码的，当使用String(byte[] bytes, String encoding)构造字符串时，encoding所指的是bytes中的数据是按照那种方式编码的，而不是最后产生的String是什么编码方式，换句话说，是让系统把bytes中的数据由encoding编码方式转换成unicode编码。如果不指明，bytes的编码方式将由jdk根据操作系统决定。 当我们从文件中读数据时，最好使用InputStream方式，然后采用String(byte[] bytes, String encoding)指明文件的编码方式。不要使用Reader方式，因为Reader方式会自动根据jdk指明的编码方式把文件内容转换成unicode 编码。 当我们从数据库中读文本数据时，采用ResultSet.getBytes()方法取得字节数组，同样采用带编码方式的字符串构造方法即可。 ResultSet rs; bytep[] bytes = rs.getBytes(); String str = new String(bytes, gb2312); 不要采取下面的步骤。 ResultSet rs; String str = rs.getString(); str = new String(str.getBytes(iso8859-1), gb2312); 这种编码转换方式效率底。之所以这么做的原因是，ResultSet在getString()方法执行时，默认数据库里的数据编码方式为 iso8859-1。系统会把数据依照iso8859-1的编码方式转换成unicode。使用str.getBytes(iso8859-1)把数据还原，然后利用new String(bytes, gb2312)把数据从gb2312转换成unicode，中间多了好多步骤。 从HttpRequest中读参数时，利用reqeust.setCharacterEncoding()方法设置编码方式，读出的内容就是正确的了。 先说Java。 JVM里面的任何字符串资源都是Unicode，就是说，任何String类型的数据都是Unicode编码。没有例外。既然只有一种编码，那么，我们可以这么说，JVM里面的String是不带编码的。String相当于 char[]。 JVM里面的 byte[] 数据是带编码的。比如，Big5，GBK，GB2312，UTF-8之类的。 一个GBK编码的byte[] 转换成 String，其实就是从GBK编码向Unicode编码转换。 一个String转换成一个Big5编码的byte[]，其实就是从Unicode编码向Big5编码转换。 所以，Unicode是所有编码转换的中间介质。所有的编码都有一个转换器可以转换到Unicode，而Unicode也可以转换到其他所有的编码。这样构成了一个总线结构。 比如，如果总共有10种编码，那么只需要 10 + 10 = 20个转换器就够了。如果要是两两直接转换，那么，需要的转换器数量是一个组合数字，需要90个转换器。 一个系统的不同部分，都有自己的编码。比如，数据库，文件，JVM，浏览器这4个部分。 在这些部分之间数据交换的地方，就会出现编码问题。比如，数据库和JVM之间，文件和JVM之间，浏览器和JVM之间。这些问题的原理都是相通的。 编码问题最容易处理的地方是文件和JVM之间。文件IO API带有encoding 参数，请自行查阅。 最不容易出现编码问题的地方是数据库和JVM之间。这应该是数据库JDBC连接的基本功能。本文不专门进行讨论。 最容易出问题的地方是浏览器和服务器JVM之间（其实，代码里面的字符串更容易出问题，不过，我已经事先声明，本文不讨论代码中的字符串编码）。下面主要讨论这块浏览器和服