jsp编码问题new_第1页
jsp编码问题new_第2页
jsp编码问题new_第3页
jsp编码问题new_第4页
jsp编码问题new_第5页
已阅读5页,还剩1页未读 继续免费阅读

下载本文档

版权说明:本文档由用户提供并上传,收益归属内容提供方,若内容存在侵权,请进行举报或认领

文档简介

1、对Java中Unicode、编码的理解Java号称国际化的语言,是因为它的class文件采用UTF-8,而JVM运行时使用UTF-16。因此java用的都是Unicode。unicode 的目标就是能支持世界上所有的字符集,也就是说几乎所有的字符集包含的字符在unicode中都有对应的编码。在unicode中,字符与代码的映射关 系,就是unicode字符集,称为UCS(Unicode Character Set),每个unicode字符编码称为code point(代码点?)。UTF-8和UTF-16是不同的UCS编码方法,UTF就是UCS Transformation Format。;在J

2、ava 中,String的getBytes()方法就是对特定的字符串(unicode)按照给定的字符集进行编码(encode),new String()则可以按照某个字符集将字节流转换回unicode(decode)。Java里面的每一个String都是unicode编码。再来看页面,如果不做特殊处理,Form的提交就按照页面的ContentType设置中的字符集进行编码转换,发送到后台,后台必须利用req.setCharacterEncoding来指定参数的编码格式(不同的应用服务器应有不同的指定方式),才能正确解码。Java 里面的encode和decode都是相对于unicode而言的,

3、encode的意思是将char -> XXX Encoding byte,decode就是由XXX Encoding byte -> char。平常,当我们说“将GBK编码转换为UTF-8编码”的时候,实际的意思就是:GBK Encoding byte -> UTF-8 Encoding byte,这种转换只有在需要用byte传输数据的时候才有意义,否则便是毫无意义的。首先要说明的一点是:Java中的String对象就是一个unicode编码的字符串。但是,我们通常会听到有人说:“我们需要将String由ISO-8859-1转换为GBK编码”,这又是怎么回事呢?实际上,我们并

