Java編程技術(shù)中漢字問題的分析及解決

1、 HYPERLINK /kt400_hhx/article/details/1641590 o 字體編碼學(xué)習(xí)-Java 編程技術(shù)中漢字問題的分析及解決 JAVA漢字顯示問題的解決方案 字體編碼學(xué)習(xí)-Java 編程技術(shù)中漢字問題的分析及解決 JAVA漢字顯示問題的解決方案分類： HYPERLINK /kt400_hhx/article/category/307815 java相關(guān)2007-06-07 02:311593人閱讀 HYPERLINK /kt400_hhx/article/details/1641590 l comments 評(píng)論(0) HYPERLINK javascript:voi

2、d(0); o 收藏 收藏 HYPERLINK /kt400_hhx/article/details/1641590 l report o 舉報(bào) 舉報(bào)字體編碼學(xué)習(xí)-關(guān)鍵字：USC,Unicode,utf-8,gb2312,字庫(kù)什么是編碼為了交流信息，所以對(duì)字符進(jìn)行了統(tǒng)一的編碼。UCS和ISO10646 ISO10646定義了通用字符集(Universal Character Set,UCS).UCS是國(guó)際標(biāo)準(zhǔn)編碼，包含了全球所有字符。UCS使用31bit進(jìn)行編碼?，F(xiàn)在只分配了前65534個(gè)碼位，這個(gè)16位的子集稱為基本多語(yǔ)言面(BMP)。什么Unicode Unicode編碼是UCS級(jí)別的實(shí)現(xiàn)

3、。Unicode編碼全碼為4個(gè)字節(jié)，所有字符都使用等的編碼方式，現(xiàn)在只使用兩個(gè)字節(jié)編碼。兼容UCS定義的BMPGB2313與Unicode GB2312是中國(guó)定制的國(guó)際準(zhǔn)標(biāo)編碼，由兩個(gè)字節(jié)組成，最高位為1表示漢字，最高為0表示是英文。 GB2312與區(qū)位碼存在數(shù)值關(guān)系,區(qū)位碼+20HGB2312 GB2312與Unicode的轉(zhuǎn)換不成數(shù)學(xué)關(guān)系，只能通過映射表來實(shí)現(xiàn)。 GB2312為年定義的基本編碼擴(kuò)展編碼有 GBK GB18030 GB13000與GBK不兼容，只是使用了相同的詞匯. 最新為GB16500-95與unicode3.0兼容Unicode與UTF-8 Utf-8是為了兼容軟件處理的

4、編碼，是unicode的另一種表示方式。使用變化的方式編碼，第一字節(jié)表示字符的長(zhǎng)度，后面的字符以10開頭表示編碼。0開頭表示ascii編碼。 例如：Unicode 字符 U+00A9 = 1010 1001 (版權(quán)符號(hào)) 在 UTF-8 里的編碼為 11000010 10101001 = 0 xC2 0 xA9字庫(kù)與編碼關(guān)系 字庫(kù)是編碼表字符顯示的描述文件。字符編碼是在字庫(kù)中查詢需要顯示的字符的索引值。 不同的編碼就應(yīng)該有不同的字庫(kù)，比如unicode編碼就有unicode的字庫(kù)。Gb2312編碼就有g(shù)b2312的字庫(kù)。字庫(kù)格式 字庫(kù)的格式主要有TrueType(ttf),PostScript

5、(rip),OpenType等 TrueType是微軟定義的字庫(kù)格式，主要用于軟件顯示這種要求精度不高的環(huán)境， PostScript是Adobe定義的字庫(kù)格式，主要用于排版印刷等大字打印精度要求很高的環(huán)境。 OpenType是TrueType與PostScript的綜合格式，并且是使用了unicode的編碼。字體引擎 字體引擎用于讀取字庫(kù)，顯示文字，文字轉(zhuǎn)換等操作?，F(xiàn)在免費(fèi)的字體引擎有FreeType.參考文獻(xiàn) UTF-8 and Unicode FAQ by Markus Kuhn HYPERLINK /linux/TrueType-HOWTO.html /linux/TrueType-HO

6、WTO.html HYPERLINK /Info/55/Info16006/ /Info/55/Info16006/ HYPERLINK /fonts/TTRefMan/index.html /fonts/TTRefMan/index.html/以前一直對(duì)utf、unicode、ascII還有GBK編碼方式不太了解，只知道如果有中文的話一般用utf-8或GBK存儲(chǔ)，今天正好又接觸到了這個(gè)問題就google了下。ASCII是用來表示英文的一種編碼規(guī)范，表示的最大字符數(shù)為256個(gè)，每個(gè)字符占1個(gè)字節(jié)。如果只用來表示英文應(yīng)該是綽綽有余了，可是還要表示中文、阿拉伯文所以就有很大的不足了，于是就產(chǎn)生了G

7、B2312。很多人應(yīng)該對(duì)這個(gè)比較了解，很多國(guó)內(nèi)網(wǎng)頁(yè)指定的編碼都是GB2312的，它其實(shí)是對(duì)ASCII的一種擴(kuò)展，是每個(gè)國(guó)家自己制定的編碼規(guī)范，比如一個(gè)中文字符是由兩個(gè)擴(kuò)展ASCII字符表示。但因?yàn)镚B2312是國(guó)家標(biāo)準(zhǔn)所以會(huì)有一些問題，記得我們小時(shí)候玩一些繁體游戲時(shí)需要借助一些南極星之類的軟件轉(zhuǎn)換編碼嗎？因?yàn)榕_(tái)灣很多用的都是big5編碼，他和GB2312的編碼格式還是類似的，會(huì)顯示出一些奇怪的文字或是偶爾也會(huì)有個(gè)別漢字。后來因?yàn)镚B2312所包含的漢字太少了，所以又?jǐn)U展出來GBK編碼。GBK包括了大部分的漢字，并且還加入了big5中幾乎所有的繁體字體（但big5和GBK中的繁體字體并不兼容）。

8、之后還有GB18030編碼，其實(shí)主要還是字符集的變化。ASCIIGB2312GBKGB18030他們都是向下兼容的，區(qū)分英文編碼和中文編碼的方法是高字節(jié)的最高位不為0，其實(shí)GB中文編碼都是雙字節(jié)字符集。因?yàn)镚B編碼都是國(guó)家標(biāo)準(zhǔn)，所以如果要解決中文問題不能從擴(kuò)展ASCII角度入手了，于是出現(xiàn)了unicode和utf。unicode分為UCS-2、UCS-4，目前常用的是UCS-2是用2個(gè)字節(jié)為字符編碼，可以表示的數(shù)為216=65535，基本可以表示歐美和大部分亞洲漢字，并且因?yàn)閁CS-2是雙字節(jié)的所以每個(gè)漢字或英文都是由1個(gè)unicode構(gòu)成，那拆字和統(tǒng)計(jì)字?jǐn)?shù)比ASCII方便了很多。似乎unic

