有關Java字符編碼的一些問題

Java字符編碼根本原理

1、

因爲JDK是國際版的，在對程序進行編譯的時候，若是咱們沒有用-encoding參數指定咱們的Java源程序的編碼格式，則javac.exe首先得到咱們操做系統默認採用的編碼格式，即：在編譯.java文件時，若咱們不指定源程序文件的編碼格式，JDK首先得到操做系統的file.encoding參數（它保存的就是操做系統默認的編碼格式，若是是WIN2k，則它的值爲GBK）。而後JDK就把咱們的Java源程序從file.encoding編碼格式，轉化爲Java內部默認的Unicode編碼格式放入內存中。而後，javac.exe把轉換後的Unicode編碼格式的文件進行編譯，使之成.class類文件，此時的.class文件是Unicode編碼的，它暫放在內存中。緊接着，JDK將此以Unicode編碼的編譯後的.class文件保存到咱們的操做系統中，造成咱們見到的.class文件。對咱們來講，咱們最終得到的.class文件是內容以Unicode編碼格式保存的類文件，它內部包含咱們源程序中的中文字符串，只不過此時它已經由file.encoding格式轉化爲Unicode格式了。當咱們不加設置就對程序進行編譯時，至關於使用了參數：javac -encoding gbk XX.java，固然就會出現不兼容的狀況。

因爲JDK是國際版的，在對程序進行編譯的時候，若是咱們沒有用-encoding參數指定咱們的Java源程序的編碼格式，則javac.exe會首先得到咱們操做系統默認採用的編碼格式，也即在編譯Java程序時，若咱們不指定源程序文件的編碼格式，JDK首先得到操做系統的file.encoding參數（它保存的就是操做系統默認的編碼格式，若是是WIN2k，則它的值爲GBK），而後JDK就把咱們的Java源程序從file.encoding編碼格式，轉化爲Java內部默認的Unicode格式放入內存中。而後，javac.exe把轉換後的Unicode格式的文件進行編譯，使之成.class類文件，此時的.class文件是Unicode編碼的，它暫放在內存中。緊接着，JDK將此以Unicode編碼的編譯後的.class 文件保存到咱們的操做系統中，造成咱們見到的.class文件。對咱們來講，咱們最終得到的.class文件是內容以Unicode編碼格式保存的類文件，它內部包含咱們源程序中的中文字符串，只不過此時它己經由file.encoding格式轉化爲Unicode格式了。當咱們不加設置就對程序進行編譯時，至關於使用了參數：

javac -encoding gbk XX.java，固然就會出現不兼容的狀況。

2、

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)

而不要使用那些不帶字符集名稱的方法簽名，經過上面兩個方法，能夠對內存中的字符進行從新編碼。

UTF-8並不是能容納了全部的中文字符集編碼

在Windows下用editPlus編寫一段Java代碼，裏面含有中文的文檔註釋。結果在編譯時出現了「編碼GBK的不可映射字符」。若此時保存的時候用的是UTF-8編碼，在cmd命令行編譯的時候寫

javac -encoding UTF8 XXX.java，可是編譯仍然會報錯，只是關於字符的報錯減小了，說明UTF-8並不是容納了全部的中文字符集編碼。