許多朋友朋友在處理XML的時候都遇到這樣的問題，那就是中文問題。如果解決這個問題呢？其次方法是很簡單的，首先讓我們了解一下編碼UTF。
什麼是 Unicode?
歷史上, 有兩個獨立的, 創立單一字符集的嘗試. 一個是國際標准化組織(ISO)的 ISO 10646 項目, 另一個是由(一開始大多是美國的)多語言軟件制造商組成的協會組織的 Unicode 項目. 幸運的是, 1991年前後, 兩個項目的參與者都認識到, 世界不需要兩個不同的單一字符集. 它們合並雙方的工作成果, 並為創立一個單一編碼表而協同工作. 兩個項目仍都存在並獨立地公布各自的標准, 但 Unicode 協會和 ISO/IEC JTC1/SC2 都同意保持 Unicode 和 ISO 10646 標准的碼表兼容, 並緊密地共同調整任何未來的擴展.
什麼是 UTF-8?
首先 UCS 和 Unicode 只是分配整數給字符的編碼表. 現在存在好幾種將一串字符表示為一串字節的方法. 最顯而易見的兩種方法是將 Unicode 文本存儲為 2 個 或 4 個字節序列的串. 這兩種方法的正式名稱分別為 UCS-2 和 UCS-4. 除非另外指定, 否則大多數的字節都是這樣的(Bigendian convention). 將一個 ASCII 或 Latin-1 的文件轉換成 UCS-2 只需簡單地在每個 ASCII 字節前插入 0x00. 如果要轉換成 UCS-4, 則必須在每個 ASCII 字節前插入三個 0x00.
在 Unix 下使用 UCS-2 (或 UCS-4) 會導致非常嚴重的問題. 用這些編碼的字符串會包含一些特殊的字符, 比如 '\0' 或 '/', 它們在 文件名和其他 C 庫函數參數裡都有特別的含義. 另外, 大多數使用 ASCII 文件的 UNIX 下的工具, 如果不進行重大修改是無法讀取 16 位的字符的. 基於這些原因, 在文件名, 文本文件, 環境變量等地方, UCS-2 不適合作為 Unicode 的外部編碼.
在 ISO 10646-1 Annex R 和 RFC 2279 裡定義的 UTF-8 編碼沒有這些問題. 它是在 Unix 風格的操作系統下使用 Unicode 的明顯的方法.
UTF-8 有一下特性:
UCS 字符 U+0000 到 U+007F (ASCII) 被編碼為字節 0x00 到 0x7F (ASCII 兼容). 這意味著只包含 7 位 ASCII 字符的文件在 ASCII 和 UTF-8 兩種編碼方式下是一樣的.
所有 >U+007F 的 UCS 字符被編碼為一個多個字節的串, 每個字節都有標記位集. 因此, ASCII 字節 (0x00-0x7F) 不可能作為任何其他字符的一部分.
表示非 ASCII 字符的多字節串的第一個字節總是在 0xC0 到 0xFD 的范圍裡, 並指出這個字符包含多少個字節. 多字節串的其余字節都在 0x80 到 0xBF 范圍裡. 這使得重新同步非常容易, 並使編碼無國界, 且很少受丟失字節的影響.
可以編入所有可能的 231個 UCS 代碼
UTF-8 編碼字符理論上可以最多到 6 個字節長, 然而 16 位 BMP 字符最多只用到 3 字節長.
Bigendian UCS-4 字節串的排列順序是預定的.
字節 0xFE 和 0xFF 在 UTF-8 編碼中從未用到.
下列字節串用來表示一個字符. 用到哪個串取決於該字符在 Unicode 中的序號.
U-00000000 - U-0000007F: 0xxxxxxx
U-00000080 - U-000007FF: 110xxxxx 10xxxxxx
U-00000800 - U-0000FFFF: 1110xxxx 10xxxxxx 10xxxxxx
U-00010000 - U-001FFFFF: 11110xxx 10xxxxxx 10xxxxxx 10xxxxxx
U-00200000 - U-03FFFFFF: 111110xx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx
U-04000000 - U-7FFFFFFF: 1111110x 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx
xxx 的位置由字符編碼數的二進制表示的位填入. 越靠右的 x 具有越少的特殊意義. 只用最短的那個足夠表達一個字符編碼數的多字節串. 注意在多字節串中, 第一個字節的開頭"1"的數目就是整個串中字節的數目.
例如: Unicode 字符 U+00A9 = 1010 1001 (版權符號) 在 UTF-8 裡的編碼為:
11000010 10101001 = 0xC2 0xA9
而字符 U+2260 = 0010 0010 0110 0000 (不等於) 編碼為:
11100010 10001001 10100000 = 0xE2 0x89 0xA0
這種編碼的官方名字拼寫為 UTF-8, 其中 UTF 代表 UCS Transformation Format. 請勿在任何文檔中用其他名字 (比如 utf8 或 UTF_8) 來表示 UTF-8, 當然除非你指的是一個變量名而不是這種編碼本身.
什麼編程語言支持 Unicode?
在大約 1993 年之後開發的大多數現代編程語言都有一個特別的數據類型, 叫做 Unicode/ISO 10646-1 字符. 在 Ada95 中叫 Wide_Character, 在 Java 中叫 char.
ISO C 也詳細說明了處理多字節編碼和寬字符 (wide characters) 的機制, 1994 年 9 月 Amendment 1 to ISO C 發表時又加入了更多. 這些機制主要是為各類東亞編碼而設計的, 它們比處理 UCS 所需的要健壯得多. UTF-8 是 ISO C 標准調用多字節字符串的編碼的一個例子, wchar_t 類型可以用來存放 Unicode 字符.
了解了utf之後讓我們看一看如何在XML中用UTF-8去解決中文亂碼的問吧！
其實解決xml中文問題的方法是很簡單的，把所有的地方都設為utf-8，例如你創建，利用程序生成XML時，都把字符集設為utf-8
如果利用xml提交表單並生成XML，那麼需要對提交的內容在程序中做個處理
代碼如下：
/**
* 將給定的字符串轉換為UTF編碼的字符串。
*
* @param str 輸入字符串
* @return 經UTF編碼後的字符串，如果有異常，則返回原編碼字符串
*/
public static String toUTF-8(final String str){
if(isNullorBlank(str)){
return str;
}
String retVal = str;
try{
retVal = new String(str.getBytes("ISO8859_1"), "UTF-8");
} catch(Exception e){
//log...
}
return retVal;
}
按照以上方式處理xml編碼，保證你的XML不會出現中文亂碼問題，希望對您所有幫助。