9、ode是比較完美了，可是它卻有一個(gè)很致命的缺點(diǎn)，就是并不能和ASCII兼容。ASCII字符是單個(gè)字節(jié)的，比如A的ASCII是65。而Unicode是雙字節(jié)的，比如A的Unicode是0065，這就造成了一個(gè)非常大的問題：以前處理ASCII的那套機(jī)制不能被用來處理Unicode了 。另一個(gè)更加嚴(yán)重的問題是，C語(yǔ)言使用/0作為字符串結(jié)尾，而Unicode里恰恰有很多字符都有一個(gè)字節(jié)為0，這樣一來，C語(yǔ)言的字符串函數(shù)將無(wú)法正常處理Unicode，除非把世界上所有用C寫的程序以及他們所用的函數(shù)庫(kù)全部換掉 。于是出現(xiàn)了utf，它是將Unicode編碼規(guī)則和計(jì)算機(jī)的實(shí)際編碼對(duì)應(yīng)起來的一個(gè)規(guī)則。現(xiàn)在流行的U

10、TF有2種：UTF-8和UTF-16。UTF-8是以8位為單元對(duì)UCS進(jìn)行編碼，它定義了一種區(qū)間規(guī)則，這種規(guī)則可以和ASCII編碼保持最大程度的兼容 。具體的編碼方式大家可以搜索一下，俺也只是一些淺顯的了解，如果有不對(duì)的地方請(qǐng)大家指出來/Unicode:制定的編碼機(jī)制, 要將全世界常用文字都函括進(jìn)去.在1.0中是16位編碼, 由U+0000到U+FFFF. 每個(gè)2byte碼對(duì)應(yīng)一個(gè)字符; 在2.0開始拋棄了16位限制, 原來的16位作為基本位平面, 另外增加了16個(gè)位平面, 相當(dāng)于20位編碼, 編碼范圍0到0 x10FFFF.UCS:ISO制定的ISO10646標(biāo)準(zhǔn)所定義的 Universal

11、 Character Set, 采用4byte編碼.Unicode與UCS的關(guān)系:ISO與是兩個(gè)不同的組織, 因此最初制定了不同的標(biāo)準(zhǔn); 但自從unicode2.0開始, unicode采用了與ISO 10646-1相同的字庫(kù)和字碼, ISO也承諾ISO10646將不會(huì)給超出0 x10FFFF的UCS-4編碼賦值,使得兩者保持一致.UCS的編碼方式:UCS-2, 與unicode的2byte編碼基本一樣.UCS-4, 4byte編碼, 目前是在UCS-2前加上2個(gè)全零的byte.UTF: Unicode/UCS Transformation FormatUTF-8, 8bit編碼, ASCII

12、不作變換, 其他字符做變長(zhǎng)編碼, 每個(gè)字符1-3 byte. 通常作為外碼. 有以下優(yōu)點(diǎn):* 與CPU字節(jié)順序無(wú)關(guān), 可以在不同平臺(tái)之間交流* 容錯(cuò)能力高, 任何一個(gè)字節(jié)損壞后, 最多只會(huì)導(dǎo)致一個(gè)編碼碼位損失, 不會(huì)鏈鎖錯(cuò)誤(如GB碼錯(cuò)一個(gè)字節(jié)就會(huì)整行亂碼)UTF-16, 16bit編碼, 是變長(zhǎng)碼, 大致相當(dāng)于20位編碼, 值在0到0 x10FFFF之間, 基本上就是unicode編碼的實(shí)現(xiàn). 它是變長(zhǎng)碼, 與CPU字序有關(guān), 但因?yàn)樽钍】臻g, 常作為網(wǎng)絡(luò)傳輸?shù)耐獯a.UTF-16是unicode的preferred encoding.UTF-32, 僅使用了unicode范圍(0到0 x10

13、FFFF)的32位編碼, 相當(dāng)于UCS-4的子集.UTF與unicode的關(guān)系:Unicode是一個(gè)字符集, 可以看作為內(nèi)碼.而UTF是一種編碼方式, 它的出現(xiàn)是因?yàn)閡nicode不適宜在某些場(chǎng)合直接傳輸和處理. UTF-16直接就是unicode編碼, 沒有變換, 但它包含了0 x00在編碼內(nèi), 頭256字節(jié)碼的第一個(gè)byte都是0 x00, 在操作系統(tǒng)(C語(yǔ)言)中有特殊意義, 會(huì)引起問題. 采用UTF-8編碼對(duì)unicode的直接編碼作些變換可以避免這問題,并帶來一些優(yōu)點(diǎn).中國(guó)國(guó)標(biāo)編碼:GB 13000: 完全等同于ISO 10646-1/Unicode 2.1, 今后也將隨ISO 106

14、46/Unicode的標(biāo)準(zhǔn)更改而同步更改.GBK: 對(duì)GB2312的擴(kuò)充, 以容納GB2312字符集范圍以外的Unicode 2.1的統(tǒng)一漢字部分, 并且增加了部分unicode中沒有的字符.GB 18030-2000: 基于GB 13000, 作為Unicode 3.0的GBK擴(kuò)展版本, 覆蓋了所有unicode編碼, 地位等同于UTF-8, UTF-16, 是一種unicode編碼形式. 變長(zhǎng)編碼, 用單字節(jié)/雙字節(jié)/4字節(jié)對(duì)字符編碼. GB18030向下兼容GB2312/GBK.GB 18030是中國(guó)所有非手持/嵌入式計(jì)算機(jī)系統(tǒng)的強(qiáng)制實(shí)施標(biāo)準(zhǔn)./徹底解決程序亂碼問題 由于程序編程過程中存

