Java編碼轉換問題，new String(str.getByts(“ISO8859-1″), “GBK”)的作用

    今天在寫JSP頁面時，使用url參數的形式將一個中文字串傳給了另一個頁面，可是發現另一個頁面在解析這個參數的時候中文出現了亂碼。假設我已經將請求的這段中文字串賦給了str字串，那麼該怎樣得到正確的字串值呢？查了很多資料，終於找到了一個比較好的解釋：

    除了UTF-16，其它字元集定義時都重複。比如漢字“我”，假設它的值是22530（只是假設，具體多少我沒查）
而日文的“マ”的值也可能是22530(也是假設)或韓文的“찾”在網路上傳輸是不能以高位元組傳輸，因為網路底層最後只認無符號char,相當於java中的byte,所以22530這個int要轉換為位元組數組，byte[0] = (22530 >> 8)&0xFF;byte[1] = 22530 &0xFF;
具體多少我沒算，假設是byte[125，231]這樣的位元組傳到服務端到是表示漢字“我”還是日文的“マ”還是其它的呢？
    一般通訊協議中會告訴對字元集，比如HTTP在請求時告訴服務端：ContentType="xxxxxxxxxx";charset="GKB";
這時服務端就知道現在接收到的［125，231］是GKB的“我”而不是其它文字。上面是標準的通訊過程。但如果有些水平有限的程式員在提交請求時沒有通知服務端字元集，那服務端就沒辦法了。只好按最常用的字元集來猜一個預設的。這還不錯，最要命的是寫伺服器的程式員水平和見識很差時，就要命了。就象寫老版本的TOMCAT的程式員，他自己生在西方，以為全世界所有人都用的是26個字母加一些符號，所以他不管用戶端提交什麼都按ISO-8859-1來解碼，結果可想而知。

    比如我們使用gbk編碼提交了一個字串給伺服器，在tomcat中，它將這段字串用ISO8859-1解碼，並發送給目的網頁，這樣就產生了錯誤。於是我們可以使用new String(str.getByts("ISO8859-1"), "GBK")，先將伺服器傳來的參數按照ISO8859-1編碼，再將編碼的結果用gbk解碼，形成字串，就可以得到正確的值了。
    沒辦法，誰讓我們用GBK的人不會寫tomcat呢，只好先把讓那個差勁的程式員錯誤產生的String用ISO-8859-1還原成
［125，231］，再重新用GKB產生String.