开发java应用出现乱码是很常见的,毕竟现在unicode的使用还不是很广泛,在使用gb2312(包含了gbk简体,big5繁体)的系统中要正确实现 中文的display和数据库的存储是最基本的要求。 ============================== 1,首先developer要明确自己为什么会遇到乱码,遇到什么样的乱码(无意义的符号还是一串问号或者其它什么东西)。 新手遇到一堆很乱的字符时通常不知所措,最直接的反映就是打开google搜索”java中文”(这个字符串在搜索引擎上的查询频率非常高), 然后一个一个的去看别人的解决方法。这样做没有错,但是很难达到目的,原因下面会提到。 总之,出现乱码的原因是非常多的,解决的方法也完全不一样,要解决问题必须先分析自己的”上下文环境”。 ============================ 2,具体说来,需要哪些信息才能确定项目中的乱码的根源。 a,开发者所用的操作系统 b,j2ee容器的名称,版本 c,数据库的名称,版本(精确版本)以及jdbc驱动的版本 d,出现乱码的source code(比如是system out 出来的,还是jsp页面中的,如果是jsp中的,那么头部声明的情况也很重要) =========================================================== 3,如何初步分析乱码出现的原因。 有了上述的信息,基本上就可以发帖求助了,相信放到javaworld等论坛上,很快就会有高手给你提出有效的解决方案的。 当然不能总靠发帖求助,也要试试自行解决问题。如何下手呢? a,分析一下你的”乱码”到底是什么编码。这个其实不难,比如 System.out.println(testString); 这一段出现了乱码,那么不妨用穷举法猜测一下它的实际编码格式。 System.out.println(new String(testString.getBytes(”ISO-8859-1″),”gb2312″)); System.out.println(new String(testString.getBytes(”UTF8″),”gb2312″)); System.out.println(new String(testString.getBytes(”GB2312″),”gb2312″)); System.out.println(new String(testString.getBytes(”GBK”),”gb2312″)); System.out.println(new String(testString.getBytes(”BIG5″),”gb2312″)); 等等,上述代码的意思是用制定的编码格式去读取testString这个”乱码”,并转换成gb2312(此处仅以中文为例) 然后你看哪一个转换出来的结果是ok的,那就。。。 b,如果用上面的步骤能得到正确的中文,说明你的数据肯定是在的,只不过是界面中没有正确显示而已。那么第二步就该纠正你的view部分了 ,通常需要检查的是jsp中是否选择了正确的页面编码。 在此要声明被很多人误解的一点,那就是<%@ page contentType=”text/html; charset=GB2312″ %>指令和<META http-equiv=Content-Type 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主要有sql server,mysql,oracle,DB2等,其中mysql作为免费DB中的老大,性能和功能是得到公认的,安装配置比较方便,相 应的driver也比较完善,性价比是绝对的OK。所以就以mysql为例。 我个人建议采用mysql的默认编码来存储,也就是iso-8859-1(在mysql的选项中对应于latin-1)。理由主要有这么几个,一是iso-8859-1对中 文的支持不错;二是跟java中的默认编码一致,至少在很多地方免除了转换编码的麻烦;三是默认的比较稳定,兼容性也更好,因为多编码的 支持是由具体的DB产品提供的,别说跟其它的DB会不兼容,即使自身的不同版本也可能出现兼容性的问题。 例如mysql 4.0以前的产品中,很多中文的解决方案是利用connection中的characterEncoding字段来制定编码,比如gb2312什么的,这样是ok 的,因为原数据都是ISO8859_1编码,jdbc驱动会采用url里面指定的character set来进行编码,resultSet.getString(*)取出的就是编码后的 字符串。这样就直接拿到gb2312的数据了。 但是mysql 4.1的推出给很多dbadmin带来了不小的麻烦,因为mysql4.1支持column level的character set,每个table,column都可以指定编码 ,不指定就是ISO8895_1,因此jdbc取出数据后会根据column的character set来进行编码,而不再是用一个全局的参数来取所有的数据了。 |