jsp的乱码问题处理.docx
- 文档编号:25453843
- 上传时间:2023-06-08
- 格式:DOCX
- 页数:17
- 大小:27.14KB
jsp的乱码问题处理.docx
《jsp的乱码问题处理.docx》由会员分享,可在线阅读,更多相关《jsp的乱码问题处理.docx(17页珍藏版)》请在冰豆网上搜索。
jsp的乱码问题处理
2表单使用Post方式提交后接收到的乱码问题
这个问题也是一个常见的问题。
这个乱码也是tomcat的内部编码格式iso8859-1在捣乱,也就是说post
提交时,如果没有设置提交的编码格式,则会以iso8859-1方式进行提交,接受的jsp却以utf-8的方式
接受。
导致乱码。
既然这样的原因,下面有几种解决方式,并比较。
A接受参数时进行编码转换
Stringstr=newString(request.getParameter("something").getBytes("ISO-8859-1"),"utf-8")
;这样的话,每一个参数都必须这样进行转码。
很麻烦。
但确实可以拿到汉字。
B在请求页面上开始处,执行请求的编码代码,request.setCharacterEncoding("UTF-8"),把提交内
容的字符集设为UTF-8。
这样的话,接受此参数的页面就不必在转码了。
直接使用
Stringstr=request.getParameter("something");即可得到汉字参数。
但每页都需要执行这句话。
这个方法也就对post提交的有效果,对于get提交和上传文件时的enctype="multipart/form-data"是无
效的。
稍后下面单独对这个两个的乱码情况再进行说明。
C为了避免每页都要写request.setCharacterEncoding("UTF-8"),建议使用过滤器对所有jsp
进行编码处理。
这个网上有很多例子。
请大家自己查阅。
3表单get提交方式的乱码处理方式。
如果使用get方式提交中文,接受参数的页面也会出现乱码,这个乱码的原因也是tomcat的内部编码格
式iso8859-1导致。
Tomcat会以get的缺省编码方式iso8859-1对汉字进行编码,编码后追加到url,导致
接受页面得到的参数为乱码/、。
解决办法:
A使用上例中的第一种方式,对接受到的字符进行解码,再转码。
BGet走的是url提交,而在进入url之前已经进行了iso8859-1的编码处理。
要想影响这个编码则需要在
server.xml的Connector节点增加useBodyEncodingForURI="true"
属性配置,即可控制tomcat对get方式的汉字编码方式,上面这个属性控制get提交也是用
request.setCharacterEncoding("UTF-8")所设置的编码格式进行编码。
所以自动编码为utf-8,接受页
面正常接受就可以了。
但我认为真正的编码过程是,tomcat又要根据
maxThreads="150"minSpareThreads="25"maxSpareThreads="75" enableLookups="false"redirectPort="8443"acceptCount="100" debug="0"connectionTimeout="20000"useBodyEncodingForURI="true" disableUploadTimeout="true"URIEncoding=”UTF-8”/> 里面所设置的URIEncoding=”UTF-8”再进行一次编码,但是由于已经编码为utf-8,再编码也不会有变 化了。 如果是从url获取编码,接受页面则是根据URIEncoding=”UTF-8”来进行解码的。 4上传文件时的乱码解决 上传文件时,form表单设置的都是enctype="multipart/form-data"。 这种方式以流方式提交文件。 如果使用apach的上传组件,会发现有很多乱码想象。 这是因为apach的先期commons-fileupload.jar有 bug,取出汉字后进行解码,因为这种方式提交,编码又自动使用的是tomcat缺省编码格式iso-8859-1 。 但出现的乱码问题是: 句号,逗号,等特殊符号变成了乱码,汉字如果数量为奇数,则会出现乱码 ,偶数则解析正常。 解决方式: 下载commons-fileupload-1.1.1.jar这个版本的jar已经解决了这些bug。 但是取出内容时仍然需要对取出的字符进行从iso8859-1到utf-8转码。 已经能得到正常所有汉字以及字 符。 5Java代码关于url请求,接受参数的乱码 url的编码格式,取决于上面所说的URIEncoding=”UTF-8”。 如果设定了这个编码格式,则意味着所 有到url的汉字参数,都必须进行编码才可以。 否则得到的汉字参数值都是乱码,例如 一个链接Response.sendDerect(“/a.jsp? name=张大维”);而在a.jsp里面直接使用 Stringname");得到的就是乱码。 因为规定了必须是utf-8才可以,所以,这个转向应该这样写: Response.sendDerect(“/a.jsp? name=URLEncode.encode(“张大维”,”utf-8”);才可以。 如果不设置这个参数URIEncoding=”UTF-8”,会怎么样呢? 不设置则就使用了缺省的编码格式 iso8859-1。 问题又出来了,第一就是参数值的个数如果是奇数个数,则就可以正常解析,如果使偶数 个数,得到最后字符就是乱码。 还有就是如果最后一个字符如果是英文,则就能正常解析,但中文的标 点符号仍出现乱码。 权宜之计,如果您的参数中没有中文标点符号,则可以在参数值最后加一个英文符 号来解决乱码问题,得到参数后再去掉这个最后面的符号。 也可以凑或使用。 6脚本代码关于url请求,接受到的参数乱码 脚本中也会进行页面转向的控制,也会涉及到附带参数,并在接受页面解析这个参数的情况。 如果这个 汉字参数不进行URIEncoding=”UTF-8”所指定的编码处理,则接受页面接受到的汉字也是乱码。 脚本 处理编码比较麻烦,必须有相应的编码脚本对应文件,然后调用脚本中的方法对汉字进行编码即可。 7关于jsp在MyEclipse中打开的乱码问题 对于一个已经存在的项目,Jsp文件的存储格式可能是utf-8。 如果新安装的eclipse,则缺省打开使用 的编码格式都是iso8859-1。 所以导致jsp里面的汉字出现乱码。 这个乱码比较容易解决,直接到 eclipse3.1的偏好设置里面找到general-〉edidor,设置为您的文件打开编码为utf-8即可。 Eclipse会 自动重新以新的编码格式打开。 汉字即可正常显示。 8关于html页面在eclipse中打开出现乱码情况 由于大部分页面都是由dreamweaver制作,其存储格式跟eclipse的识别有差别导致。 一般这种情况,在eclipse中新建一个jsp,直接从dreamweaver复制页面内容粘贴到jsp即可。 ////////////////////////////////////////////////////////////////////////////////////////// jsp中文乱码问题的解决办法jsp中java中文编码问题的个人经验|终于看到一个完全解决的方案 四月5th,2006 ==================== ======= 开发java应用出现乱码是很常见的,毕竟现在unicode的使用还不是很广泛,在使用gb2312(包含了gbk 简体,big5繁体)的系统中要正确实现 中文的display和数据库的存储是最基本的要求。 ======================== 1,首先developer要明确自己为什么会遇到乱码,遇到什么样的乱码(无意义的符号还是一串问号或者 其它什么东西)。 新手遇到一堆很乱的字符时通常不知所措,最直接的反映就是打开google搜索”java中文”(这个字符 串在搜索引擎上的查询频率非常高), 然后一个一个的去看别人的解决方法。 这样做没有错,但是很难达到目的,原因下面会提到。 总之,出现乱码的原因是非常多的,解决的方法也完全不一样,要解决问题必须先分析自己的”上下文 环境”。 ======================== 2,具体说来,需要哪些信息才能确定项目中的乱码的根源。 a,开发者所用的操作系统 b,j2ee容器的名称,版本 c,数据库的名称,版本(精确版本)以及jdbc驱动的版本 d,出现乱码的sourcecode(比如是systemout出来的,还是jsp页面中的,如果是jsp中的,那么头 部声明的情况也很重要) ========================= 3,如何初步分析乱码出现的原因。 有了上述的信息,基本上就可以发帖求助了,相信放到javaworld等论坛上,很快就会有高手给你提出 有效的解决方案的。 当然不能总靠发帖求助,也要试试自行解决问题。 如何下手呢? a,分析一下你的”乱码”到底是什么编码。 这个其实不难,比如 System.out.println(testString); 这一段出现了乱码,那么不妨用穷举法猜测一下它的实际编码格式。 System.out.println(newString(testString.getBytes(”ISO-8859-1〃),”gb2312〃)); System.out.println(newString(testString.getBytes(”UTF8〃),”gb2312〃)); System.out.println(newString(testString.getBytes(”GB2312〃),”gb2312〃)); System.out.println(newString(testString.getBytes(”GBK”),”gb2312〃)); System.out.println(newString(testString.getBytes(”BIG5〃),”gb2312〃)); 等等,上述代码的意思是用制定的编码格式去读取testString这个”乱码”,并转换成gb2312(此处仅 以中文为例) 然后你看哪一个转换出来的结果是ok的,那就。 。 。 b,如果用上面的步骤能得到正确的中文,说明你的数据肯定是在的,只不过是界面中没有正确显示而 已。 那么第二步就该纠正你的view部分了 ,通常需要检查的是jsp中是否选择了正确的页面编码。 在此要声明被很多人误解的一点,那就是<%@pagecontentType=”text/html;charset=GB2312〃%> 指令和 content=”text/html;charset=gb2312〃>两者的不同。 通常网上的很多文章在提到中文问题时都是说 数据库中选择unicode或者gb2312存储,同 时在jsp中用page指令声明编码就可以解决。 但是我觉得这种说法很不负责任,害的我费了N多时间为本 来并不存在的乱码而郁闷。 实际上page 的作用是在jsp被编译成为html的过程中提供编码方式让java来”读取”表达式当中的String(有点类 似于上面的第三个语句的作用),而meta 的作用是众所周知的为IE浏览器提供编码选择,是用来”显示”最后的数据的。 但是没有看到有人提醒 这一点,我一直把page当成meta在用, 导致本来是iso-8859的数据,被page指令读成gb2312,于是乱码,所以又加了编码转化的函数把所有的 string数据都从iso8859转到gb2312(为 什么这么转,当时也没考虑这么多,因为这么做可以正常显示了,所以就这么改了,呵呵当时实在没有 时间慢慢排查问题了)。 =========================== === 4,数据库选择什么样的编码比较好。 目前流行的DB主要有sqlserver,mysql,oracle,DB2等,其中mysql作为免费DB中的老大,性能和功 能是得到公认的,安装配置比较方便,相 应的driver也比较完善,性价比是绝对的OK。 所以就以mysql为例。 我个人建议采用mysql的默认编码来存储,也就是iso-8859-1(在mysql的选项中对应于latin-1)。 理 由主要有这么几个,一是iso-8859-1对中 文的支持不错;二是跟java中的默认编码一致,至少在很多地方免除了转换编码的麻烦;三是默认的比 较稳定,兼容性也更好,因为多编码的 支持是由具体的DB产品提供的,别说跟其它的DB会不兼容,即使自身的不同版本也可能出现兼容性的问 题。 例如mysql4.0以前的产品中,很多中文的解决方案是利用connection中的characterEncoding字段来制 定编码,比如gb2312什么的,这样是ok 的,因为原数据都是ISO8859_1编码,jdbc驱动会采用url里面指定的characterset来进行编码, resultSet.getString(*)取出的就是编码后的 字符串。 这样就直接拿到gb2312的数据了。 但是mysql4.1的推出给很多dbadmin带来了不小的麻烦,因为mysql4.1支持columnlevel的character set,每个table,column都可以指定编码 ,不指定就是ISO8895_1,因此jdbc取出数据后会根据column的characterset来进行编码,而不再是用 一个全局的参数来取所有的数据了。 这从另一个方面也说明了乱码问题的产生实在是很复杂的事情,原因太多了。 我也只是针对自己遇 //////////////////////////////////////////////////////////////////////////////////////// jsp中文问题解决之道[转载] 和Java一样,JSP是目前比较热门的一个话题。 它是一种在服务器端编译执行的Web设计语言,因为脚本 语言采用了Java,所以JSP继承了Java的所有优点。 可是在使用JSP程序的过程中,常遇到中文乱码问题 ,很多人为此头疼不已,初学的时候我就深受其害,而且使用平台不同,中文乱码问题的解决方法也不 同,无形中增加了学习JSP的难度。 其实,在彻底了解相关原因后,问题还是比较容易解决的。 ,以下 是我总结的解决方法,相信对读者会有一定的借鉴意义。 (因为我使用得最多的是Tomcat环境,所以 主要是以Tomcat为例,其它的环境只会提及一下,但解决办法也是差不多的! 每个国家(或区域)都规定了计算机信息交换用的字符编码集,如美国的扩展ASCII码、中国的GB2312 -80、日本的JIS等,作为该国家(区域)信息处理的基础,有着统一编码的重要作用。 由于各本地字 符集代码范围重叠,相互间信息交换困难,软件本地化版本独立维护成本较高。 因此有必要将本地化工 作中的共性抽取出来,做一致性处理,将特殊的本地化处理内容降低到最少,这就是所谓的国际化 (I18N)。 各种语言信息被规范为本地信息,而底层字符集采用包含了所有字符的Unicode。 相信了解JSP代码的读者对ISO8859-1一定不陌生,ISO8859-1是我们平时使用比较多的一个CodePage, 它属于西欧语系。 GB2312-80是在国内计算机汉字信息技术发展初始阶段制订的,其中包含了大部分 常用的一、二级汉字和9区的符号。 该字符集是几乎所有的中文系统和国际化的软件都支持的中文字符 集,这也是最基本的中文字符集。 GBK是GB2312-80的扩展,是向上兼容的。 它包含了20902个汉字,其编码范围是0x8140~ 0xFEFE,剔除高位0x80的字位,其所有字符都可以一对一映射到Unicode2.0,也就是说Java 实际上提供了对GBK字符集的支持。 >GB18030-2000(GBK2K)在GBK的基础上进一步扩展了汉字,增加了藏、蒙等少数民族的文字。 GBK2K从根本上解决了字位不够、字形不足的问题。 1.Tomcat4开发平台 这个版本应该是我们经常用到的版本,所以讨论得会比较详细。 Windows98/2000下的Tomcat4以上版本都会出现中文问题(而在Linux下和Tomcat3.x中则没有问 题),主要表现是页面显示乱码。 为解决这个问题,最简单的方法就是在每个JSP的页面开始处加上<%@pagelanguage=“Java” contentType=“text/html;charset=gb2312”%>。 不过,这还不够,虽然这时显示了中文,但是发现 从数据库读出的字段变成了乱码。 经过分析发现: 在数据库中保存的中文字符是正常的,数据库用 ISO8859-1字符集存取数据,而Java程序在处理字符时默认采用统一的ISO8859-1字符集(这也体现了 Java国际化思想),所以在数据添加的时候Java和数据库都是以ISO8859-1方式处理,这样不会出错。 但 是在读取数据的时候就出现问题了,因为数据读出也采用ISO8859-1字符集,而JSP的文件头中有语句 <%@pagelanguage=“Java”contentType=“text/html;charset=gb2312”%>,这说明页面采用 GB2312的字符集显示,这样就和读出的数据不一样。 这时页面显示从数据库中读出的字符是乱码,解决 的方法是对这些字符转码,从ISO8859-1转成GB2312,就可以正常显示了。 这个解决办法对很多平台具 有通用性,读者可以灵活运用。 具体的方法会在以下详细讲解。 另外,对于不同的数据库如SQL Server,Oracle,Mysql,Sybase等,字符集的选择很重要。 如果考虑多语言版本,数据库的字符集就 应该统一采用ISO8859-1,需要输出的时候在不同的字符集之间做转换就可以了。 以下是针对不同平台的总结: (1)JSWDK只适合于普通开发,稳定性和其他问题可能不如商业软件。 由于JDK1.3版性能要好于 JDK1.2.2很多,并且对中文的支持也较好,所以应该尽量采用。 现在jdk已经出到1.4版本了,所以 如果允许最好升级到最新的版本,这样对中文的也会较好,而且还可以得到更多的支持。 (2)Tomcat仅仅是一个对JSP1.1、Servlet2.2标准的实现,我们不应该要求这个免费软件在细节 和性能上都面面俱到,它主要考虑英文用户,这也是为什么不做特殊转换,汉字用URL方法传递就有 问题的原因。 大部分IE浏览器缺省始终以UTF-8发送,这似乎是Tomcat的一个不足,另外Tomcat不管 当前的操作系统是什么语言,都按ISO8859去编译JSP,似乎也欠妥。 2.JSP代码的中文处理 (1)如果与数据无关的操作,可以在页面首行加入 (2)将Form中的值传送到数据库中再取出来后全变成了“? ”。 Form用POST提交数据,代码中使用了语 句: Stringst=new(request.getParameter(“name”).getBytes(“ISO8859_1”)),而且也声明了 charset=gb2312。 要处理Form中传递的中文参数,应该在JSP中加入下面的代码,另外定义一个专门解决这个问题的 getStr类,然后对接收到的参数进行转换: Stringkeyword1=request.getParameter(“keyword1”); keyword1=getStr(keyword1); 这样就可以解决问题了,代码如下: <%@pagecontentType=“text/html;charset=gb2312”%> <%! publicStringgetStr(Stringstr){ try{Stringtemp_p=str; byte[]temp_t=temp_p.getBytes(“ISO8859-1”); Stringtemp=newString(temp_t); returntemp; } catch(Exceptione){} return“NULL”; } %> <%--测试--%> <%Stringkeyword=“创联网络技术中心欢迎您的到来”; Stringkeyword1=request.getParameter(“keyword1”); keyword1=getStr(keyword1); out.print(keyword); out.print(keyword1); %> 另外,流行的关系数据库系统都支持数据库Encoding,也就是说在创建数据库时可以指定它自己的字符 集设置,数据库的数据以指定的编码形式存储。 当应用程序访问数据时,在入口和出口处都会有 Encoding转换。 对于中文数据,数据库字符编码的设置应当保证数据的完整性。 GB2312、GBK、 UTF-8等都是可选的数据库Encoding,也可以选择ISO8859-1(8-bit),但会增加了编程的复 杂度,ISO8859-1不是推荐的数据库Encoding。 在JSP/Servlet编程时,可以先用数据库管理系统提供 的管理功能检查其中的中文数据是否正确。 (3)JDBCDriver的字符转换 目前大多数JDBCDriver采用本地编码格式来传输中文字符,例如中文字符“0x4175”会被转成“0x41 ”和“0x75”进行传输。 因此需要对JDBCDriver返回的字符以及要发给JDBCDriver的字符进行转换 。 当用JDBCDriver向数据库中插入数据时,需要先将Unicode转成Nativecode;当JDBCDriver 从数据库中查询数据时,则需要将Nativecode转换成Unicode。 下面给出了这两种转换的实现: Stringnative2Unicode(Strings){ if(s==null||s.length()==0){ returnnull; } byte[]buffer=newbyte[s.length()]; for(inti=0;is.length();i++){if(s.charAt(i)>=0x100){ c=s.charAt(i); byte[]buf=(“”+c).getBytes(); buffer[j++]=(char)buf[0]; buffer[j++]=(char)buf[1];
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- jsp 乱码 问题 处理