15、在眾多的編碼集，而這些編碼集又各自有自己的方法來表示一個(gè)中文字符。由此，造成我們的程序顯示中文的時(shí)候亂碼。最多的是本來是中文，但結(jié)果顯示為問號(hào)？ 這篇文章從我碰到過的問題來從根本上解決亂碼的問題，反正我用這個(gè)方法是百戰(zhàn)百勝_嘎嘎 我們知道，在我們的中文系統(tǒng)中使用的是“GBK”編碼集。 也就是說，比如我們從本地系統(tǒng)中讀入一個(gè)包含中文內(nèi)容的.txt文件，那么我們從這個(gè)磁盤空間所獲得是流文件是個(gè)經(jīng)過“GBK”的。 但是，假如我們的JVM默認(rèn)的編碼集是“ISO-8859-1”，那么這個(gè)流文件經(jīng)過我們的JVM編碼就變成一個(gè)Unicode的字符或者字符串。 是不是說的很抽象。 下面我具體解釋一下。 什么是

16、編碼？編碼說白了就是從字節(jié)到字符(Unicode）的過程，因?yàn)槲覀兊淖址蜃址贘VM中是用Unicode表示的，也就是說編碼實(shí)質(zhì)上是獲取一個(gè)Unicode碼的過程。 我再來解釋一下解碼？解碼就是把JVM里的Unicode碼轉(zhuǎn)換成我們本地字符集所表示的字節(jié)流。 如果在編程過程中，JVM默認(rèn)的字符集和我們的中文系統(tǒng)，或者數(shù)據(jù)庫(kù)文件等采用的字符集不一樣。 這樣的情況下，如果我們僅僅是編碼，而不去解碼。也就說把本來用“GBK”的字節(jié)流采用“ISO-8859-1”轉(zhuǎn)換成字符或字符串，這個(gè)時(shí)候就產(chǎn)生了亂碼。 當(dāng)然，現(xiàn)在JVM和中文系統(tǒng)默認(rèn)的編碼集已經(jīng)一樣了，所以產(chǎn)生這種情況的很少。但是在讀取數(shù)據(jù)庫(kù)文件

17、的時(shí)候依然會(huì)經(jīng)常碰到這種情況。所以，我一貫主張從本質(zhì)上來了解一個(gè)知識(shí)，然后才能融會(huì)貫通，應(yīng)用自如，這是高手的境界，當(dāng)然，我不能算高手_哈哈 好了，如果你現(xiàn)在還不明白編碼解碼怎么回事？以及亂碼產(chǎn)生的原因。我想你可以去撞墻了。 那么，編碼的時(shí)候兩個(gè)系統(tǒng)的字符集不一致，該怎么辦呢？怎么樣把他們變成一致？ 如果有可以直接改變系統(tǒng)字符集的方法，那當(dāng)然是最好的了。比如在JVM里 Properties pps = System.getProperties(); pps.put(file.encoding,GBK); 這樣，就把JVM的默認(rèn)字符集改變成“GBK”了。 那么，如果沒有改怎么辦？ 什么？沒辦法？那

18、是不可能滴，沒有程序解決不了的問題，這也是偶滴名言，嘎嘎！當(dāng)然要再次編碼了，或者說重新編碼！ 還記得不？剛才我們解碼的時(shí)候得到一個(gè)利用JVM解碼的字符或字符串（也可以說Unicode）好，如果不記得，麻煩你再看看上面寫的，記性太差了！ 我們利用這個(gè)字符或字符串再重新編碼。我們把這個(gè)字符或字符串再次現(xiàn)出原形，也就是字節(jié)數(shù)組。 byte data = str.getBytes(ISO-8859-1);好，現(xiàn)在又獲得了“ISO-8859-1”字符集下的字節(jié)數(shù)組。這個(gè)里面就完整的存放著我們想要的漢字，哈哈。得到了字節(jié)數(shù)組，不就好辦了嗎？還不會(huì)？沒關(guān)系，我教你！String newstr = new S

19、tring(data,“GBK”);好了，得到了我們完整的字符串了！編碼變成！這個(gè)字符串就是我們要的中文系統(tǒng)下的字符串，它又經(jīng)過我們“GBK”編碼過了！可以放心的輸出到中文系統(tǒng)下了。其實(shí)說白了，編碼解碼就是把我們從系統(tǒng)得到的字符轉(zhuǎn)換成字節(jié)數(shù)組，然后對(duì)它用系統(tǒng)字符集加工，加工完后再重新包裝，再把它輸出。/Java 編程技術(shù)中漢字問題的分析及解決在基于 Java 語(yǔ)言的編程中，我們經(jīng)常碰到漢字的處理及顯示的問題。一大堆看不懂的亂碼肯定不是我們?cè)敢饪吹降娘@示效果，怎樣才能夠讓那些漢字正確顯示呢？Java 語(yǔ)言默認(rèn)的編碼方式是UNICODE ，而我們中國(guó)人通常使用的文件和數(shù)據(jù)庫(kù)都是基于 GB2312或

20、者 BIG5 等方式編碼的，怎樣才能夠恰當(dāng)?shù)剡x擇漢字編碼方式并正確地處理漢字的編碼呢？本文將從漢字編碼的常識(shí)入手，結(jié)合 Java 編程實(shí)例，分析以上兩個(gè)問題并提出解決它們的方案?，F(xiàn)在 Java 編程語(yǔ)言已經(jīng)廣泛應(yīng)用于互聯(lián)網(wǎng)世界，早在 Sun 公司開發(fā) Java 語(yǔ)言的時(shí)候，就已經(jīng)考慮到對(duì)非英文字符的支持了。Sun 公司公布的 Java 運(yùn)行環(huán)境（JRE）本身就分英文版和國(guó)際版，但只有國(guó)際版才支持非英文字符。不過在 Java 編程語(yǔ)言的應(yīng)用中，對(duì)中文字符的支持并非如同 Java Soft 的標(biāo)準(zhǔn)規(guī)范中所宣稱的那樣完美，因?yàn)橹形淖址恢灰粋€(gè)，而且不同的操作系統(tǒng)對(duì)中文字符的支持也不盡相同，所以會(huì)有

21、許多和漢字編碼處理有關(guān)的問題在我們進(jìn)行應(yīng)用開發(fā)中困擾著我們。有很多關(guān)于這些問題的解答，但都比較瑣碎，并不能夠滿足大家迫切解決問題的愿望，關(guān)于 Java 中文問題的系統(tǒng)研究并不多，本文從漢字編碼常識(shí)出發(fā)，分析 Java 中文問題，希望對(duì)大家解決這個(gè)問題有所幫助。漢字編碼的常識(shí)我們知道，英文字符一般是以一個(gè)字節(jié)來表示的，最常用的編碼方法是 ASCII 。但一個(gè)字節(jié)最多只能區(qū)分256個(gè)字符，而漢字成千上萬(wàn)，所以現(xiàn)在都以雙字節(jié)來表示漢字，為了能夠與英文字符分開，每個(gè)字節(jié)的最高位一定為1，這樣雙字節(jié)最多可以表示64K格字符。我們經(jīng)常碰到的編碼方式有 GB2312、BIG5、UNICODE 等。關(guān)于具體編

