您的位置:首页 > 其它

new String(getBytes(ISO-8859-1),GBK)解决中文乱码问题分析

2016-02-23 10:43 260 查看
用了好几种编码 全是乱码,request.setCharacterEncoding("UTF-8");尝试了好几种

String newdefrayItem = new String(request.getParameter("newdefrayItem").getBytes("iso-8859-1"),"GBK");也换了几次编码方式,最后是String newdefrayItem = new String(request.getParameter("newdefrayItem").getBytes("iso-8859-1"),"GBK");这样可以。在网上查了下原理,转了过来

 

tomcat默认全部都是用ISO-8859-1编码,不管你页面用什么显示,Tomcat最终还是会替你将所有字符转做ISO-8859-1.那么,当在另目标页面再用GBK翻译时就会将本来错的编码翻译成GBK的编码,这时的文字会乱码. 

所以需要先将得到"字符"(不管是什么)都先用字节数组表示,且使用ISO-8859-1进行翻译,得到一个在ISO-8859-1编码环境下的字节数组.例如:AB表示成[64,65].然后再用GBK编码这个数组,并翻译成一个字符串. 

那么我们可以得到一个编码转换的过程 

假设:GBK码("你")->URLencode后变成->(%3F%2F)->Tomcat自动替你转一次ISO-8859-1->得到( 23 43 68 23 42 68 每一个符号表示为ISO-8859-1中的一个编码)->接收页面--->再转一次为ISO-8859-1的Byte数组[23,43,68,23,42,68]--->用GBK再转为可读的文字--->(%3F%2F"---->转为("你")

 

除了UTF-16,其它字符集定义时都重复。 

比如汉字“我”,假设它的值是22530(只是假设,具体多少我没查) 

而日文的“マ”的值也可能是22530(也是假设)或韩文的“?” 

在网络上传输是不能以高字节传输,因为网络底层最后只认无符号char,相当于java中的byte,所以 

22530这个int要转换为字节数组, 

byte[0] = (22530 >> 8)&0xFF; 

byte[1] = 22530 &0xFF; 

具体多少我没算,假设是byte[125,231] 

这样的字节传到服务端到是表示汉字“我”还是日文的“マ”还是其它狗屁? 

一般通讯协议中会告诉对字符集,比如HTTP在请求时告诉服务端: 

ContentType="xxxxxxxxxx";charset="GKB"; 

这时服务端就知道现在接收到的[125,231]是GKB的“我”而不是其它文字。 

上面是标准的通信过程。但如果有些水平很差的程序员在提交请求时没有通知服务端字符集,那服务端就没办法了。 

只好按最常用的字符集来猜一个默认的。 

这还不错,最要命的是写服务器的程序员水平和见识很差时,就要命了。就象写老版本的TOMCAT的程序员,他自己生在西方,以为全世界所有人都用的是26个字母加一些符号,所以他不管客户端提交什么都按ISO-8859-1来算,结果可想而知。 

没办法,谁让我们用GBK的人不会写tomcat呢,只好先把让那个差劲的程序员错误生成的String用ISO-8859-1还原成 

[125,231],再重新用GKB生成String.

 

 

用于得到服务器传来的字符重新生成GBK编码
内容来自用户分享和网络整理,不保证内容的准确性,如有侵权内容,可联系管理员处理 点击这里给我发消息
标签: