Java字元編碼原理

Java開發中，常常會遇到亂碼的問題，一旦遇到這種問題，常常就很扯蛋，每個人都不願意承認是自己的代碼有問題。其實編碼問題並沒有那麼神秘，那麼不可捉摸，搞清Java的編碼本質過程就真相大白了。
 
其實，編碼問題存在兩個方面：JVM之內和JVM之外。
 
 
1、Java檔案編譯後形成class
這裡Java檔案的編碼可能有多種多樣，但Java編譯器會自動將這些編碼按照Java檔案的編碼格式正確讀取後產生class檔案，這裡的class檔案編碼是Unicode編碼（具體說是UTF-16編碼）。
 
因此，在Java代碼中定義一個字串：
String s="漢字";
不管在編譯前java檔案使用何種編碼，在編譯後成class後，他們都是一樣的----Unicode編碼錶示。
 
2、JVM中的編碼
JVM載入class檔案讀取時候使用Unicode編碼方式正確讀取class檔案，那麼原來定義的String s="漢字";在記憶體中的表現形式是Unicode編碼。
 
當調用String.getBytes()的時候，其實已經為亂碼買下了禍根。因為此方法使用平台預設的字元集來擷取字串對應的位元組數組。在WindowsXP中文版中，使用的預設編碼是GBK，不信運行下：
public class Test {
        public static void main(String[] args) {
                System.out.println("當前JRE：" + System.getProperty("java.version"));

                System.out.println("當前JVM的預設字元集：" + Charset.defaultCharset());
        }
}
當前JRE：1.6.0_16
當前JVM的預設字元集：GBK
當不同的系統、資料庫經過多次編碼後，如果對其中的原理不理解，就容易導致亂碼。因此，在一個系統中，有必要對字串的編碼做一個統一，這個統一模糊點說，就是對外統一。比如方法字串參數，IO流，在中文系統中，可以統一使用GBK、GB13080、UTF-8、UTF-16等等都可以，只是要選擇有些更大字元集，以保證任何可能用到的字元都可以正常顯示，避免亂碼的問題。（假設對所有的檔案都用ASCII碼）那麼就無法實現雙向轉換了。
 
要特別注意的是，UTF-8並非能容納了所有的中文字元集編碼，因此，在特殊情況下，UTF-8轉GB18030可能會出現亂碼，然而一群傻B常常在做中文系統喜歡用UTF-8編碼而不說不出個所以然出來！最傻B的是，一個系統多個人做，原始碼檔案有的人用GBK編碼，有人用UTF-8，還有人用GB18030。FK，都是中國人，也不是外包項目，用什麼UTF-8啊，神經！原始碼統統都用GBK18030就OK了，免得ANT指令碼編譯時間候提示不可認的字元編碼。
 
因此，對於中文系統來說，最好選擇GBK或GB18030編碼（其實GBK是GB18030的子集），以便最大限度的避免亂碼現象。
 
3、記憶體中字串的編碼
記憶體中的字串不僅僅局限於從class代碼中直接載入而來的字串，還有一些字串是從文字檔中讀取的，還有的是通過資料庫讀取的，還有可能是從位元組數組構建的，然而他們基本上都不是Unicode編碼的，原因很簡單，儲存最佳化。
 
因此就需要處理各種各樣的編碼問題，在處理之前，必須明確“源”的編碼，然後用指定的編碼方式正確讀取到記憶體中。如果是一個方法的參數，實際上必須明確該字串參數的編碼，因為這個參數可能是另外一個日文系統傳遞過來的。當明確了字串編碼時候，就可以按照要求正確處理字串，以避免亂碼。
在對字串進行解碼編碼的時候，應該調用下面的方法：
getBytes(String charsetName)    
String(byte[] bytes, String charsetName)  

而不要使用那些不帶字元集名稱的方法簽名，通過上面兩個方法，可以對記憶體中的字元進行重新編碼。

轉載：http://www.oschina.net/code/snippet_121156_4749