22、碼方式的詳細(xì)資料，有興趣的讀者可以查閱相關(guān)資料。我膚淺談一下和我們關(guān)系密切的 GB2312 和 UNICODE。GB2312 碼，中華人民共和國(guó)國(guó)家標(biāo)準(zhǔn)漢字信息交換用編碼，是一個(gè)由中華人民共和國(guó)國(guó)家標(biāo)準(zhǔn)總局發(fā)布的關(guān)于簡(jiǎn)化漢字的編碼，通行于中國(guó)大陸地區(qū)及新加坡，簡(jiǎn)稱國(guó)標(biāo)碼。兩個(gè)字節(jié)中，第一個(gè)字節(jié)（高字節(jié)）的值為區(qū)號(hào)值加32（20H），第二個(gè)字節(jié)（低字節(jié)）的值為位號(hào)值加32（20H），用這兩個(gè)值來表示一個(gè)漢字的編碼。UNICODE 碼是微軟提出的解決多國(guó)字符問題的多字節(jié)等長(zhǎng)編碼，它對(duì)英文字符采取前面加“0”字節(jié)的策略實(shí)現(xiàn)等長(zhǎng)兼容。如 “A” 的 ASCII 碼為0 x41，UNICODE 就為0

23、x00，0 x41。利用特殊的工具各種編碼之間可以互相轉(zhuǎn)換。Java 中文問題的初步認(rèn)識(shí)我們基于 Java 編程語(yǔ)言進(jìn)行應(yīng)用開發(fā)時(shí)，不可避免地要處理中文。Java 編程語(yǔ)言默認(rèn)的編碼方式是 UNICODE，而我們通常使用的數(shù)據(jù)庫(kù)及文件都是基于 GB2312 編碼的，我們經(jīng)常碰到這樣的情況：瀏覽基于 JSP 技術(shù)的網(wǎng)站看到的是亂碼，文件打開后看到的也是亂碼，被 Java 修改過的數(shù)據(jù)庫(kù)的內(nèi)容在別的場(chǎng)合應(yīng)用時(shí)無(wú)法繼續(xù)正確地提供信息。String sEnglish = “apple”;String sChinese = “蘋果”;String s = “蘋果 apple ”;sEnglish 的長(zhǎng)度

24、是5，sChinese的長(zhǎng)度是4，而 s 默認(rèn)的長(zhǎng)度是14。對(duì)于 sEnglish來說， Java 中的各個(gè)類都支持得非常好，肯定能夠正確顯示。但對(duì)于 sChinese 和 s 來說，雖然 Java Soft 聲明 Java 的基本類已經(jīng)考慮到對(duì)多國(guó)字符的支持（默認(rèn) UNICODE編碼），但是如果操作系統(tǒng)的默認(rèn)編碼不是 UNICODE ，而是國(guó)標(biāo)碼等。從 Java 源代碼到得到正確的結(jié)果，要經(jīng)過 “Java 源代碼- Java 字節(jié)碼- ;虛擬機(jī)-操作系統(tǒng)-顯示設(shè)備”的過程。在上述過程中的每一步驟，我們都必須正確地處理漢字的編碼，才能夠使最終的顯示結(jié)果正確?！?Java 源代碼- Java 字

25、節(jié)碼”，標(biāo)準(zhǔn)的 Java 編譯器 javac 使用的字符集是系統(tǒng)默認(rèn)的字符集，比如在中文 Windows 操作系統(tǒng)上就是 GBK ,而在 Linux 操作系統(tǒng)上就是ISO-8859-1，所以大家會(huì)發(fā)現(xiàn)在 Linux 操作系統(tǒng)上編譯的類中源文件中的中文字符都出了問題，解決的辦法就是在編譯的時(shí)候添加 encoding 參數(shù)，這樣才能夠與平臺(tái)無(wú)關(guān)。用法是javac encoding GBK?！?Java 字節(jié)碼-虛擬機(jī)-操作系統(tǒng)”， Java 運(yùn)行環(huán)境 （JRE） 分英文版和國(guó)際版，但只有國(guó)際版才支持非英文字符。 Java 開發(fā)工具包 （JDK） 肯定支持多國(guó)字符，但并非所有的計(jì)算機(jī)用戶都安裝了 J

26、DK 。很多操作系統(tǒng)及應(yīng)用軟件為了能夠更好的支持 Java ，都內(nèi)嵌了 JRE 的國(guó)際版本，為自己支持多國(guó)字符提供了方便。“操作系統(tǒng)-顯示設(shè)備”，對(duì)于漢字來說，操作系統(tǒng)必須支持并能夠顯示它。英文操作系統(tǒng)如果不搭配特殊的應(yīng)用軟件的話，是肯定不能夠顯示中文的。還有一個(gè)問題，就是在 Java 編程過程中，對(duì)中文字符進(jìn)行正確的編碼轉(zhuǎn)換。例如，向網(wǎng)頁(yè)輸出中文字符串的時(shí)候，不論你是用out.println(string); / string 是含中文的字符串還是用，都必須作 UNICODE 到 GBK 的轉(zhuǎn)換，或者手動(dòng)，或者自動(dòng)。在 JSP 1.0中，可以定義輸出字符集，從而實(shí)現(xiàn)內(nèi)碼的自動(dòng)轉(zhuǎn)換。用法是但是

27、在一些 JSP 版本中并沒有提供對(duì)輸出字符集的支持，（例如 JSP 0.92），這就需要手動(dòng)編碼輸出了，方法非常多。最常用的方法是String s1 = request.getParameter(“keyword”);String s2 = new String(s1.getBytes(“ISO-8859-1”),”GBK”);getBytes 方法用于將中文字符以“ISO-8859-1”編碼方式轉(zhuǎn)化成字節(jié)數(shù)組，而“GBK”是目標(biāo)編碼方式。我們從以ISO-8859-1方式編碼的數(shù)據(jù)庫(kù)中讀出中文字符串 s1 ，經(jīng)過上述轉(zhuǎn)換過程，在支持 GBK 字符集的操作系統(tǒng)和應(yīng)用軟件中就能夠正確顯示中文字符串

