這個孩子講到了JSP亂碼的本質，強！

以下為轉載內容：

 

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 >>&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.