这几天改项目中别人做的模块,一个页面总有乱码,别的就没有问题,改了半天发现
method="get" 晕了,换成post后解决
下面收集一些乱码的问题:
一、避免乱码的一些注意点:
1.尽量使用统一的编码,如果你是重头开发一个系统,特别是Java开发的,推荐从页面到数据库再到配置文件都使用UTF-8进行编码,安全第一。
2.SetCharacterEncodingFilter的使用,这个东西不是万能的,但是没有它就会很麻烦,如果是基于Servlet开发的东西,能用的就给它用上,省心。不过有一个注意的地方,这个Filter只是对POST请求有效,GET一律忽略,不信你可以debug一下,看看它怎么做的,至于为什么不过滤get请求,好象是它对GET请求是无能为力的。
3.就如上面所说,GET请求有问题,尽量使用POST请求,这个也是Web开发的一个基本要领:
Web Health Warning:Put All Destructive Actions Behind a POST method(from Agile Web Development with Rails)
有点扯远了,不过少用GET,是会有回报滴。
4.JavaScript和Ajax乱码的避免,注意JavaScript默认是ISO8859的编码,避免JS/AJAX乱码和GET一样,不要在URL里面使用中文,实在避免不了,就只能在生成链接的时候转码,绝对不能想当然的认为SetCharacterEncodingFilter会帮你做什么事情。
5.尽早统一开发环境,早点模拟真实环境测试,这个好像也有跑题的嫌疑,但凡软件开发都是这么干的,但仍然值得注意。我这出现过一次状况,程序是在Win下编译的,拿去Linux上测试没问题,等实际部署的时候代码是在Linux下编译,结果乱码,秋后算帐总觉得有点晚。
二、乱码发生的情况和应对措施
1.开发环境乱码
由于Java默认使用UTF-8编码,而且网上很多人都建议Struts开发的时候应尽量选用UTF-8做为默认编码,而非GBK。IDE使 用Eclipse,在第一次使用Eclipse的时候应将default text editor改为UTF-8编码,免得日后后悔再改就惨了,我本次开发的时候就忽视了这一点,刚开始没注意,结果到快交工时乱码问题无法解决,导致将所有 的文件全部修改一遍,呜……
自打使用Ubuntu,我就开心的笑阿,再也不用为搞这些乱码问题而烦恼^^(Ubuntu公益广告)
2.POST请求的过滤
这个是最基本的了,每个Servlet系统基本都会用到这个东西。不过只对POST请求有效,这个挺关键的。
使用SetCharacterEncodingFilter,这个很基础的一套过滤器,将所有来自页面的POST请求全部过滤为UTF-8编码。
3. JSP,HTML页面乱码
将JSP页面全部改为charset=UTF-8,这样可以保证与后台交互的时候都是UTF-8编码,一般应用做了以上工作就基本可以应付了。
4.资源文件中汉字转化UTF-8字符问题
国际化问题,在使用资源文件的时候,由于中文在properties文件中无法被程序所识别,需要将其进行转码,我在资源文件下面制作了一个很简单的 bat文件,每次修改资源文件的时候都是在一个临时文件中修改,然后执行这个bat文件,将其转化并保存为所需要的资源文件,这个动作挺烦的,也有项目组 成员使用一些插件,但是那些东西都是直接写UTF-8码的,有时候反倒不方便,不过以后任务量巨大的时候可能会考虑使用。Bat文件内容: set path=%path%;%JAVA_HOME%/bin/,native2ascii -encoding UTF-8 ApplicationResources_bk.txt > ApplicationResources_zh.properties
PS:上面的方法好老了,实际操作起来相当麻烦,现在基本都是使用Eclipse插件,Eclipse3.1时使用propertyeditor,但是这 个项目看上去好像停摆了,到Eclipse3.2时改用了ResourseBundle,相当的强劲的一个插件,推荐使用。
5. GET请求乱码
如果在本项目中采用了get方式提交请求并附加参数,结果导致编码乱码,原因是Tomcat默认请求编码是ISO8859,需要在Tomcat的配置文件 server.xml添加一个参数,URIEncoding=”UTF-8”,这样请求中附件的参数就会以UTF-8来进行编码。
6.Ajax请求乱码
使用Ajax,JS也是默认使用ISO8859编码,所以在进行请求时遇到中文参数需要进行编码,如:var url = "GetSelectListAction.do?queryData=subTrade" + "&queryId=" + encodeURI(obj.value) + "&r=" + Math.random();
这里有两个地方需要注意:第一个地方是encodeURI(),方法,可以将参数进行转码,默认是转化为UTF-8,如果需要转为其他码制,需要在方法中添加第二个参数。
第二个地方是Math.random(),由于Ajax有缓存机制,在接受请求的时候第一时间先判断该请求的地址是否被访问过,如果被访问过则 直接使用缓存中的内容返回,这个东西很讨厌,客户在访问过一次出错后以后每次出现的都是这个错误,所以在请求中给其增加一个时间戳,只要可以随机生成一个 不同的字串就可以,保证Ajax每次都去访问服务器。
7. GET方法的另一个乱码问题
在项目即将交工的时候突然又出现乱码问题,发现对于超长的汉字做为参数传递仍然会出现乱码问题,解决方法是采用java.net.URLEncoder的 Encode方法强制转码,缺点是会使JSP页面代码相当的长,但是目前还没有其他好的解决办法,我想最好的办法就是不用中文做为参数传递 :P,写法如:<a href="TestAction.do?name=<%= java.net.URLEncoder.encode("你好","UTF-8")%>
8.乱码仍然是偶们的心病,一直牵动着大家的心,最近一位朋友说连接MSsql数据库有乱码,使用了很多办法,都没解决,后来重新下了个新的驱动搞定……
数据库乱码其实也很讨厌的,一般来说驱动问题比较常见,所以一旦碰到比较难缠的乱码可以先考虑下换换驱动。也有如MysqL这种,直接连接的时候就需要显示进行编码转化的,这个就要不同情况区别对待了。
//2007年11月30日添加
9.WebService乱码,由于对WebService不怎么熟悉,使用的是Weblogic提供的WebService支持,乱码再次出现搞得手忙脚乱,而且无从下手,在自己系统上跑都没有问题,结果跑到服务器上就全乱套,又无法调试,愁人。
反复尝试的过程就不说了,绝对比普通的Web开发麻烦的多。最终解决方法:
A.为WebService服务也加上一个filter,WebService也是走HTTP协议的,这个东西同样有用,先得加上。
B.修改服务器上的环境变量,LANG=zh_CN.UTF-8,改成这个是为什么我仍然说的不是很清楚,不过当时开发人员就是在Win下开发的,我在自己的Ubuntu上测试没问题,拿到Redhat服务器上就不行,因为服务器上默认的是LANG=en_US.UTF-8,这个明显是不支持汉字的。
经过这两个步骤WebService乱码总算得到抑制,它主要的麻烦在于所有与协议有关的东西都被Weblogic包办,里面做什么事情我们不好控制,所以只能采取这种比较笨的办法,虽然解燃煤之急但无法寻根溯源的搞定它,说不定哪天又会出来搞鬼。果然又一次出现乱码问题,经过比较环境变量发现服务器上的LC_CTYPE被修改了,所以强制改成LC_CTYPE=zh_CN。修改环境变量的方法不到万不得已不推荐使用。
任意给定的3个汉字
=>UTF-8使用9个bytes编码之(123|456|789)
=>这9个bytes通过网络传给tomcat
=>tomcat认为这9个字节是gbk编码(因为你配置了tomcat)
=>gbk汉字编码规则12|34|56|78|9
=>构建string时至少最后一个字节不能正确解析为汉字,此时使用?代替
=>在对这个至少带一个问号的string.getBytes("gbk")时,肯定将出现问号ascii码(63)的byte
=>以utf-8构造string时,遇到63的地方肯定输出?
=>产生了你说的现象
- public static void main(String[] args) throws UnsupportedEncodingException {
- //给定某3个汉字
- String src = "你好啊";
- //String src = "一二三";
- //浏览器进行utf-8编码,并传送到服务器
- byte[] bytes1 = src.getBytes("utf-8");
- System.out.println(bytes1.length);//9
- //tomcat以gbk方式解码(这个片段的说明仅针对gbk处理汉字的情况)
- //如果一对汉字字节不符合gbk编码规范,则每个字节使用'?'(ascii 63)代替
- //万幸的话,只是最后一个(第9个)字节因不能成对,变成问号(比如当src="你好啊"时)
- //不幸的话,中间某些字节就通不过gbk编码规范出现'?'了(比如当src="一二三"时)
- //总之temp的最后一位必定是问号'?'
- String temp = new String(bytes1, "gbk");
- //你的action中的代码
- //由于以上的tomcat以gbk解释utf-8不能成功
- //所以此时bytes2和bytes1不一样
- byte[] bytes2 = temp.getBytes("gbk");
- System.out.println(bytes2.length);
- for (int i = 0; i < bytes1.length; i++) {
- System.out.print(bytes1[i] & 0xff);
- System.out.print("/t");
- }
- System.out.println();
- for (int i = 0; i < bytes2.length; i++) {
- System.out.print(bytes2[i] & 0xff);
- System.out.print("/t");
- }
- System.out.println();
- //构建出来的dest自然不是原先的src
- String dest = new String(bytes2, "utf-8");
- System.out.println(dest);
- }
src等于"你好啊"时:
- 9
- 9
- 228 189 160 229 165 189 229 149 138
- 228 189 160 229 165 189 229 149 63
- 你好??
src等于"一二三"时:
- 9
- 8
- 228 184 128 228 186 140 228 184 137
- 228 184 63 186 140 228 184 63
- ??????
都是网上找的资料,感谢原作者
版权声明:本文内容由互联网用户自发贡献,该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 [email protected] 举报,一经查实,本站将立刻删除。