28、s2 。Java 中文問題的表層分析及處理背景開發(fā)環(huán)境JDK1.15Vcafe2.0JPadPro服務(wù)器端NT IISSybase SystemJconnect（JDBC）客戶端IE5.0Pwin98.CLASS 文件存放在服務(wù)器端，由客戶端的瀏覽器運(yùn)行 APPLET ， APPLET 只起調(diào)入 FRAME 類等主程序的作用。界面包括 Textfield ，TextArea，List，Choice 等。I. 取中文用 JDBC 執(zhí)行 SELECT 語(yǔ)句從服務(wù)器端讀取數(shù)據(jù)（中文）后，將數(shù)據(jù)用 APPEND 方法加到 TextArea（TA） ，不能正確顯示。但加到 List 中時(shí)，大部分漢字卻可

29、正確顯示。將數(shù)據(jù)按“ISO-8859-1” 編碼方式轉(zhuǎn)化為字節(jié)數(shù)組，再按系統(tǒng)缺省編碼方式 （Default Character Encoding） 轉(zhuǎn)化為 STRING ，即可在 TA 和 List 中正確顯示。程序段如下：dbstr2 = results.getString(1);/After reading the result from DB server，converting it to string.dbbyte1 = dbstr2.getBytes(“iso-8859-1”);dbstr1 = new String(dbbyte1);在轉(zhuǎn)換字符串時(shí)不采用系統(tǒng)默認(rèn)編碼方式，而直接采用

30、“ GBK” 或者 “GB2312” ,在A 和 B 兩種情況下，從數(shù)據(jù)庫(kù)取數(shù)據(jù)都沒有問題。II. 寫中文到數(shù)據(jù)庫(kù)處理方式與“取中文”相逆，先將 SQL 語(yǔ)句按系統(tǒng)缺省編碼方式轉(zhuǎn)化為字節(jié)數(shù)組，再按“ISO-8859-1”編碼方式轉(zhuǎn)化為 STRING ，最后送去執(zhí)行，則中文信息可正確寫入數(shù)據(jù)庫(kù)。程序段如下：sqlstmt = tf_input.getText();/Before sending statement to DB server，converting it to sql statement.dbbyte1 = sqlstmt.getBytes();sqlstmt = newString

31、(dbbyte1,”iso-8859-1”);_stmt = _con.createStatement();_stmt.executeUpdate(sqlstmt);問題：如果客戶機(jī)上存在 CLASSPATH 指向 JDK 的 CLASSES.ZIP 時(shí)（稱為 A 情況），上述程序代碼可正確執(zhí)行。但是如果客戶機(jī)只有瀏覽器，而沒有 JDK 和 CLASSPATH 時(shí)（稱為 B 情況），則漢字無(wú)法正確轉(zhuǎn)換。我們的分析：1.經(jīng)過測(cè)試，在 A 情況下，程序運(yùn)行時(shí)系統(tǒng)的缺省編碼方式為 GBK 或者 GB2312 。在B 情況下，程序啟動(dòng)時(shí)瀏覽器的 JAVA 控制臺(tái)中出現(xiàn)如下錯(cuò)誤信息：Cant find

32、resource for sun.awt.windows.awtLocalization_zh_CN然后系統(tǒng)的缺省編碼方式為“8859-1”。2.如果在轉(zhuǎn)換字符串時(shí)不采用系統(tǒng)缺省編碼方式，而是直接采用 “GBK” 或“GB2312”，則在 A 情況下程序仍然可正常運(yùn)行，在 B 情況下，系統(tǒng)出現(xiàn)錯(cuò)誤：UnsupportedEncodingException。3.在客戶機(jī)上，把 JDK 的 CLASSES.ZIP 解壓后，放在另一個(gè)目錄中， CLASSPATH 只包含該目錄。然后一邊逐步刪除該目錄中的 .CLASS 文件，另一邊運(yùn)行測(cè)試程序，最后發(fā)現(xiàn)在一千多個(gè) CLASS 文件中，只有一個(gè)是必不可

33、少的，該文件是：sun.io.CharToByteDoubleByte.class。將該文件拷到服務(wù)器端和其它的類放在一起，并在程序的開頭 IMPORT 它，在 B 情況下程序仍然無(wú)法正常運(yùn)行。4.在 A 情況下，如果在 CLASSPTH 中去掉 sun.io.CharToByteDoubleByte.class ，則程序運(yùn)行時(shí)測(cè)得默認(rèn)編碼方式為“8859-1”，否則為 “GBK” 或 “GB2312” 。如果 JDK 的版本為1.2以上的話，在 B 情況下遇到的問題得到了很好的解決，測(cè)試的步驟同上，有興趣的讀者可以嘗試一下。/bJava 中文問題的根源分析及解決/b在簡(jiǎn)體中文 MS Wind

34、ows 98 + JDK 1.3 下，可以用 System.getProperties() 得到 Java 運(yùn)行環(huán)境的一些基本屬性，類 PoorChinese 可以幫助我們得到這些屬性。類 PoorChinese 的源代碼：public class PoorChinese public static void main(String args) System.getProperties().list(System.out); 執(zhí)行 java PoorChinese 后，我們會(huì)得到:系統(tǒng)變量 file.encoding 的值為 GBK ，user.language 的值為 zh ， user.r

35、egion 的值為 CN ，這些系統(tǒng)變量的值決定了系統(tǒng)默認(rèn)的編碼方式是 GBK 。在上述系統(tǒng)中，下面的代碼將 GB2312 文件轉(zhuǎn)換成 Big5 文件，它們能夠幫助我們理解Java 中漢字編碼的轉(zhuǎn)化:import java.io.*;import java.util.*;public class gb2big5 static int iCharNum=0;public static void main(String args) System.out.println(Input GB2312 file, output Big5 file.);if (args.length!=2) System.

36、err.println(Usage: jview gb2big5 gbfile big5file);System.exit(1); String inputString = readInput(args0);writeOutput(inputString,args1);System.out.println(Number of Characters in file: +iCharNum+.);static void writeOutput(String str, String strOutFile) try FileOutputStream fos = new FileOutputStream(

37、strOutFile);Writer out = new OutputStreamWriter(fos, Big5);out.write(str);out.close();catch (IOException e) e.printStackTrace();e.printStackTrace();static String readInput(String strInFile) StringBuffer buffer = new StringBuffer();try FileInputStream fis = new FileInputStream(strInFile);InputStreamR

38、eader isr = new InputStreamReader(fis, GB2312);Reader in = new BufferedReader(isr);int ch;while (ch = in.read() -1) iCharNum += 1;buffer.append(char)ch);in.close();return buffer.toString();catch (IOException e) e.printStackTrace();return null;編碼轉(zhuǎn)化的過程如下： ByteToCharGB2312 CharToByteBig5GB2312UnicodeBi

