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)
以上是Java字元編碼實例分析的詳細內容。更多資訊請關注PHP中文網其他相關文章!