4、不是要“将 一个由ISO-8859-1编码的String转换为GBK编码的String”,反复说明的是,JAVA中的String都是unicode编码的,所以不存在“ISO- 8859-1编码的String”或“GBK编码的String”这样的说法。而需要转换的唯一的原因是String进行了错误的编码。我们经常会碰到由ISO-8859- 1转换为诸如GBK/UTF-8等等这样的需求。所谓的转换过程是:String -> byte ->String。也许 你非常清楚这个过程的代码:new String(text.getBytes("ISO-8859-1"),&qu

5、ot;GBK")。但是,要真正理解起来并不是那么简单。表面上看似乎很容易理解, 不就是将text String对象按照ISO-8859-1的方式编码为byte然后再把它按照GBK的方式转换为String吗?但是这句代码很容易会被误解为: “将text String由ISO-8859-1转换为GBK编码”,这种说法是错误的。难道你见过用这样的代码:new String(text.getBytes("GBK"),"UTF-8")来对String进行编码转换的吗?之所以你会经常看到new String(text.getBytes("ISO-

6、8859-1"),"GBK")这句代码,是因为一个GBK的字节流被错误地以ISO-8859- 1的方式转换为String(unicode)了!发生这种情况最普遍的地方是一个GBK编码的网页向后台提交数据的时候,就有可能会看到这句代码的出 现。GBK的流被错误的当成ISO8859-1的流,所以便得到了一个错误的String。由于ISO8859-1是单字节编码,所以每个字节被按照原样 转换为String,也就是说,虽然这是一个错误的转换,但编码没有改变,所以我们仍然有机会把编码转换回来!所以那句经典的new String(text.getBytes("ISO

7、-8859-1"),"GBK")便出现了。如果系统误以为是其它编码格式,就有可能再也转换不回来了,因为编码转换并不是负负得正那么简单的% page language="java" pageEncoding="UTF-8"% page contentType="text/html;charset=iso8859-1"%htmlheadtitle中文问题/titlemeta http-equiv="Content-Type" content="text/html; charset

8、=UTF-8"/head/headbody这就是一行中文/body/html 三个地方的编码第一个地方的编码格式为jsp文件的存储格式。Ecljpse会根据这个编码格式保存文件。并编译jsp文件,包括里面的汉字。第二处编码为解码格式。因为存为UTF-8的文件被解码为iso8859-1,这样如有中文肯定出乱码。也就是必须一致。而第二处所在的这一行,可以没有。缺省也是使用iso8859-1的编码格式。所以如果没有这一行的话,“这就是一行中文”也会出现乱码。必须一致才可以。(好像有些版本的Tomcat设置了第一个第二行不用也可以的,大家可以自己试下自己版本是不这样的)第三处编码为控制浏览器

9、的解码方式。如果前面的解码都一致并且无误的话,这个编码格式没有关系。有的网页出现乱码,就是因为浏览器不能确定使用哪种编码格式。因为页面有时候会嵌入页面,导致浏览器混淆了编码格式。出现了乱码。表单使用Post方式提交后接收到的乱码问题这个问题也是一个常见的问题。这个乱码也是tomcat的内部编码格式iso8859-1在捣乱,也就是说post提交时,如果没有设置提交的编码格式,则会以iso8859-1方式进行提交,接受的jsp却以utf-8的方式接受。导致乱码。既然这样的原因,下面有几种解决方式,并比较。a. 接受参数时进行编码转换String str = new String(request.g

10、etParameter("something").getBytes("ISO-8859-1"),"utf-8") ; 这样的话,每一个参数都必须这样进行转码。很麻烦。但确实可以拿到汉字。b. 在请求页面上开始处,执行请求的编码代码request.setCharacterEncoding("UTF-8") 把提交内容的字符集设为UTF8。这样的话,接受此参数的页面就不必在转码了。直接使用String str = request.getParameter("something"); 即可得到汉字参数

11、。但每页都需要执行这句话。这个方法也就对post提交的有效果,对于get提交和上传文件时的enctype="multipart/form-data"是无效的。稍后下面单独对这个两个的乱码情况再进行说明。c. 为了避免每页都要写request.setCharacterEncoding("UTF-8"),建议使用过滤器对所有jsp进行编码处理。这个网上有很多例子。请大家自己查阅。表单get提交方式的乱码处理方式如果使用get方式提交中文,接受参数的页面也会出现乱码,这个乱码的原因也是tomcat的内部编码格式iso8859-1导致。Tomcat会以get的缺

12、省编码方式iso8859-1对汉字进行编码,编码后追加到url,导致接受页面得到的参数为乱码/、。解决办法:a. 使用上例中的第一种方式,对接受到的字符进行解码,再转码。b. Get走的是url提交,而在进入url之前已经进行了iso8859-1的编码处理。要想影响这个编码则需要在server.xml的Connector节点增加useBodyEncodingForURI="true"属性配置,即可控制tomcat对get方式的汉字编码方式,上面这个属性控制get提交也是用request.setCharacterEncoding("UTF-8")所设置的编

13、码格式进行编码。所以自动编码为utf-8,接受页面正常接受就可以了。但我认为真正的编码过程是,tomcat又要根据Connector port="8080"maxThreads="150" minSpareThreads="25" maxSpareThreads="75"enableLookups="false" redirectPort="8443" acceptCount="100"debug="0" connectionTimeo

14、ut="20000" useBodyEncodingForURI="true"disableUploadTimeout="true" URIEncoding=”UTF-8”/ 里面所设置的URIEncoding=”UTF-8”再进行一次编码,但是由于已经编码为utf-8,再编码也不会有变化了。如果是从url获取编码,接受页面则是根据URIEncoding=”UTF-8”来进行解码的。上传文件时的乱码解决上传文件时,form表单设置的都是enctype="multipart/form-data"。这种方式以流方式提交

15、文件。如果使用apach的上传组件,会发现有很多乱码想象。这是因为apach的先期commons-fileupload.jar有bug,取出汉字后进行解码,因为这种方式提交,编码又自动使用的是tomcat缺省编码格式iso-8859-1。但出现的乱码问题是:句号,逗号,等特殊符号变成了乱码,汉字如果数量为奇数,则会出现乱码,偶数则解析正常。解决方式:下载commons-fileupload-1.1.1.jar 这个版本的jar已经解决了这些bug。但是取出内容时仍然需要对取出的字符进行从iso8859-1到utf-8转码。已经能得到正常所有汉字以及字符。Java代码关于url请求,接受参数的乱

16、码url的编码格式,取决于上面所说的URIEncoding=”UTF-8”。如果设定了这个编码格式,则意味着所有到url的汉字参数,都必须进行编码才可以。否则得到的汉字参数值都是乱码,例如一个链接:Response.sendDerect(“/a.jsp?name=张大维”); 而在a.jsp里面直接使用String name = request.getParameter("name"); 得到的就是乱码。因为规定了必须是utf-8才可以,所以,这个转向应该这样写:Response.sendDerect(“/a.jsp?name=URLEncode.encode(“张大维”,

17、”utf-8”); 才可以。如果不设置这个参数URIEncoding=”UTF-8”,会怎么样呢? 不设置则就使用了缺省的编码格式iso8859-1。问题又出来了,第一就是参数值的个数如果是奇数个数,则就可以正常解析,如果使偶数个数,得到最后字符就是乱码。还有就是如果最后一个字符如果是英文,则就能正常解析,但中文的标点符号仍出现乱码。权宜之计,如果您的参数中没有中文标点符号,则可以在参数值最后加一个英文符号来解决乱码问题,得到参数后再去掉这个最后面的符号。也可以凑或使用。脚本代码关于url请求,接受到的参数乱码脚本中也会进行页面转向的控制,也会涉及到附带参数,并在接受页面解析这个参数的情况。如果这个汉字参数不进行URIEncoding=”UTF-8”所指定的编码处理,则接受页面接受到的汉字也是乱码。脚本处理编码比较麻烦,必须有相应的编码脚本对应文件,然后调用脚本中的方法对汉字进行编码即可。关于jsp在MyEclipse中打开的乱码问题对于一个已经存在的项目,Jsp文件的存储格式可能是utf-8。如果

温馨提示

  • 1. 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。图纸软件为CAD,CAXA,PROE,UG,SolidWorks等.压缩文件请下载最新的WinRAR软件解压。
  • 2. 本站的文档不包含任何第三方提供的附件图纸等,如果需要附件,请联系上传者。文件的所有权益归上传用户所有。
  • 3. 本站RAR压缩包中若带图纸,网页内容里面会有图纸预览,若没有图纸预览就没有图纸。
  • 4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
  • 5. 人人文库网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对用户上传分享的文档内容本身不做任何修改或编辑,并不能对任何下载内容负责。
  • 6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
  • 7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

评论

0/150

提交评论