39、g5執(zhí)行 java gb2big5 gb.txt big5.txt ，如果 gb.txt 的內(nèi)容是“今天星期三”，則得到的文件 big5.txt 中的字符能夠正確顯示；而如果 gb.txt 的內(nèi)容是“情人節(jié)快樂”，則得到的文件 big5.txt 中對(duì)應(yīng)于“節(jié)”和“樂”的字符都是符號(hào)“？”（0 x3F），可見 sun.io.ByteToCharGB2312 和 sun.io.CharToByteBig5 這兩個(gè)基本類并沒有編好。正如上例一樣， Java 的基本類也可能存在問題。由于國(guó)際化的工作并不是在國(guó)內(nèi)完成的，所以在這些基本類發(fā)布之前，沒有經(jīng)過嚴(yán)格的測(cè)試，所以對(duì)中文字符的支持并不像Java S

40、oft 所聲稱的那樣完美。前不久，我的一位技術(shù)上的朋友發(fā)信給我說，他終于找到了 Java Servlet 中文問題的根源。兩周以來，他一直為 Java Servlet 的中文問題所困擾，因?yàn)槊棵鎸?duì)一個(gè)含有中文字符的字符串都必須進(jìn)行強(qiáng)制轉(zhuǎn)換才能夠得到正確的結(jié)果（這好象是大家公認(rèn)的唯一的解決辦法）。后來，他確實(shí)不想如此繼續(xù)安分下去了，因?yàn)檫@樣的事情確實(shí)不應(yīng)該是高級(jí)程序員所要做的工作，他就找出 Servlet 解碼的源代碼進(jìn)行分析，因?yàn)樗麘岩蓡栴}就出在解碼這部分。經(jīng)過四個(gè)小時(shí)的奮斗，他終于找到了問題的根源所在。原來他的懷疑是正確的， Servlet 的解碼部分完全沒有考慮雙字節(jié)，直接把 %XX 當(dāng)作

41、一個(gè)字符。（原來 Java Soft 也會(huì)犯這幺低級(jí)的錯(cuò)誤?。┤绻銓?duì)這個(gè)問題有興趣或者遇到了同樣的煩惱的話，你可以按照他的步驟對(duì) Servlet.jar 進(jìn)行修改：找到源代碼 HttpUtils 中的 static private String parseName ，在返回前將 sb（StringBuffer） 復(fù)制成 byte bs ，然后 return new String(bs,”GB2312”)。作上述修改后就需要自己解碼了：HashTable form=HttpUtils .parseQueryString(request.getQueryString()或者form=HttpUt

42、ils.parsePostData()千萬(wàn)別忘了編譯后放到 Servlet.jar 里面。五、 關(guān)于 Java 中文問題的總結(jié)Java 編程語(yǔ)言成長(zhǎng)于網(wǎng)絡(luò)世界，這就要求 Java 對(duì)多國(guó)字符有很好的支持。 Java 編程語(yǔ)言適應(yīng)了計(jì)算的網(wǎng)絡(luò)化的需求，為它能夠在網(wǎng)絡(luò)世界迅速成長(zhǎng)奠定了堅(jiān)實(shí)的基礎(chǔ)。 Java 的締造者 （Java Soft） 已經(jīng)考慮到 Java 編程語(yǔ)言對(duì)多國(guó)字符的支持，只是現(xiàn)在的解決方案有很多缺陷在里面，需要我們付諸一些補(bǔ)償性的措施。而世界標(biāo)準(zhǔn)化組織也在努力把人類所有的文字統(tǒng)一在一種編碼之中，其中一種方案是 ISO10646 ，它用四個(gè)字節(jié)來表示一個(gè)字符。當(dāng)然，在這種方案未被采

43、用之前，還是希望 Java Soft 能夠嚴(yán)格地測(cè)試它的產(chǎn)品，為用戶帶來更多的方便。附一個(gè)用于從數(shù)據(jù)庫(kù)和網(wǎng)絡(luò)中取出中文亂碼的處理函數(shù)，入?yún)⑹怯袉栴}的字符串，出參是問題已經(jīng)解決了的字符串。 String parseChinese(String in) String s = null; byte temp ; if (in = null) System.out.println(Warn:Chinese null founded!); return new String(); try temp=in.getBytes(iso-8859-1); temp=in.getBytes(iso-8859-1)

44、; s = new String(temp); System.out.println(Warn:Chinese null founded!); return new String(); try temp=in.getBytes(iso-8859-1); s = new String(temp); catch(UnsupportedEncodingException e) System.out.println (e.toString(); return s; 作者簡(jiǎn)介段明輝，清華大學(xué)電子工程系學(xué)生現(xiàn)在正在清華大學(xué)微電子學(xué)研究所從事 Java 智能卡微處理器的研究和開發(fā)yaya_316 www68

45、207295領(lǐng)導(dǎo)BBS 水木清華站的 Java 討論組，為眾多 Java 技術(shù)應(yīng)用者提供解決方案/JAVA漢字顯示問題的解決方案 在基于 Java 語(yǔ)言的編程中，我們經(jīng)常碰到漢字的處理及顯示的問題。一大堆看不懂的亂碼肯定不是我們?cè)敢饪吹降娘@示效果，怎樣才能夠讓那些漢字正確顯示呢？Java 語(yǔ)言默認(rèn)的編碼方式是UNICODE ，而我們中國(guó)人通常使用的文件和數(shù)據(jù)庫(kù)都是基于 GB2312 或者 BIG5 等方式編碼的，怎樣才能夠恰當(dāng)?shù)剡x擇漢字編碼方式并正確地處理漢字的編碼呢？本文將從漢字編碼的常識(shí)入手，結(jié)合 Java編程實(shí)例，分析以上兩個(gè)問題并提出解決它們的方案?，F(xiàn)在 Java 編程語(yǔ)言已經(jīng)廣泛應(yīng)用

