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