原文:https://www.cnblogs.com/liaozhenting/p/6869668.html
前后端交互,后端与后端交互中文乱码
前端工程师,当你和后端的文件都是以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是最好的语言。