[生活]java+字符编码.doc

[生活]java字符编码java字符编码StringnewStr=newString((),"UTF-8");java中的String类是按照unicode进行编码的,当使用String(byte[]bytes,Stringencoding)构造字符串时,encoding所指的是bytes中的数据是按照那种方式编码的,而不是最后产生的String是什么编码方式,换句话说,是让系统把bytes中的数据由encoding编码方式转换成unicode编码。如果不指明,bytes的编码方式将由jdk根据操作系统决定。当我们从文件中读数据时,最好使用InputStream方式,然后采用String(byte[]bytes,Stringencoding)指明文件的编码方式。不要使用Reader方式,因为Reader方式会自动根据jdk指明的编码方式把文件内容转换成unicode编码。当我们从数据库中读文本数据时,()方法取得字节数组,同样采用带编码方式的字符串构造方法即可。ResultSetrs;bytep[]bytes=();Stringstr=newString(bytes,"gb2312");不要采取下面的步骤。ResultSetrs;Stringstr=();str=newString(("iso8859-1"),"gb2312");这种编码转换方式效率底。之所以这么做的原因是,ResultSet在getString()方法执行时,默认数据库里的数据编码方式为iso8859-1。系统会把数据依照iso8859-1的编码方式转换成unicode。("iso8859-1")把数据还原,然后利用newString(bytes,"gb2312")把数据从gb2312转换成unicode,中间多了好多步骤。从HttpRequest中读参数时,()方法设置编码方式,读出的内容就是正确的了。先说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之间。文件IOAPI带有encoding参数,请自行查阅。最不容易出现编码问题的地方是数据库和JVM之间。这应该是数据库JDBC连接的基本功能。本文不专门进行讨论。最容易出问题的地方是浏览器和服务器JVM之间(其实,代码里面的字符串更容易出问题,不过,我已经事先声明,本文不讨论代码中的字符串编码)。下面主要讨论这块浏览器和服务器JVM之间的编码问题。我们把浏览器编码叫做Browser_Charset,把JVM编码叫做JVM_Charset(通常等于服务器系统编码)。当浏览器的数据过来的时候,是一个带有Browser_Charset的byte[]。如果用户处理程序需要一个String类型的数据,那么JVM会好心好意地把这个byte[]转换成String。使用的转换器是JVM_Charset->Unicode。注意,如果这个时候,Browser_Charset和JVM_Charset并不相等。那么,这个自动转换是错误的。为了弥补这个错误。我们需要做两步工作。(1)Unicode->JVM_Charset,把这个String转换回到原来的byte[]。(2)Browser_Charset->Unicode,把这个还原的byte[]转换成String。这个效果,和