最近用到了字串的壓縮，用到了gzipinputstream和gzipoutputstream，再次遇到了闊別已久的中文亂碼問題。
看了一些相關的文章，覺得我們之所以會遇到這樣那樣的亂碼問題，基本上都是由於我們在某些地方隱含了byte到char的轉換，而這種隱含的轉換採用的是iso-8859-1的編碼進行的。
以jsp頁面中文傳遞為例子，假設客戶端的編碼是gb2312,表單中的中文提交後，首先根據gb2312編碼轉換為位元組流，到達伺服器端後，如果我們直接在servlet中呼叫request.getparameter(string name)等方法，由於方法返回的是string 物件，所以其中必然隱含了一次從byte到char的轉換，錯誤也就是在這裡產生的，如果這次轉換採用的編碼是iso-8859-1，得到的當然是亂碼。
}幸好，以iso-8859-1進行的預設轉換不會損失位元組，也不會增加位元組，我們只要按照iso-8859-1的方式返回原來的位元組陣列，重新按照gb2312的方式進行byte 到char的轉換就可以了。
再以壓縮流為例（檔案流實際上也是一樣的)
public string uncompress(byte cmp)
bos.close();
baos.close();
bis.close();
ret = new string(baos.tobytearray());//用平台預設的編碼進行組裝，我是gb2312
}catch (ioexception ex)
return ret;
}reader是以字元為核心，inputstream是以byte為核心的，當他們轉換的時候就會進行byte到char的轉換，所以我們要注意自己的呼叫的順序。
我們如果今後再遇到亂碼的問題，就去找找自己是不是什麼地方進行了隱含的byte到char的轉換。
中文亂碼問題產生的由來
中文亂碼問題產生的由來 在計算機中，只有二進位制的資料，不管資料是在記憶體中，還是在外部裝置上。對於我們所看到的字元，也是以二進位制資料的形式存在的。不同的字元對應的 二進位制數的規則，就是字元的編碼。字元編碼的集合稱為字符集。常用的字符集 1 ascii 2 iso8859 1 3 gb2312和...
Java 開發中遇到的亂碼問題
unicode的空間分配 以下unicode區位碼均以16進製表示 unicode的前256個字元和iso 8859 1 西歐字母 完全相同，其中前半段就是ascii u 0000到u 00ff 每個iso 8859 1碼前面補上乙個空byte 0x00 後才是相應的unicode碼。和我們切身相關...
PHP 解決rtrim產生亂碼的問題
item 3 魔力之源 300 10鑽石 300000 金幣 var dump rtrim item string 3 魔力之源 300 10鑽石 300000 金 length 47 rtrim函式把引數都轉成了utf8後再進行比較。對於中文，一般都是先轉成unicode，再根據下表轉成utf8。...