46、于互聯(lián)網(wǎng)世界，早在 Sun 公司開發(fā) Java 語(yǔ)言的時(shí)候，就已經(jīng)考慮到對(duì)非英文字符的支持了。Sun 公司公布的 Java 運(yùn)行環(huán)境（JRE）本身就分英文版和國(guó)際版，但只有國(guó)際版才支持非英文字符。不過在 Java 編程語(yǔ)言的應(yīng)用中，對(duì)中文字符的支持并非如同 JavaSoft 的標(biāo)準(zhǔn)規(guī)范中所宣稱的那樣完美，因?yàn)橹形淖址恢灰粋€(gè)，而且不同的操作系統(tǒng)對(duì)中文字符的支持也不盡相同，所以會(huì)有許多和漢字編碼處理有關(guān)的問題在我們進(jìn)行應(yīng)用開發(fā)中困擾著我們。有很多關(guān)于這些問題的解答，但都比較瑣碎，并不能夠滿足大家迫切解決問題的愿望，關(guān)于 Java 中文問題的系統(tǒng)研究并不多，本文從漢字編碼常識(shí)出發(fā)，分析 Java

47、 中文問題，希望對(duì)大家解決這個(gè)問題有所幫助。一、漢字編碼的常識(shí)我們知道，英文字符一般是以一個(gè)字節(jié)來表示的，最常用的編碼方法是 ASCII 。但一個(gè)字節(jié)最多只能區(qū)分256個(gè)字符，而漢字成千上萬(wàn)，所以現(xiàn)在都以雙字節(jié)來表示漢字，為了能夠與英文字符分開，每個(gè)字節(jié)的最高位一定為1，這樣雙字節(jié)最多可以表示64K格字符。我們經(jīng)常碰到的編碼方式有 GB2312、BIG5、UNICODE 等。關(guān)于具體編碼方式的詳細(xì)資料，有興趣的讀者可以查閱相關(guān)資料。我膚淺談一下和我們關(guān)系密切的 GB2312 和 UNICODE。GB2312 碼，中華人民共和國(guó)國(guó)家標(biāo)準(zhǔn)漢字信息交換用編碼，是一個(gè)由中華人民共和國(guó)國(guó)家標(biāo)準(zhǔn)總局發(fā)布的

48、關(guān)于簡(jiǎn)化漢字的編碼，通行于中國(guó)大陸地區(qū)及新加坡，簡(jiǎn)稱國(guó)標(biāo)碼。兩個(gè)字節(jié)中，第一個(gè)字節(jié)（高字節(jié)）的值為區(qū)號(hào)值加32（20H），第二個(gè)字節(jié)（低字節(jié)）的值為位號(hào)值加32（20H），用這兩個(gè)值來表示一個(gè)漢字的編碼。UNICODE 碼是微軟提出的解決多國(guó)字符問題的多字節(jié)等長(zhǎng)編碼，它對(duì)英文字符采取前面加“0”字節(jié)的策略實(shí)現(xiàn)等長(zhǎng)兼容。如 “A” 的 ASCII碼為0 x41，UNICODE 就為0 x00，0 x41。利用特殊的工具各種編碼之間可以互相轉(zhuǎn)換。二、Java 中文問題的初步認(rèn)識(shí)我們基于 Java 編程語(yǔ)言進(jìn)行應(yīng)用開發(fā)時(shí)，不可避免地要處理中文。Java 編程語(yǔ)言默認(rèn)的編碼方式是 UNICODE，而我

49、們通常使用的數(shù)據(jù)庫(kù)及文件都是基于 GB2312 編碼的，我們經(jīng)常碰到這樣的情況：瀏覽基于 JSP 技術(shù)的網(wǎng)站看到的是亂碼，文件打開后看到的也是亂碼，被 Java 修改過的數(shù)據(jù)庫(kù)的內(nèi)容在別的場(chǎng)合應(yīng)用時(shí)無(wú)法繼續(xù)正確地提供信息。String sEnglish = “apple”;String sChinese = “蘋果”;String s = “蘋果 apple ”;sEnglish 的長(zhǎng)度是5，sChinese的長(zhǎng)度是4，而 s 默認(rèn)的長(zhǎng)度是14。對(duì)于 sEnglish來說， Java中的各個(gè)類都支持得非常好，肯定能夠正確顯示。但對(duì)于 sChinese 和 s 來說，雖然 Java Soft 聲

50、明Java 的基本類已經(jīng)考慮到對(duì)多國(guó)字符的支持（默認(rèn) UNICODE 編碼），但是如果操作系統(tǒng)的默認(rèn)編碼不是 UNICODE ，而是國(guó)標(biāo)碼等。從 Java 源代碼到得到正確的結(jié)果，要經(jīng)過 “Java 源代碼- Java 字節(jié)碼- ;虛擬機(jī)-操作系統(tǒng)-顯示設(shè)備”的過程。在上述過程中的每一步驟，我們都必須正確地處理漢字的編碼，才能夠使最終的顯示結(jié)果正確?！?Java 源代碼- Java 字節(jié)碼”，標(biāo)準(zhǔn)的 Java 編譯器 javac 使用的字符集是系統(tǒng)默認(rèn)的字符集，比如在中文 Windows 操作系統(tǒng)上就是 GBK ,而在 Linux 操作系統(tǒng)上就是ISO-8859-1，所以大家會(huì)發(fā)現(xiàn)在 Linu

51、x 操作系統(tǒng)上編譯的類中源文件中的中文字符都出了問題，解決的辦法就是在編譯的時(shí)候添加 encoding 參數(shù)，這樣才能夠與平臺(tái)無(wú)關(guān)。用法是javac encoding GBK?！?Java 字節(jié)碼-虛擬機(jī)-操作系統(tǒng)”， Java 運(yùn)行環(huán)境 （JRE） 分英文版和國(guó)際版，但只有國(guó)際版才支持非英文字符。 Java 開發(fā)工具包 （JDK） 肯定支持多國(guó)字符，但并非所有的計(jì)算機(jī)用戶都安裝了 JDK 。很多操作系統(tǒng)及應(yīng)用軟件為了能夠更好的支持 Java ，都內(nèi)嵌了 JRE 的國(guó)際版本，為自己支持多國(guó)字符提供了方便。“操作系統(tǒng)-顯示設(shè)備”，對(duì)于漢字來說，操作系統(tǒng)必須支持并能夠顯示它。英文操作系統(tǒng)如果不搭配

