前端工程师，当你和后端的文件都是以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是最好的语言。