前后端交互,后端与后端交互中文乱码

前端工程师,当你和后端的文件都是以UTF-8的编码,但是后台大哥告诉你,中文是乱码的,然后你百度了半天,给jQuery.ajax设置了contentType: "application/x-www-form-urlencoded; charset=UTF-8", 但是却并没有卵用,后端告诉你,传过去的字符串都是GBK编码,项目期限快到了,所有人都怀疑是你的问题时。你会想到什么?

我分享一下我的故事。其实主要是讲一下这个BUG如何怎么解决的。我是一个前端工程师,接受了一个项目,处于安全考虑,是前端发送信息给代理的后端,代理后端再发送信息到客户公司的后台,然后数据库保存信息。

后端告诉我,如论怎么设置,我传过去的字符串都是GB2312编码。我决定自己将传过去的字符串进行编码。然后再POST传过去。

var postData=encodeURIComponent(encodeURIComponent(str));

为什么编码两次?因为我的后台是Java语言。

服务器端TOMCAT会自动先做一次decode,所以客户端要编码两次,服务器端只解码一次就OK了。并且这个奇妙的BUG就是无论你怎么改,后台显示你传过去的都是GB2312编码,所以你编码两次,TOMCAT自动解码一次,然后,再在程序中 java.net.URLDecoder(***, "UTF-8")) 就可以得到正确的字符串。不管是按 GB2312还是 UTF-8 还是 ISO-8859-1 。

但是代理后台没有问题正常显示中文,客户的后台保存到数据库确是乱码。我直觉告诉这绝对跟我没有关系了。

我观察一下了乱码的形状,

 

初步判断是是ISO-8859-1的编码形式。开始猜测应该是客户的后台出了问题。

客户的后台程序员建议我们写个junit测试。还发了一个能正确提交中文的示例代码。我观察到他的示例代码有段注释“必须POST提交,否则会以ISO-8859-1编码”。

我猜测可能是提交方式的原因。

后来因为某个原因这个接口信息提交不上去,我登录远超服务器,看到代理后端的TOMCAT显示get请求 400。果然是代理后端是get方式向客户公司的后台发数据。

我叫代理后端的程序员改成POST方式提交到客户之后,数据库就正常了。

写这篇文章虽然轻松,但是找BUG却备受煎熬,尤其是别人很懒不想配合你的时候。

作为前端工程师,必须时刻保持警惕。因为你作为前端,后端的错你是很难发现的。你必须对后端有所了解,才能少被坑。

总结一下知识点:

1.通过乱码判断这是什么编码,方便确认出了什么错。

ISO-8859-1的乱码

GBK的乱码

UTF-8的乱码

2.Java某框架,get方式提交过来的参数,如果不设置,默认是iso8859-1编码。

3.找BUG就像科学研究,提出假设,找寻证据,验证假设。

讲道理我一个前端工程师是一辈子找不出这种后端制造的BUG,但是我最近学了PHP,对后端有了一定了解,所以PHP是最好的语言。

 

 


posted @ 2017-05-17 21:40  从过去穿越到现在  阅读(8176)  评论(3编辑  收藏  举报