52、特殊的應(yīng)用軟件的話，是肯定不能夠顯示中文的。還有一個(gè)問題，就是在 Java 編程過程中，對(duì)中文字符進(jìn)行正確的編碼轉(zhuǎn)換。例如，向網(wǎng)頁(yè)輸出中文字符串的時(shí)候，不論你是用 out.println(string); / string 是含中文的字符串 還是用 ，都必須作 UNICODE 到 GBK 的轉(zhuǎn)換，或者手動(dòng)，或者自動(dòng)。在 JSP 1.0中，可以定義輸出字符集，從而實(shí)現(xiàn)內(nèi)碼的自動(dòng)轉(zhuǎn)換。用法是但是在一些 JSP 版本中并沒有提供對(duì)輸出字符集的支持，（例如 JSP 0.92），這就需要手動(dòng)編碼輸出了，方法非常多。最常用的方法是String s1 = request.getParameter(“keyw

53、ord”);String s2 = new String(s1.getBytes(“ISO-8859-1”),”GBK”);getBytes 方法用于將中文字符以“ISO-8859-1”編碼方式轉(zhuǎn)化成字節(jié)數(shù)組，而“GBK” 是目標(biāo)編碼方式。我們從以ISO-8859-1方式編碼的數(shù)據(jù)庫(kù)中讀出中文字符串 s1 ，經(jīng)過上述轉(zhuǎn)換過程，在支持GBK 字符集的操作系統(tǒng)和應(yīng)用軟件中就能夠正確顯示中文字符串 s2 。三、Java 中文問題的表層分析及處理背景開發(fā)環(huán)境JDK1.15Vcafe2.0JPadPro服務(wù)器端NT IISSybase SystemJconnect（JDBC）客戶端IE5.0Pwin98

54、.CLASS 文件存放在服務(wù)器端，由客戶端的瀏覽器運(yùn)行 APPLET ， APPLET 只起調(diào)入 FRAME 類等主程序的作用。界面包括 Textfield ，TextArea，List，Choice 等。I. 取中文用 JDBC 執(zhí)行 SELECT 語(yǔ)句從服務(wù)器端讀取數(shù)據(jù)（中文）后，將數(shù)據(jù)用 APPEND 方法加到TextArea（TA） ，不能正確顯示。但加到 List 中時(shí)，大部分漢字卻可正確顯示。將數(shù)據(jù)按“ISO-8859-1” 編碼方式轉(zhuǎn)化為字節(jié)數(shù)組，再按系統(tǒng)缺省編碼方式 （DefaultCharacter Encoding） 轉(zhuǎn)化為 STRING ，即可在 TA 和 List 中正

55、確顯示。程序段如下：dbstr2 = results.getString(1);/After reading the result from DB server，converting it to string.dbbyte1 = dbstr2.getBytes(“iso-8859-1”);dbstr1 = new String(dbbyte1);在轉(zhuǎn)換字符串時(shí)不采用系統(tǒng)默認(rèn)編碼方式，而直接采用“ GBK” 或者 “GB2312” ,在 A 和 B 兩種情況下，從數(shù)據(jù)庫(kù)取數(shù)據(jù)都沒有問題。II. 寫中文到數(shù)據(jù)庫(kù)處理方式與“取中文”相逆，先將 SQL 語(yǔ)句按系統(tǒng)缺省編碼方式轉(zhuǎn)化為字節(jié)數(shù)組，再按“IS

56、O-8859-1”編碼方式轉(zhuǎn)化為 STRING ，最后送去執(zhí)行，則中文信息可正確寫入數(shù)據(jù)庫(kù)。程序段如下：sqlstmt = tf_input.getText();/Before sending statement to DB server，converting it to sql statement.dbbyte1 = sqlstmt.getBytes();sqlstmt = newString(dbbyte1,”iso-8859-1”);_stmt = _con.createStatement();_stmt.executeUpdate(sqlstmt);問題：如果客戶機(jī)上存在 CLASSP

57、ATH 指向 JDK 的 CLASSES.ZIP 時(shí)（稱為 A 情況），上述程序代碼可正確執(zhí)行。但是如果客戶機(jī)只有瀏覽器，而沒有 JDK 和 CLASSPATH 時(shí)（稱為 B 情況），則漢字無(wú)法正確轉(zhuǎn)換。我們的分析：1.經(jīng)過測(cè)試，在 A 情況下，程序運(yùn)行時(shí)系統(tǒng)的缺省編碼方式為 GBK 或者 GB2312 。在 B 情況下，程序啟動(dòng)時(shí)瀏覽器的 JAVA 控制臺(tái)中出現(xiàn)如下錯(cuò)誤信息：Cant find resource for sun.awt.windows.awtLocalization_zh_CN然后系統(tǒng)的缺省編碼方式為“8859-1”。2.如果在轉(zhuǎn)換字符串時(shí)不采用系統(tǒng)缺省編碼方式，而是直接采用

58、 “GBK” 或“GB2312”，則在 A情況下程序仍然可正常運(yùn)行，在 B 情況下，系統(tǒng)出現(xiàn)錯(cuò)誤：UnsupportedEncodingException。3.在客戶機(jī)上，把 JDK 的 CLASSES.ZIP 解壓后，放在另一個(gè)目錄中， CLASSPATH 只包含該目錄。然后一邊逐步刪除該目錄中的 .CLASS 文件，另一邊運(yùn)行測(cè)試程序，最后發(fā)現(xiàn)在一千多個(gè) CLASS 文件中，只有一個(gè)是必不可少的，該文件是： sun.io.CharToByteDoubleByte.class。將該文件拷到服務(wù)器端和其它的類放在一起，并在程序的開頭 IMPORT 它，在 B 情況下程序仍然無(wú)法正常運(yùn)行。4.在

59、 A 情況下，如果在 CLASSPTH 中去掉 sun.io.CharToByteDoubleByte.class ，則程序運(yùn)行時(shí)測(cè)得默認(rèn)編碼方式為“8859-1”，否則為 “GBK” 或 “GB2312” 。如果 JDK 的版本為1.2以上的話，在 B 情況下遇到的問題得到了很好的解決，測(cè)試的步驟同上，有興趣的讀者可以嘗試一下。四、Java 中文問題的根源分析及解決在簡(jiǎn)體中文 MS Windows 98 + JDK 1.3 下，可以用 System.getProperties() 得到 Java 運(yùn)行環(huán)境的一些基本屬性，類 PoorChinese 可以幫助我們得到這些屬性。類 PoorChi

60、nese 的源代碼：public class PoorChinese public static void main(String args) System.getProperties().list(System.out);執(zhí)行 java PoorChinese 后，我們會(huì)得到:系統(tǒng)變量 file.encoding 的值為 GBK ，user.language 的值為 zh ， user.region 的值為 CN，這些系統(tǒng)變量的值決定了系統(tǒng)默認(rèn)的編碼方式是 GBK 。在上述系統(tǒng)中，下面的代碼將 GB2312 文件轉(zhuǎn)換成 Big5 文件，它們能夠幫助我們理解 Java 中漢字編碼的轉(zhuǎn)化:imp