發表者討論內容

冷日
(冷日) 發表時間：2008/3/18 6:00

Webmaster

註冊日: 2008/2/19
來自:
發表數: 15771

[轉貼]從漢化到國際化

從漢化到國際化
——UniCode inside, Localization outsite

作者：車東 Email: chedongATbigfoot.com/chedongATchedong.com

寫於：2002/08 最後更新： Wed, 16 Mar 2005 08:30:13 GMT
Feed Back >> ( Read this before you ask question )

版權聲明：可以任意轉載，轉載時請務必以超鏈接形式標明文章原始出處和作者信息及本聲明
 http://www.chedong.com/tech/unicode_java.html

關鍵詞：i18n java jvm locale 亂碼

內容摘要：

Java對輸入輸入首先有一個「字節流」到「字符流」之間的編碼/解碼過程，這個設置是根據系統配置決定的，為什麼PHP之類的應用很少有字符集問題而Java有很好的國際化機制，卻經常出現亂碼問題呢？

簡單的舉例：
有一個包含「你好」這2個中文字的文件實際上是4個字節組成的：C4 E3 BA C3

在英文操作系統中缺省的編碼解碼方式是缺省編碼方式是ISO8859，所以直接從文件中讀取的結果是4個的字節，按ISO8859解碼後在程序中操作的是 4個Java字符，雖然每個JAVA字符是16位Unicode，但每個字符仍是8位字節的映射\u00C4\u00E3\u00BA\u00C3，因此處理的仍是「英文」。而顯示過程中，是瀏覽器將字節流正確的顯示成了相應的中文。

而一個Java應用在GBK編碼方式的操作系統中，直接從文件中讀取4個的字節後，按GBK方式解碼後是2個16位的Java字符\u4F60\u597D，每個字都是相應Unicode的CJK區塊所對應的中文。

更多的例子請參考： Java的中文處理學習筆記

這也就是為什麼在php等應用很少出字符集問題的原因：在服務器端環境缺省一般是英文（ISO8859-1），等於全部處理使用的都是按字節方式處理的。數據輸入輸出過程中編碼方式完全不被改動，因此亂碼問題很少出現。而Java實際上提供了把每個中文直接當成1個「字」而不是2個字節處理的機制，主要的亂碼問題往往是輸入輸出時編碼解碼方式不一致造成的。而且通過Unicode機制，程序除了實現程序界面根據本地化的適應外，甚至程序處理的內容本
身的在不同字符集的操作系統中也是可以通用的，比如：在繁體中文操作系統中編輯的內容，在簡體中文操作系統中也能正常的查詢。以下例子可能更說明問題：

JAVA應用的中文問題：如何通過GNU/Linux系統的本地化設置讓JAVA應用支持中文
Java Web應用設計中的中文問題：通過web.xml設置解決URLEncoder.encode()方法和系統缺省編碼方式相關的問題
以GOOGLE的搜索引擎為例：說明如何將國際化和本地化應用到自己的應用設計中(UniCode inside Localization outsite)

通過GNU/Linux系統的本地化設置讓JAVA應用支持中文

Java編程技術中漢字問題的分析及解決這篇直到最近還經常被一些網站轉貼的文章中有一個例子說明了很多中國程序員遇到漢字亂碼問題的思路："GB2312 it"（漢化）

原文如下：
>>>>>>>
......前不久，我的一位技術上的朋友發信給我說，他終於找到了 Java Servlet 中文問題的根源。兩週以來，他一直為 Java Servlet
的中文問題所困擾，因為每面對一個含有中文字符的字符串都必須進行強制轉換才能夠得到正確的結果（這好像是大家公認的唯一的解決辦法）。後來，他確實不想如此繼續安分下去了，因為這樣的事情確實不應該是高級程序員所要做的工作，他就找出 Servlet 解碼的源代碼進行分析，因為他懷疑問題就出在解碼這部分。經過四個小時的奮鬥，他終於找到了問題的根源所在。原來他的懷疑是正確的，Servlet 的解碼部分完全沒有考慮雙字節，直接把 %XX 當作一個字符。（原來 Java Soft 也會犯這?低級的錯誤！）

如果你對這個問題有興趣或者遇到了同樣的煩惱的話，你可以按照他的步驟對 Servlet.jar 進行修改：

找到源代碼 HttpUtils 中的 static private String parseName ，在返回前將 sb（StringBuffer）複製成 byte bs[] ，然後 return newString(bs,」GB2312」)。作上述修改後就需要自己解碼了：

HashTable form=HttpUtils .parseQueryString(request.getQueryString())或者

form=HttpUtils.parsePostData(……)

千萬別忘了編譯後放到 Servlet.jar 裡面。
......
<<<<<<<<<

請問這位「高級」程序員幾個問題：

如果這是一個商業產品的話，難道客戶需要你Hacking過的Servlet.jar才運行這個應用嗎？
難道這個產品只能用在中文平台的GB2312上嗎？如果是日文應用怎麼辦，如法Hacking嗎？

也許我錯了，但我的感覺是犯低級錯誤的不是JAVA：

首先，在Servlet層就不應該考慮中文輸出的問題，因為，在MVC的設計模式中，Servlet主要的角色是 Contrallor，所以，在這一層中，數據應該最好還是Unicode形式，在最後讓Jsp或者通過xslt做針對客戶端瀏覽器的輸出時，再需要考慮本地字符集編碼的問題。
作為一個標準的國際化應用，JAVA應用的缺省編碼方式不應該是在WEB應用這一層設置的，而是JVM根據系統缺省編碼方式根據操作系統的環境設置(locale,包括字符集，日期格式等本地化環境)改變來實現。

如何設置可以讓GNU/Linux從系統層次就支持中文編碼（讓JVM缺省的file.encoding就按照中文GB2312或者GBK進行編碼解碼）呢？

以上這篇文章發表在2000年年底，當時的GNU/Linux的內核是基於glibc-2.1開發的，而GLIBC2.1對中文的locale支持
還有限，因此，在GNU/Linux上不能根據locale的設置將系統缺省的編碼方式變成GB2312，從而改變JVM缺省的編碼方式。關於 GNU/Linux對l10n的支持請看： GNU/Linux 程序員必讀：中文化與GB18030標準。所以在redhat6.x下，無論你怎麼設置locale，系統缺省的缺省file.encoding都是ISO_8859_1。

在redhat7.x 系統內核所基於的glibc-2.2.x對l10n有了更完整的支持，所以可以通過設置
LC_ALL=zh_CN.GB2312;export LC_ALL
LANG=zh_CN.GB2312;export LANG
讓系統缺省的編碼方式變成GB2312。JVM會根據系統的缺省編碼方式設置系統的file.encoding屬性。之後，應用中任何字節流到字符流的轉換，JVM都會按照這一系統缺省編碼方式進行轉換。因此在基於glibc-2.2以上的GNU/Linux上是可以通過locale的設置來改變系統缺省的編碼方式，從而改變上層Java應用的缺省編碼、解碼方式的。

locale設置對JVM file.encoding的影響可以我通過做過的一個試驗說明：
hello_unicode.html

由此可見：

GNU/Linux是依靠GNU的工具發展起來的：沒有GNU就沒有GNU/Linux。所以GNU/Linux對本地化的支持，也是在核心的glibc-2.2.x對中文locale有了更好的支持以後才逐步發展起來的。
GNU/Linux對國際化的支持遠遠落後於WINDOWS SOLARIS等商業操作系統：2年甚至更多。

通過web.xml設置解決URLEncoder.encode()方法和系統缺省編碼方式相關的問題

在我所理解的範圍內，J2SE 1.3中非常不符合Java的國際化規範的是在使用URLEncoder的時候：
比如在中文WIN98上運行的應用，使用URLEncoder.encode(String s)時：比如「中文」這2個字符直接被Encoding的話結果是"%3F%3F"=>"??"。原因很簡單，「中文」在encode()過程中應該先按GBK編碼方式編碼成4個字節（\u00d6\u00d0\u00ce\u00c4）後再進行URLEncoding才是正確的。這個在 J2SE1.4中也修正了。方法encode(String
s)已經不鼓勵使用，取而代之的是除了需要進行URLEncoding的字符串外，同時需要指定字符串編碼方式的encode(String s,String enc)。這樣，URLEncoder就可以和系統缺省的編碼方式無關了。

在J2SE1.3下一個WEB應用如果有這個問題可以通過在WEB-INF/web.xml中設置character-encoding來解決：

...

比如：產品是在中文WINDOWS98中運行，系統缺省字符集是用GBK，則這個應用的web.xml需要設置成：

...

UniCode inside, Localization outsite

以上2個方法仍然只是讓應用更方便地本地化了，而應用本身並不是真正的國際化應用。設想一下如何設計一個全球的論壇系統：可以讓中文和日文的用戶都可以方便的瀏覽發表呢？在數據中間處理階段應該以那種字符集存儲呢？答案很簡單：UniCode。以前很多文章都有關於如何設計一個國際化界面的介紹，只是應用的本地化界面輸出，但很少提及數據在中間處理過程中如何適應國際化。

輸入和存儲階段就用UniCode方式進行處理和存儲，以方便應用以後的國際化 。GOOGLE的設計就是一個非常好的國際化應用榜樣，我以GOOGLE搜索引擎的國際化支持為例說明如何實現國際化應用的設計。

GOOGLE用戶經常有這樣的感覺：

為什麼我第一次去GOOGLE，出現的就是中文的界面？
為什麼在所有網站中查中文：有時候還會匹配到日文網站的結果？比如：就以"google秘密"這個查詢為例：我們在輸入框輸入"google 秘密"
http://www.google.com/search?hl=zh-CN&newwindow=1&q=google+%C3%D8%C3%DC&btnG=Google%CB%D1%CB%F7&lr=

首先我將GOOGLE對查詢的處理流程簡單的說明如下：

客戶端瀏覽器輸入；
查詢字符串按客戶端系統編碼方式（GBK）轉換成字節流，並URL Encode後傳給GOOGLE；
GOOLGE將輸入的字符串URL Decode後，按照客戶端的系統編碼方式將這個字符串（字節串）解碼成UniCode

查詢過程，完全是基於UniCode的匹配過程，比如對於「中文」這2個字在簡體繁體中文和日文裡都有，因此無論是何種語言的頁麵包含這2個字的頁面都能匹配上。
結果集輸出：將查詢結果集的內容（UNICODE）按客戶端系統編碼方式（GBK）「編碼」成的字節流，返回給瀏覽器

具體說明：

GOOGLE如何識別出瀏覽器使用的「界面語言」：GOOGLE獲得這個查詢字符串的同時，一般會根據hl=zh-CN這個參數，知道了客戶端使用的字符集編碼方式，如果用戶第一次訪問：GOOGLE會根據瀏覽器的發送的請求中包含的Accept language: zh_cn這個頭信息來判別，這就是為什麼現在很多用戶第一次去GOOGLE的時候它就能自動識別出來的原因。這個參數在之後的查詢和翻頁過程中通過cookie保存，並通過get方式一直傳遞給GOOGLE（因此你也可以使用使用偏好設置界面語言），從而可靠地識別出客戶端的編碼方式。
GOOGLE如何查詢：也許從URL上你可以看到：傳過去的「秘密」這個查詢實際上是%C3%D8%C3%DC=>"秘密"這2個字按GBK（WINDOWS客戶端缺省的編碼方式）編碼方式的4個字節然後再URLEncode後的形式（關於中文編碼方式請參考：
漢字的編碼方式）， GOOGLE將查詢字符串按這個編碼方式解碼並轉成UniCode，然後用這個UniCode編碼方式的字符串進行內部的查詢操作。而任何語言的頁面都是先轉換成UniCode後存儲在GOOGLE的數據索引庫裡的。在UniCode中日文和中文寫法一樣的字，用的是同樣的編碼。因此，如果你沒有指定語言過濾的話，日文網頁的結果就首先被命中了；因此，對於中文客戶端的查詢：如果相應字符在UniCode中和繁體，日文映射的字一樣，就可以匹配到相應的日文網頁，繁體中文網頁...，GOOGLE的查詢結果也首先是UniCode的，最後將UniCode結果按照客戶端的編碼方式轉換成字節流，返回到客戶端。

從以上的分析中我們可以看出：UniCode非常漂亮的解決了應用的國際化問題。對於應用前端來說，剩下的工作就是根據本地編碼環境進行本地化的過程了。

數據從輸入的開始，就全部先轉換成UniCode，然後再進行處理，並按照UniCode方式集中存儲(UniCode inside)
數據輸出過程中，只是在最後輸出到客戶端的時候，按照客戶端的本地化設置將UniCode數據轉換成本地字符集，並配以相應語言/字符的界面(Localizationoutside)

如果應用的開發只是滿足於在國內市場自給自足，「漢化」的思路的大量出現是很自然的。但要是把「漢化」比作UCDOS和RichWin的話，那麼這種漢化方式遲早要被內核漢化的WIN95淘汰的。畢竟核心級別對國際化的支持才是一個真正簡化前端應用設計、通用的解決方案。Microsoft和Sun 等國際化大公司的產品從一開始就是為全球市場設計的，因此對國際化的支持一致非常重視。相比之下國內軟件行業對相應國際標準顯然重視不足，也很少積極地參與相關標準制定。

參考文檔：
Java i18n
http://java.sun.com/docs/books/tutorial/i18n/index.html

Linux 國際化本地化和中文化
 http://www.linuxforum.net/doc/i18n-new.html

GNU/Linux 程序員必讀：中文化與GB18030標準
 http://www.ccidnet.com/tech/os/2001/07/31/58_2811.html

UniCode FAQ

http://www.cl.cam.ac.uk/~mgk25/UniCode.html
http://www.linuxforum.net/books/UTF-8-UniCode.html （中文版）

Java 編程技術中漢字問題的分析及解決
 http://www-900.ibm.com/developerWorks/cn/java/java_chinese/index.shtml

漢字的編碼方式：
http://www.unihan.com.cn/cjk/ana17.htm

*註釋：l10n i18n都是縮寫：用的是英文單詞的首尾字母和其間字母個數
l10n: localization 本地化
i18n: internationalization 國際化

原文出處：http://www.chedong.com/tech/unicode_java.html

回覆

冷日
(冷日) 發表時間：2008/3/18 6:32

Webmaster

註冊日: 2008/2/19
來自:
發表數: 15771

[轉貼]Java中文處理學習筆記——Hello Unicode

Java中文處理學習筆記——Hello Unicode

作者：車東 Email: chedongATbigfoot.com/chedongATchedong.com

寫於：2002/07 最後更新： Wed, 16 Mar 2005 08:28:17 GMT
Feed Back >> ( Read this before you ask question )

版權聲明：可以任意轉載，轉載時請務必以超鏈接形式標明文章原始出處和作者信息及本聲明
 http://www.chedong.com/tech/hello_unicode.html

關鍵詞：linux java mutlibyte encoding locale i18n i10n chinese ISO-8859-1 GB2312 BIG5 GBK UNICODE

內容摘要：

不知道你有沒有這樣的感受：為什麼PHP很少有亂碼問題而用Java做WEB應用卻這麼麻煩呢？為什麼在Google上能用簡體中文查到繁體中文，甚至日文的結果？而且用Google的時候發現它居然能自動根據我使用瀏覽器的語言選擇自動調出中文界面？

很多國際化應用的讓我理解了這麼一個道理：Unicode是為更方便的做國際化應用設計的，而Java核心的字符是基於UNICODE的，這一機制為應用提供了對中文「字」的控制（而不是字節）。但如果不仔細理解其中的規範，這種自由反而會成為累贅，從而導致更多的亂碼問題：

關於字符集的一些基本概念；
試驗1：顯示系統的環境設置和支持的編碼方式；
試驗2：系統缺省編碼方式對Java應用的輸入輸出影響；
試驗3：在WEB應用中輸出和輸出中的字符集問題；

關於字符集的準備知識：
ISO-8859-1 GB2312 BIG5 GBK GB18030 UNICODE 為什麼會有這麼多字符集編碼方式？

注意：以下說明不是嚴格定義，一些比喻僅作為方便理解使用。

假設一個字符就是棋盤上的一個棋子，有其固定的坐標，如果需要區別所有的字符，就需要有足夠的棋格容納不同的「字符」。　

英文和歐洲其他語言的單字節字符集 (SingleByte Charsets)：
首先對於ISO-8859系列的字符集都想像成一個：2^8 = 16 * 16 = 256個格子的棋盤，這樣所有的西文字符（英文）用這樣一個16×16的坐標系就基本可以覆蓋全了。而英文實際上只用其中小於128(\x80)的部分就夠了。利用大於128部分的空間的不同定義規則形成了真對其他歐洲語言的擴展字符集：ISO-8859-2ISO-8859-4等……

ISO-8859-1

ISO-8859-7

其他語言

英文	其他西歐字符
	o-e-

英文	希臘字符
	μγ

英文	其他單字節
	字符集

GB2312 BIG5 SJIS等多字節字符集（MultiByte Charsets）：

對於亞洲語言來說：漢字這麼多，用這麼一個256格的小棋盤肯定放不下，所以要區別成千上萬的漢字解決辦法就是用2個字節（坐標）來定位一個「字」在棋盤上的位置，將以上規則做一個擴展：

如果第1個字符是小於128(\x80)的仍和英文字符集編碼方式保持兼容；
如果第1個字符是大於128(\x80)的，就當成是漢字的第1個字節，這個自己和後面緊跟的1個字節組成一個漢字；

其結果相當於在位於128以上的小棋格里每個小棋格又劃分出了一個16×16的小棋盤。這樣一個棋盤中的格子數（可能容納的字符數）就變成了128 + 128 * 256。按照類似的方式有了簡體中文的GB2312標準，繁體中文的BIG5字符集和日文的SJIS字符集等，GB2312字符集包含大約有六仟多個常用簡體漢字。

簡體中文

日文SJIS

繁體中文

英文	簡
英文	體
	中
		文

英文	日
英文		文

英文
英文		繁
		體
	中	文

由此可以看出，所有這些從ASCII擴展式的編碼方式中：英文部分都是兼容的，但擴展部分的編碼方式是不兼容的，雖然很多字在3種體系中寫法一致（比如「中文」這2個字）但在相應字符集中的坐標不一致，所以GB2312編寫的頁面用BIG5看就變得面目全非了。而且有時候經常在瀏覽其他非英語國家的頁面時（比如包含有德語的人名時）經常出現奇怪的漢字，其實就是擴展位的編碼衝突造成的。

我把GBK和GB18030理解成一個小UNICODE：GBK字符集是GB2312的擴展(K)，GBK裡大約有貳萬玖仟多個字符，除了保持和 GB2312兼容外，繁體中文字，甚至連日文的假名字符也能顯示。而GB18030-2000則是一個更複雜的字符集，採用變長字節的編碼方式，能夠支持更多的字符。關於漢字的編碼方式比較詳細的定義規範可以參考：
http://www.unihan.com.cn/cjk/ana17.htm

ASCII（英文） ==> 西歐文字 ==> 東歐字符集（俄文，希臘語等） ==> 東亞字符集（GB2312 BIG5 SJIS等）==> 擴展字符集GBK GB18030這個發展過程基本上也反映了字符集標準的發展過程，但這麼隨著時間的推移，尤其是互聯網讓跨語言的信息的交互變得越來越多的時候，太多多針對本地語言的編碼標準的出現導致一個應用程序的國際化變得成本非常高。尤其是你要編寫一個同時包含法文和簡體中文的文檔，這時候一般都會想到要是用一個通用的字符集能夠顯示所有語言的所有文字就好了，而且這樣做應用也能夠比較方便的國際化，為了達到這個目標，即使應用犧牲一些空間和程序效率也是非常值得的。UNICODE就是這樣一個通用的解決方案。

UNICODE雙字節字符集
所以你可以把UNICODE想像成這樣：讓所有的字符（包括英文）都用2個字節（2個8位）表示，這樣就有了一個2^(8*2) = 256 * 256 =65536個格子的大棋盤。在這個棋盤中，這樣中（簡繁）日韓（還包括越南）文字作為CJK字符集都放在一定的區位內，為了減少重複，各種語言中寫法一樣的字共享一個「棋格」。詳細的區位見附錄A

Unicode：(DoubleByte Charsets)

西	C中	其
歐	J日	它
英	K韓	語
文		言

什麼還要有UTF-8？畢竟互聯網70％以上的信息仍然是英文。如果連英文都用2個字節存取(UCS-2)，空間浪費不就太多了？所謂UTF-8就是這樣一個為了提高英文存取效率的字符集轉換格式：Unicode Transformation Form 8-bit form。用UTF-8，UNICODE的2字節字符用變長個（1－3個字節）表示：

對英文，仍然和ASCII一樣用1個字節表示，這個字節的值小於128(\x80)；
對其他語言的用一個值位於128-256之間的字節開始，再加後面緊跟的2個字節表示，一個字符一共是3個字節；

因此，在應用中程序處理過程中所有字符都是16位（雙字節），但在存取轉換成字節流時使用UTF-8格式轉換，對於英文字符來說和原來用ASCII方式存取時相比大小仍然是一樣的，而對中文來說和原來的GB2312編碼方式相比，大小為：(3字節/2字節)=1.5倍

小節：

假設英文字符集是一個16×16的棋盤，麼其他語言的字符集就是把高位區重新分割的(>128)的中等棋盤，多種字符集之間互不兼容而UNICODE本身就相當於一個256×256的大棋盤，通過一定規則將英文和其他所有語言的字符都包含在內。

試驗1：操作系統語言環境設置對Java應用缺省編碼方式的影響

為了了解Java應用的編碼處理的機制，首先要了解操作系統對JVM缺省編碼方式的影響，因此我做了一個 Env.java ，用於打印顯示不同系統下JVM的屬性和系統支持的LOCALE。程序很簡單：

/*
* Copyright (c) 2002 Email: chedongATbigfoot.com/chedongATchedong.com
* $Id: hello_unicode.html,v 1.6 2003/11/09 07:57:11 chedong Exp $
*/

import java.util.*;
import java.text.*;

/**
 ** 目的：
 **     顯示環境變量和JVM的缺省屬性
 ** 輸入：無
 ** 輸出：
 **     1 支持的LOCALE
 **     2 JVM的缺省屬性
 **/
 
 public class Env {
     /**
      **  main entrance
      **/
          public static void main(String[] args) {
          System.out.println("Hello, it's: " +  new Date());
          //print available locales
          Locale list[] = DateFormat.getAvailableLocales();
          System.out.println("======System available locales:======== ");
          for (int i = 0; i < list.length; i++) {
          System.out.println(list[i].toString() + "\t" + list[i].getDisplayName());
          }
          //print JVM default properties
          System.out.println("======System property======== ");
          System.getProperties().list(System.out);
          }
 }

最需要注意的是 JVM的file.encoding屬性 ，這個屬性確定了JVM的缺省的編碼/解碼方式：從而影響應用中所有字節流==>字符流的解碼方式，字符流==>字節流的編碼方式。

LINUX下的LOCALE可以通過 LANG=zh_CN; LC_ALL=zh_CN.GBK; export LANGLC_ALL 設置。locale 命令可以顯示系統當前的環境設置
Windows的LOCALE可以通過控制面板==>區域設置設置實現

GNU/Linux 2.4.x(J2SE1.3.1) LANG=en_US LC_ALL=en_US	GNU/Linux 2.4.x(J2SE1.3.1) LANG=zh_CN LC_ALL=zh_CN.GBK	Windows 2000(J2SE1.3.0) 區域設置:中國中文	Windows 2000(J2SE1.3.0) 區域設置:英國英文
Hello, it's: Tue Jul 30 11:05:44 CST 2002 ======System available locales:======== en English en_US English (United States) ar Arabic ar_AE Arabic (United Arab Emirates) ar_BH Arabic (Bahrain) ar_DZ Arabic (Algeria) ar_EG Arabic (Egypt) ar_IQ Arabic (Iraq) ar_JO Arabic (Jordan) ar_KW Arabic (Kuwait) ar_LB Arabic (Lebanon) ar_LY Arabic (Libya) ar_MA Arabic (Morocco) ar_OM Arabic (Oman) ar_QA Arabic (Qatar) ar_SA Arabic (Saudi Arabia) ar_SD Arabic (Sudan) ar_SY Arabic (Syria) ar_TN Arabic (Tunisia) ar_YE Arabic (Yemen) be Byelorussian be_BY Byelorussian (Belarus) bg Bulgarian bg_BG Bulgarian (Bulgaria) ca Catalan ca_ES Catalan (Spain) ca_ES_EURO Catalan (Spain,Euro) cs Czech cs_CZ Czech (Czech Republic) da Danish da_DK Danish (Denmark) de German de_AT German (Austria) de_AT_EURO German (Austria,Euro) de_CH German (Switzerland) de_DE German (Germany) de_DE_EURO German (Germany,Euro) de_LU German (Luxembourg) de_LU_EURO German (Luxembourg,Euro) el Greek el_GR Greek (Greece) en_AU English (Australia) en_CA English (Canada) en_GB English (United Kingdom) en_IE English (Ireland) en_IE_EURO English (Ireland,Euro) en_NZ English (New Zealand) en_ZA English (South Africa) es Spanish es_BO Spanish (Bolivia) es_AR Spanish (Argentina) es_CL Spanish (Chile) es_CO Spanish (Colombia) es_CR Spanish (Costa Rica) es_DO Spanish (Dominican Republic) es_EC Spanish (Ecuador) es_ES Spanish (Spain) es_ES_EURO Spanish (Spain,Euro) es_GT Spanish (Guatemala) es_HN Spanish (Honduras) es_MX Spanish (Mexico) es_NI Spanish (Nicaragua) et Estonian es_PA Spanish (Panama) es_PE Spanish (Peru) es_PR Spanish (Puerto Rico) es_PY Spanish (Paraguay) es_SV Spanish (El Salvador) es_UY Spanish (Uruguay) es_VE Spanish (Venezuela) et_EE Estonian (Estonia) fi Finnish fi_FI Finnish (Finland) fi_FI_EURO Finnish (Finland,Euro) fr French fr_BE French (Belgium) fr_BE_EURO French (Belgium,Euro) fr_CA French (Canada) fr_CH French (Switzerland) fr_FR French (France) fr_FR_EURO French (France,Euro) fr_LU French (Luxembourg) fr_LU_EURO French (Luxembourg,Euro) hr Croatian hr_HR Croatian (Croatia) hu Hungarian hu_HU Hungarian (Hungary) is Icelandic is_IS Icelandic (Iceland) it Italian it_CH Italian (Switzerland) it_IT Italian (Italy) it_IT_EURO Italian (Italy,Euro) iw Hebrew iw_IL Hebrew (Israel) ja Japanese ja_JP Japanese (Japan) ko Korean ko_KR Korean (South Korea) lt Lithuanian lt_LT Lithuanian (Lithuania) lv Latvian (Lettish) lv_LV Latvian (Lettish) (Latvia) mk Macedonian mk_MK Macedonian (Macedonia) nl Dutch nl_BE Dutch (Belgium) nl_BE_EURO Dutch (Belgium,Euro) nl_NL Dutch (Netherlands) nl_NL_EURO Dutch (Netherlands,Euro) no Norwegian no_NO Norwegian (Norway) no_NO_NY Norwegian (Norway,Nynorsk) pl Polish pl_PL Polish (Poland) pt Portuguese pt_BR Portuguese (Brazil) pt_PT Portuguese (Portugal) pt_PT_EURO Portuguese (Portugal,Euro) ro Romanian ro_RO Romanian (Romania) ru Russian ru_RU Russian (Russia) sh Serbo-Croatian sh_YU Serbo-Croatian (Yugoslavia) sk Slovak sk_SK Slovak (Slovakia) sl Slovenian sl_SI Slovenian (Slovenia) sq Albanian sq_AL Albanian (Albania) sr Serbian sr_YU Serbian (Yugoslavia) sv Swedish sv_SE Swedish (Sweden) th Thai th_TH Thai (Thailand) tr Turkish tr_TR Turkish (Turkey) uk Ukrainian uk_UA Ukrainian (Ukraine) zh Chinese zh_CN Chinese (China) zh_HK Chinese (Hong Kong) zh_TW Chinese (Taiwan) ======System property======== -- listing properties -- java.runtime.name=Java(TM) 2 Runtime Environment, Stand... sun.boot.library.path=/usr/java/jdk1.3.1_04/jre/lib/i386 java.vm.version=1.3.1_04-b02 java.vm.vendor=Sun Microsystems Inc. java.vendor.url=http://java.sun.com/ path.separator=: java.vm.name=Java HotSpot(TM) Client VM file.encoding.pkg=sun.io java.vm.specification.name=Java Virtual Machine Specification user.dir=/home/chedong/src/char_test java.runtime.version=1.3.1_04-b02 java.awt.graphicsenv=sun.awt.X11GraphicsEnvironment os.arch=i386 java.io.tmpdir=/tmp line.separator=java.vm.specification.vendor=Sun Microsystems Inc. java.awt.fonts= os.name=Linux java.library.path=/usr/java/jdk1.3.1_04/jre/lib/i386:/u... java.specification.name=Java Platform API Specification java.class.version=47.0 os.version=2.4.7-10 user.home=/home/chedong user.timezone=Asia/Shanghai java.awt.printerjob=sun.awt.motif.PSPrinterJob <font color="#ff0000">file.encoding=ISO-8859-1</font> java.specification.version=1.3 user.name=chedong java.class.path=/home/chedong/classes java.vm.specification.version=1.0 java.home=/usr/java/jdk1.3.1_04/jre <font color="#ff0000">user.language=en</font> java.specification.vendor=Sun Microsystems Inc. java.vm.info=mixed mode java.version=1.3.1_04 java.ext.dirs=/usr/java/jdk1.3.1_04/jre/lib/ext sun.boot.class.path=/usr/java/jdk1.3.1_04/jre/lib/rt.jar:... java.vendor=Sun Microsystems Inc. file.separator=/ java.vendor.url.bug=http://java.sun.com/cgi-bin/bugreport... sun.cpu.endian=little sun.io.unicode.encoding=UnicodeLittle user.region=US sun.cpu.isalist=
Hello, it's: Tue Jul 30 11:07:34 CST 2002 ======System available locales:======== en 英文 en_US 英文 (美國) ar 阿拉伯文 ar_AE 阿拉伯文 (阿拉伯聯合酋長國) ar_BH 阿拉伯文 (巴林) ar_DZ 阿拉伯文 (阿爾及利亞) ar_EG 阿拉伯文 (埃及) ar_IQ 阿拉伯文 (伊拉克) ar_JO 阿拉伯文 (約旦) ar_KW 阿拉伯文 (科威特) ar_LB 阿拉伯文 (黎巴嫩) ar_LY 阿拉伯文 (利比亞) ar_MA 阿拉伯文 (摩洛哥) ar_OM 阿拉伯文 (阿曼) ar_QA 阿拉伯文 (卡塔爾) ar_SA 阿拉伯文 (沙特阿拉伯) ar_SD 阿拉伯文 (蘇丹) ar_SY 阿拉伯文 (敘利亞) ar_TN 阿拉伯文 (突尼斯) ar_YE 阿拉伯文 (也門) be 白俄羅斯文 be_BY 白俄羅斯文 (白俄羅斯) bg 保加利亞文 bg_BG 保加利亞文 (保加利亞) ca 加泰羅尼亞文 ca_ES 加泰羅尼亞文 (西班牙) ca_ES_EURO 加泰羅尼亞文 (西班牙,Euro) cs 捷克文 cs_CZ 捷克文 (捷克共和國) da 丹麥文 da_DK 丹麥文 (丹麥) de 德文 de_AT 德文 (奧地利) de_AT_EURO 德文 (奧地利,Euro) de_CH 德文 (瑞士) de_DE 德文 (德國) de_DE_EURO 德文 (德國,Euro) de_LU 德文 (盧森堡) de_LU_EURO 德文 (盧森堡,Euro) el 希臘文 el_GR 希臘文 (希臘) en_AU 英文 (澳大利亞) en_CA 英文 (加拿大) en_GB 英文 (英國) en_IE 英文 (愛爾蘭) en_IE_EURO 英文 (愛爾蘭,Euro) en_NZ 英文 (新西蘭) en_ZA 英文 (南非) es 西班牙文 es_BO 西班牙文 (玻利維亞) es_AR 西班牙文 (阿根廷) es_CL 西班牙文 (智利) es_CO 西班牙文 (哥倫比亞) es_CR 西班牙文 (哥斯達黎加) es_DO 西班牙文 (多米尼加共和國) es_EC 西班牙文 (厄瓜多爾) es_ES 西班牙文 (西班牙) es_ES_EURO 西班牙文 (西班牙,Euro) es_GT 西班牙文 (危地馬拉) es_HN 西班牙文 (洪都拉斯) es_MX 西班牙文 (墨西哥) es_NI 西班牙文 (尼加拉瓜) et 愛沙尼亞文 es_PA 西班牙文 (巴拿馬) es_PE 西班牙文 (秘魯) es_PR 西班牙文 (波多黎哥) es_PY 西班牙文 (巴拉圭) es_SV 西班牙文 (薩爾瓦多) es_UY 西班牙文 (烏拉圭) es_VE 西班牙文 (委內瑞拉) et_EE 愛沙尼亞文 (愛沙尼亞) fi 芬蘭文 fi_FI 芬蘭文 (芬蘭) fi_FI_EURO 芬蘭文 (芬蘭,Euro) fr 法文 fr_BE 法文 (比利時) fr_BE_EURO 法文 (比利時,Euro) fr_CA 法文 (加拿大) fr_CH 法文 (瑞士) fr_FR 法文 (法國) fr_FR_EURO 法文 (法國,Euro) fr_LU 法文 (盧森堡) fr_LU_EURO 法文 (盧森堡,Euro) hr 克羅地亞文 hr_HR 克羅地亞文 (克羅地亞) hu 匈牙利文 hu_HU 匈牙利文 (匈牙利) is 冰島文 is_IS 冰島文 (冰島) it 意大利文 it_CH 意大利文 (瑞士) it_IT 意大利文 (意大利) it_IT_EURO 意大利文 (意大利,Euro) iw 希伯來文 iw_IL 希伯來文 (以色列) ja 日文 ja_JP 日文 (日本) ko 朝鮮文 ko_KR 朝鮮文 (南朝鮮) lt 立陶宛文 lt_LT 立陶宛文 (立陶宛) lv 拉托維亞文(列托) lv_LV 拉托維亞文(列托) (拉脫維亞) mk 馬其頓文 mk_MK 馬其頓文 (馬其頓王國) nl 荷蘭文 nl_BE 荷蘭文 (比利時) nl_BE_EURO 荷蘭文 (比利時,Euro) nl_NL 荷蘭文 (荷蘭) nl_NL_EURO 荷蘭文 (荷蘭,Euro) no 挪威文 no_NO 挪威文 (挪威) no_NO_NY 挪威文 (挪威,Nynorsk) pl 波蘭文 pl_PL 波蘭文 (波蘭) pt 葡萄牙文 pt_BR 葡萄牙文 (巴西) pt_PT 葡萄牙文 (葡萄牙) pt_PT_EURO 葡萄牙文 (葡萄牙,Euro) ro 羅馬尼亞文 ro_RO 羅馬尼亞文 (羅馬尼亞) ru 俄文 ru_RU 俄文 (俄羅斯) sh 塞波尼斯-克羅地亞文 sh_YU 塞波尼斯-克羅地亞文 (南斯拉夫) sk 斯洛伐克文 sk_SK 斯洛伐克文 (斯洛伐克) sl 斯洛文尼亞文 sl_SI 斯洛文尼亞文 (斯洛文尼亞) sq 阿爾巴尼亞文 sq_AL 阿爾巴尼亞文 (阿爾巴尼亞) sr 塞爾維亞文 sr_YU 塞爾維亞文 (南斯拉夫) sv 瑞典文 sv_SE 瑞典文 (瑞典) th 泰文 th_TH 泰文 (泰國) tr 土耳其文 tr_TR 土耳其文 (土耳其) uk 烏克蘭文 uk_UA 烏克蘭文 (烏克蘭) zh 中文 zh_CN 中文 (中國) zh_HK 中文 (香港) zh_TW 中文 (台灣) ======System property======== -- listing properties -- java.runtime.name=Java(TM) 2 Runtime Environment, Stand... sun.boot.library.path=/usr/java/jdk1.3.1_04/jre/lib/i386 java.vm.version=1.3.1_04-b02 java.vm.vendor=Sun Microsystems Inc. java.vendor.url=http://java.sun.com/ path.separator=: java.vm.name=Java HotSpot(TM) Client VM file.encoding.pkg=sun.io java.vm.specification.name=Java Virtual Machine Specification user.dir=/home/chedong/src/char_test java.runtime.version=1.3.1_04-b02 java.awt.graphicsenv=sun.awt.X11GraphicsEnvironment os.arch=i386 java.io.tmpdir=/tmp line.separator= java.vm.specification.vendor=Sun Microsystems Inc. java.awt.fonts= os.name=Linux java.library.path=/usr/java/jdk1.3.1_04/jre/lib/i386:/u... java.specification.name=Java Platform API Specification java.class.version=47.0 os.version=2.4.7-10 user.home=/home/chedong user.timezone=Asia/Shanghai java.awt.printerjob=sun.awt.motif.PSPrinterJob <font color="#ff0000">file.encoding=GBK</font> java.specification.version=1.3 user.name=chedong java.class.path=/home/chedong/classes java.vm.specification.version=1.0 java.home=/usr/java/jdk1.3.1_04/jre <font color="#ff0000">user.language=zh</font> java.specification.vendor=Sun Microsystems Inc. java.vm.info=mixed mode java.version=1.3.1_04 java.ext.dirs=/usr/java/jdk1.3.1_04/jre/lib/ext sun.boot.class.path=/usr/java/jdk1.3.1_04/jre/lib/rt.jar:... java.vendor=Sun Microsystems Inc. file.separator=/ java.vendor.url.bug=http://java.sun.com/cgi-bin/bugreport... sun.cpu.endian=little sun.io.unicode.encoding=UnicodeLittle user.region=CN sun.cpu.isalist=
Hello, it's: Tue Jul 30 11:49:36 CST 2002 ======System available locales:======== en English en_US English (United States) ar Arabic ar_AE Arabic (United Arab Emirates) ar_BH Arabic (Bahrain) ar_DZ Arabic (Algeria) ar_EG Arabic (Egypt) ar_IQ Arabic (Iraq) ar_JO Arabic (Jordan) ar_KW Arabic (Kuwait) ar_LB Arabic (Lebanon) ar_LY Arabic (Libya) ar_MA Arabic (Morocco) ar_OM Arabic (Oman) ar_QA Arabic (Qatar) ar_SA Arabic (Saudi Arabia) ar_SD Arabic (Sudan) ar_SY Arabic (Syria) ar_TN Arabic (Tunisia) ar_YE Arabic (Yemen) be Byelorussian be_BY Byelorussian (Belarus) bg Bulgarian bg_BG Bulgarian (Bulgaria) ca Catalan ca_ES Catalan (Spain) ca_ES_EURO Catalan (Spain,Euro) cs Czech cs_CZ Czech (Czech Republic) da Danish da_DK Danish (Denmark) de German de_AT German (Austria) de_AT_EURO German (Austria,Euro) de_CH German (Switzerland) de_DE German (Germany) de_DE_EURO German (Germany,Euro) de_LU German (Luxembourg) de_LU_EURO German (Luxembourg,Euro) el Greek el_GR Greek (Greece) en_AU English (Australia) en_CA English (Canada) en_GB English (United Kingdom) en_IE English (Ireland) en_IE_EURO English (Ireland,Euro) en_NZ English (New Zealand) en_ZA English (South Africa) es Spanish es_AR Spanish (Argentina) es_BO Spanish (Bolivia) es_CL Spanish (Chile) es_CO Spanish (Colombia) es_CR Spanish (Costa Rica) es_DO Spanish (Dominican Republic) es_EC Spanish (Ecuador) es_ES Spanish (Spain) es_ES_EURO Spanish (Spain,Euro) es_GT Spanish (Guatemala) es_HN Spanish (Honduras) es_MX Spanish (Mexico) es_NI Spanish (Nicaragua) es_PA Spanish (Panama) es_PE Spanish (Peru) es_PR Spanish (Puerto Rico) es_PY Spanish (Paraguay) es_SV Spanish (El Salvador) es_UY Spanish (Uruguay) es_VE Spanish (Venezuela) et Estonian et_EE Estonian (Estonia) fi Finnish fi_FI Finnish (Finland) fi_FI_EURO Finnish (Finland,Euro) fr French fr_BE French (Belgium) fr_BE_EURO French (Belgium,Euro) fr_CA French (Canada) fr_CH French (Switzerland) fr_FR French (France) fr_FR_EURO French (France,Euro) fr_LU French (Luxembourg) fr_LU_EURO French (Luxembourg,Euro) hr Croatian hr_HR Croatian (Croatia) hu Hungarian hu_HU Hungarian (Hungary) is Icelandic is_IS Icelandic (Iceland) it Italian it_CH Italian (Switzerland) it_IT Italian (Italy) it_IT_EURO Italian (Italy,Euro) iw Hebrew iw_IL Hebrew (Israel) ja Japanese ja_JP Japanese (Japan) ko 韓文 ko_KR 韓文 (大韓民國) lt Lithuanian lt_LT Lithuanian (Lithuania) lv Latvian (Lettish) lv_LV Latvian (Lettish) (Latvia) mk Macedonian mk_MK Macedonian (Macedonia) nl Dutch nl_BE Dutch (Belgium) nl_BE_EURO Dutch (Belgium,Euro) nl_NL Dutch (Netherlands) nl_NL_EURO Dutch (Netherlands,Euro) no Norwegian no_NO Norwegian (Norway) no_NO_NY Norwegian (Norway,Nynorsk) pl Polish pl_PL Polish (Poland) pt Portuguese pt_BR Portuguese (Brazil) pt_PT Portuguese (Portugal) pt_PT_EURO Portuguese (Portugal,Euro) ro Romanian ro_RO Romanian (Romania) ru Russian ru_RU Russian (Russia) sh Serbo-Croatian sh_YU Serbo-Croatian (Yugoslavia) sk Slovak sk_SK Slovak (Slovakia) sl Slovenian sl_SI Slovenian (Slovenia) sq Albanian sq_AL Albanian (Albania) sr Serbian sr_YU Serbian (Yugoslavia) sv Swedish sv_SE Swedish (Sweden) th Thai th_TH Thai (Thailand) tr Turkish tr_TR Turkish (Turkey) uk Ukrainian uk_UA Ukrainian (Ukraine) zh 中文 zh_CN 中文 (中華人民共和國) zh_HK 中文 (香港) zh_TW 中文 (台灣) ======System property======== -- listing properties -- java.runtime.name=Java(TM) 2 Runtime Environment, Stand... sun.boot.library.path=C:\PROGRAM FILES\JavaSOFT\JRE\1.3.0_0... java.vm.version=1.3.0_02 java.vm.vendor=Sun Microsystems Inc. java.vendor.url=http://java.sun.com/ path.separator=; java.vm.name=Java HotSpot(TM) Client VM file.encoding.pkg=sun.io java.vm.specification.name=Java Virtual Machine Specification user.dir=D:\java\src\char_test java.runtime.version=1.3.0_02 java.awt.graphicsenv=sun.awt.Win32GraphicsEnvironment os.arch=x86 java.io.tmpdir=D:\TEMP\ line.separator= java.vm.specification.vendor=Sun Microsystems Inc. java.awt.fonts= os.name=Windows 98 java.library.path=C:\WINDOWS;.;C:\WINDOWS\SYSTEM;C:\WIN... java.specification.name=Java Platform API Specification java.class.version=47.0 os.version=4.90 user.home=C:\WINDOWS user.timezone=Asia/Shanghai java.awt.printerjob=sun.awt.windows.WPrinterJob <font color="#ff0000">file.encoding=GBK</font> java.specification.version=1.3 user.name=Sicci java.class.path=d:\java\classes java.vm.specification.version=1.0 java.home=C:\PROGRAM FILES\JavaSOFT\JRE\1.3.0_02 <font color="#ff0000">user.language=zh</font> java.specification.vendor=Sun Microsystems Inc. awt.toolkit=sun.awt.windows.WToolkit java.vm.info=mixed mode java.version=1.3.0_02 java.ext.dirs=C:\PROGRAM FILES\JavaSOFT\JRE\1.3.0_0... sun.boot.class.path=C:\PROGRAM FILES\JavaSOFT\JRE\1.3.0_0... java.vendor=Sun Microsystems Inc. file.separator=\ java.vendor.url.bug=http://java.sun.com/cgi-bin/bugreport... sun.cpu.endian=little sun.io.unicode.encoding=UnicodeLittle user.region=CN sun.cpu.isalist=pentium i486 i386
Hello, it's: Tue Jul 30 11:53:27 CST 2002 ======System available locales:======== en English en_US English (United States) ar Arabic ar_AE Arabic (United Arab Emirates) ar_BH Arabic (Bahrain) ar_DZ Arabic (Algeria) ar_EG Arabic (Egypt) ar_IQ Arabic (Iraq) ar_JO Arabic (Jordan) ar_KW Arabic (Kuwait) ar_LB Arabic (Lebanon) ar_LY Arabic (Libya) ar_MA Arabic (Morocco) ar_OM Arabic (Oman) ar_QA Arabic (Qatar) ar_SA Arabic (Saudi Arabia) ar_SD Arabic (Sudan) ar_SY Arabic (Syria) ar_TN Arabic (Tunisia) ar_YE Arabic (Yemen) be Byelorussian be_BY Byelorussian (Belarus) bg Bulgarian bg_BG Bulgarian (Bulgaria) ca Catalan ca_ES Catalan (Spain) ca_ES_EURO Catalan (Spain,Euro) cs Czech cs_CZ Czech (Czech Republic) da Danish da_DK Danish (Denmark) de German de_AT German (Austria) de_AT_EURO German (Austria,Euro) de_CH German (Switzerland) de_DE German (Germany) de_DE_EURO German (Germany,Euro) de_LU German (Luxembourg) de_LU_EURO German (Luxembourg,Euro) el Greek el_GR Greek (Greece) en_AU English (Australia) en_CA English (Canada) en_GB English (United Kingdom) en_IE English (Ireland) en_IE_EURO English (Ireland,Euro) en_NZ English (New Zealand) en_ZA English (South Africa) es Spanish es_AR Spanish (Argentina) es_BO Spanish (Bolivia) es_CL Spanish (Chile) es_CO Spanish (Colombia) es_CR Spanish (Costa Rica) es_DO Spanish (Dominican Republic) es_EC Spanish (Ecuador) es_ES Spanish (Spain) es_ES_EURO Spanish (Spain,Euro) es_GT Spanish (Guatemala) es_HN Spanish (Honduras) es_MX Spanish (Mexico) es_NI Spanish (Nicaragua) es_PA Spanish (Panama) es_PE Spanish (Peru) es_PR Spanish (Puerto Rico) es_PY Spanish (Paraguay) es_SV Spanish (El Salvador) es_UY Spanish (Uruguay) es_VE Spanish (Venezuela) et Estonian et_EE Estonian (Estonia) fi Finnish fi_FI Finnish (Finland) fi_FI_EURO Finnish (Finland,Euro) fr French fr_BE French (Belgium) fr_BE_EURO French (Belgium,Euro) fr_CA French (Canada) fr_CH French (Switzerland) fr_FR French (France) fr_FR_EURO French (France,Euro) fr_LU French (Luxembourg) fr_LU_EURO French (Luxembourg,Euro) hr Croatian hr_HR Croatian (Croatia) hu Hungarian hu_HU Hungarian (Hungary) is Icelandic is_IS Icelandic (Iceland) it Italian it_CH Italian (Switzerland) it_IT Italian (Italy) it_IT_EURO Italian (Italy,Euro) iw Hebrew iw_IL Hebrew (Israel) ja Japanese ja_JP Japanese (Japan) ko Korean ko_KR Korean (South Korea) lt Lithuanian lt_LT Lithuanian (Lithuania) lv Latvian (Lettish) lv_LV Latvian (Lettish) (Latvia) mk Macedonian mk_MK Macedonian (Macedonia) nl Dutch nl_BE Dutch (Belgium) nl_BE_EURO Dutch (Belgium,Euro) nl_NL Dutch (Netherlands) nl_NL_EURO Dutch (Netherlands,Euro) no Norwegian no_NO Norwegian (Norway) no_NO_NY Norwegian (Norway,Nynorsk) pl Polish pl_PL Polish (Poland) pt Portuguese pt_BR Portuguese (Brazil) pt_PT Portuguese (Portugal) pt_PT_EURO Portuguese (Portugal,Euro) ro Romanian ro_RO Romanian (Romania) ru Russian ru_RU Russian (Russia) sh Serbo-Croatian sh_YU Serbo-Croatian (Yugoslavia) sk Slovak sk_SK Slovak (Slovakia) sl Slovenian sl_SI Slovenian (Slovenia) sq Albanian sq_AL Albanian (Albania) sr Serbian sr_YU Serbian (Yugoslavia) sv Swedish sv_SE Swedish (Sweden) th Thai th_TH Thai (Thailand) tr Turkish tr_TR Turkish (Turkey) uk Ukrainian uk_UA Ukrainian (Ukraine) zh Chinese zh_CN Chinese (China) zh_HK Chinese (Hong Kong) zh_TW Chinese (Taiwan) ======System property======== -- listing properties -- java.runtime.name=Java(TM) 2 Runtime Environment, Stand... sun.boot.library.path=C:\PROGRAM FILES\JavaSOFT\JRE\1.3.0_0... java.vm.version=1.3.0_02 java.vm.vendor=Sun Microsystems Inc. java.vendor.url=http://java.sun.com/ path.separator=; java.vm.name=Java HotSpot(TM) Client VM file.encoding.pkg=sun.io java.vm.specification.name=Java Virtual Machine Specification user.dir=D:\java\src\char_test java.runtime.version=1.3.0_02 java.awt.graphicsenv=sun.awt.Win32GraphicsEnvironment os.arch=x86 java.io.tmpdir=D:\TEMP\ line.separator= java.vm.specification.vendor=Sun Microsystems Inc. java.awt.fonts= os.name=Windows 98 java.library.path=C:\WINDOWS;.;C:\WINDOWS\SYSTEM;C:\WIN... java.specification.name=Java Platform API Specification java.class.version=47.0 os.version=4.90 user.home=C:\WINDOWS user.timezone=Asia/Shanghai java.awt.printerjob=sun.awt.windows.WPrinterJob <font color="#ff0000">file.encoding=Cp1252</font> java.specification.version=1.3 user.name=Sicci java.class.path=d:\java\classes java.vm.specification.version=1.0 java.home=C:\PROGRAM FILES\JavaSOFT\JRE\1.3.0_02 <font color="#ff0000">user.language=en</font> java.specification.vendor=Sun Microsystems Inc. awt.toolkit=sun.awt.windows.WToolkit java.vm.info=mixed mode java.version=1.3.0_02 java.ext.dirs=C:\PROGRAM FILES\JavaSOFT\JRE\1.3.0_0... sun.boot.class.path=C:\PROGRAM FILES\JavaSOFT\JRE\1.3.0_0... java.vendor=Sun Microsystems Inc. file.separator=\ java.vendor.url.bug=http://java.sun.com/cgi-bin/bugreport... sun.cpu.endian=little sun.io.unicode.encoding=UnicodeLittle <font color="#ff0000">user.region=GB</font> sun.cpu.isalist=pentium i486 i386 >

結論1：

JVM的缺省編碼方式由系統的「本地語言環境」設置確定，和操作系統的類型無關 。所以當設置成相同的LOCALE時， Linux和Windows下的缺省編碼方式是沒有區別的（可以認為cp1252=ISO-8859-1都是一樣的西文編碼方式，只包含255以下的拉丁字符），因此後面的測試2我只列出了GNU/Linux下LOCALE分別設置成zh_CN和en_US的測試結果輸出。以下測試如果在Windows下分別按照不同的區域和字符集設置後試驗的輸出是一樣的。

試驗2：Java的輸入輸出過程中的字節流到字符流的轉換過程

通過這個 HelloUnicode.java 程序，演示說明"Hello world 世界你好"這個字符串（16個字符）在不同缺省系統編碼方式下的處理效果。在編碼/解碼的每個步驟之後，都打印出了相應字符串每個字符(Charactor)的byte值，short值和所在的UNICODE區間。

LANG=en_US LC_ALL=en_US LANG=zh_CN LC_ALL=zh_CN.GBK

========testing1: write hello world to files========
[test 1-1]: with system default encoding=ISO-8859-1
string=Hello world 世界你好     length=20
char[0]='H'     byte=72 \u48    short=72 \u48   BASIC_LATIN
char[1]='e'     byte=101 \u65   short=101 \u65  BASIC_LATIN
char[2]='l'     byte=108 \u6C   short=108 \u6C  BASIC_LATIN
char[3]='l'     byte=108 \u6C   short=108 \u6C  BASIC_LATIN
char[4]='o'     byte=111 \u6F   short=111 \u6F  BASIC_LATIN
char[5]=' '     byte=32 \u20    short=32 \u20   BASIC_LATIN
char[6]='w'     byte=119 \u77   short=119 \u77  BASIC_LATIN
char[7]='o'     byte=111 \u6F   short=111 \u6F  BASIC_LATIN
char[8]='r'     byte=114 \u72   short=114 \u72  BASIC_LATIN
char[9]='l'     byte=108 \u6C   short=108 \u6C  BASIC_LATIN
char[10]='d'    byte=100 \u64   short=100 \u64  BASIC_LATIN
char[11]=' '    byte=32 \u20    short=32 \u20   BASIC_LATIN
char[12]='?    byte=-54 \uFFFFFFCA     short=202 \uCA  LATIN_1_SUPPLEMENT
char[13]='?    byte=-64 \uFFFFFFC0     short=192 \uC0  LATIN_1_SUPPLEMENT
char[14]='?    byte=-67 \uFFFFFFBD     short=189 \uBD  LATIN_1_SUPPLEMENT
char[15]='?    byte=-25 \uFFFFFFE7     short=231 \uE7  LATIN_1_SUPPLEMENT
char[16]='?    byte=-60 \uFFFFFFC4     short=196 \uC4  LATIN_1_SUPPLEMENT
char[17]='?    byte=-29 \uFFFFFFE3     short=227 \uE3  LATIN_1_SUPPLEMENT
char[18]='?    byte=-70 \uFFFFFFBA     short=186 \uBA  LATIN_1_SUPPLEMENT
char[19]='?    byte=-61 \uFFFFFFC3     short=195 \uC3  LATIN_1_SUPPLEMENT

<font color="#0000ff">第1步：在英文編碼環境下，雖然屏幕上正確的顯示了中文，
但實際上它打印的是「半個」漢字，將結果寫入第1個文件 hello.orig.html</font>
[test 1-2]: getBytes with platform default encoding and decoding as gb2312:
string=Hello world ???? length=16
char[0]='H'     byte=72 \u48    short=72 \u48   BASIC_LATIN
char[1]='e'     byte=101 \u65   short=101 \u65  BASIC_LATIN
char[2]='l'     byte=108 \u6C   short=108 \u6C  BASIC_LATIN
char[3]='l'     byte=108 \u6C   short=108 \u6C  BASIC_LATIN
char[4]='o'     byte=111 \u6F   short=111 \u6F  BASIC_LATIN
char[5]=' '     byte=32 \u20    short=32 \u20   BASIC_LATIN
char[6]='w'     byte=119 \u77   short=119 \u77  BASIC_LATIN
char[7]='o'     byte=111 \u6F   short=111 \u6F  BASIC_LATIN
char[8]='r'     byte=114 \u72   short=114 \u72  BASIC_LATIN
char[9]='l'     byte=108 \u6C   short=108 \u6C  BASIC_LATIN
char[10]='d'    byte=100 \u64   short=100 \u64  BASIC_LATIN
char[11]=' '    byte=32 \u20    short=32 \u20   BASIC_LATIN
char[12]='?'    byte=22 \u16    short=19990 \u4E16      CJK_UNIFIED_IDEOGRAPHS
char[13]='?'    byte=76 \u4C    short=30028 \u754C      CJK_UNIFIED_IDEOGRAPHS
char[14]='?'    byte=96 \u60    short=20320 \u4F60      CJK_UNIFIED_IDEOGRAPHS
char[15]='?'    byte=125 \u7D   short=22909 \u597D      CJK_UNIFIED_IDEOGRAPHS
<font color="#0000ff">按系統缺省編碼重新變成字節流，然後按照GB2312方式解碼，這裡雖然打印出的是問號
（因為當前的英文環境下系統對於255以上的字符是不知道用什麼字符表示的，因此全部用?顯示）
但從相應的UNICODE MAPPING和SHORT值我們可以知道字符是正確的中文</font>
<font color="#0000ff">但下一步的寫入第2個文件html.gb2312.html，
沒有指定編碼方式（按系統缺省的ISO-8859-1編碼方式），
因此從後面的測試2－2讀取的結果是真的'？'了</font>
[test 1-3]: convert string to UTF8
string=Hello world 涓栫?浣? length=24
char[0]='H'     byte=72 \u48    short=72 \u48   BASIC_LATIN
char[1]='e'     byte=101 \u65   short=101 \u65  BASIC_LATIN
char[2]='l'     byte=108 \u6C   short=108 \u6C  BASIC_LATIN
char[3]='l'     byte=108 \u6C   short=108 \u6C  BASIC_LATIN
char[4]='o'     byte=111 \u6F   short=111 \u6F  BASIC_LATIN
char[5]=' '     byte=32 \u20    short=32 \u20   BASIC_LATIN
char[6]='w'     byte=119 \u77   short=119 \u77  BASIC_LATIN
char[7]='o'     byte=111 \u6F   short=111 \u6F  BASIC_LATIN
char[8]='r'     byte=114 \u72   short=114 \u72  BASIC_LATIN
char[9]='l'     byte=108 \u6C   short=108 \u6C  BASIC_LATIN
char[10]='d'    byte=100 \u64   short=100 \u64  BASIC_LATIN
char[11]=' '    byte=32 \u20    short=32 \u20   BASIC_LATIN
char[12]='?    byte=-28 \uFFFFFFE4     short=228 \uE4  LATIN_1_SUPPLEMENT
char[13]='?    byte=-72 \uFFFFFFB8     short=184 \uB8  LATIN_1_SUPPLEMENT
char[14]='?    byte=-106 \uFFFFFF96    short=150 \u96  LATIN_1_SUPPLEMENT
char[15]='?    byte=-25 \uFFFFFFE7     short=231 \uE7  LATIN_1_SUPPLEMENT
char[16]='?    byte=-107 \uFFFFFF95    short=149 \u95  LATIN_1_SUPPLEMENT
char[17]='?    byte=-116 \uFFFFFF8C    short=140 \u8C  LATIN_1_SUPPLEMENT
char[18]='?    byte=-28 \uFFFFFFE4     short=228 \uE4  LATIN_1_SUPPLEMENT
char[19]='?    byte=-67 \uFFFFFFBD     short=189 \uBD  LATIN_1_SUPPLEMENT
char[20]='?    byte=-96 \uFFFFFFA0     short=160 \uA0  LATIN_1_SUPPLEMENT
char[21]='?    byte=-27 \uFFFFFFE5     short=229 \uE5  LATIN_1_SUPPLEMENT
char[22]='?    byte=-91 \uFFFFFFA5     short=165 \uA5  LATIN_1_SUPPLEMENT
char[23]='?    byte=-67 \uFFFFFFBD     short=189 \uBD  LATIN_1_SUPPLEMENT
<font color="#0000ff">第3個試驗，將字符流按照UTF8方式編碼後，寫入第3個測試文件hello.utf8.html，
我們可以看到UTF8對英文沒有影響，但對於其他文字使用了3字節編碼方式，
因此比GB2312編碼方式的存儲要大50%，</font>
========Testing2: reading and decoding from files========
[test 2-1]: read hello.orig.html: decoding with system default encoding
string=Hello world 世界你好     length=20
char[0]='H'     byte=72 \u48    short=72 \u48   BASIC_LATIN
char[1]='e'     byte=101 \u65   short=101 \u65  BASIC_LATIN
char[2]='l'     byte=108 \u6C   short=108 \u6C  BASIC_LATIN
char[3]='l'     byte=108 \u6C   short=108 \u6C  BASIC_LATIN
char[4]='o'     byte=111 \u6F   short=111 \u6F  BASIC_LATIN
char[5]=' '     byte=32 \u20    short=32 \u20   BASIC_LATIN
char[6]='w'     byte=119 \u77   short=119 \u77  BASIC_LATIN
char[7]='o'     byte=111 \u6F   short=111 \u6F  BASIC_LATIN
char[8]='r'     byte=114 \u72   short=114 \u72  BASIC_LATIN
char[9]='l'     byte=108 \u6C   short=108 \u6C  BASIC_LATIN
char[10]='d'    byte=100 \u64   short=100 \u64  BASIC_LATIN
char[11]=' '    byte=32 \u20    short=32 \u20   BASIC_LATIN
char[12]='?    byte=-54 \uFFFFFFCA     short=202 \uCA  LATIN_1_SUPPLEMENT
char[13]='?    byte=-64 \uFFFFFFC0     short=192 \uC0  LATIN_1_SUPPLEMENT
char[14]='?    byte=-67 \uFFFFFFBD     short=189 \uBD  LATIN_1_SUPPLEMENT
char[15]='?    byte=-25 \uFFFFFFE7     short=231 \uE7  LATIN_1_SUPPLEMENT
char[16]='?    byte=-60 \uFFFFFFC4     short=196 \uC4  LATIN_1_SUPPLEMENT
char[17]='?    byte=-29 \uFFFFFFE3     short=227 \uE3  LATIN_1_SUPPLEMENT
char[18]='?    byte=-70 \uFFFFFFBA     short=186 \uBA  LATIN_1_SUPPLEMENT
char[19]='?    byte=-61 \uFFFFFFC3     short=195 \uC3  LATIN_1_SUPPLEMENT
<font color="#0000ff">按系統從中間存儲hello.orig.html文件中讀取相應文件，
雖然是按字節方式（半個「字」）讀取的，但由於能完整的還原，因此輸出顯示沒有錯誤。
其實PHP等應用很少出現字符集問題其實就是這個原因，全程都是按字節流方式處理，
很好的還原了輸入，但這樣處理的同時也失去了對字符的控制</font>
[test 2-2]: read hello.gb2312.html: decoding as GB2312
string=Hello world ???? length=16
char[0]='H'     byte=72 \u48    short=72 \u48   BASIC_LATIN
char[1]='e'     byte=101 \u65   short=101 \u65  BASIC_LATIN
char[2]='l'     byte=108 \u6C   short=108 \u6C  BASIC_LATIN
char[3]='l'     byte=108 \u6C   short=108 \u6C  BASIC_LATIN
char[4]='o'     byte=111 \u6F   short=111 \u6F  BASIC_LATIN
char[5]=' '     byte=32 \u20    short=32 \u20   BASIC_LATIN
char[6]='w'     byte=119 \u77   short=119 \u77  BASIC_LATIN
char[7]='o'     byte=111 \u6F   short=111 \u6F  BASIC_LATIN
char[8]='r'     byte=114 \u72   short=114 \u72  BASIC_LATIN
char[9]='l'     byte=108 \u6C   short=108 \u6C  BASIC_LATIN
char[10]='d'    byte=100 \u64   short=100 \u64  BASIC_LATIN
char[11]=' '    byte=32 \u20    short=32 \u20   BASIC_LATIN
char[12]='?'    byte=63 \u3F    short=63 \u3F   BASIC_LATIN
char[13]='?'    byte=63 \u3F    short=63 \u3F   BASIC_LATIN
char[14]='?'    byte=63 \u3F    short=63 \u3F   BASIC_LATIN
char[15]='?'    byte=63 \u3F    short=63 \u3F   BASIC_LATIN
<font color="#0000ff">最慘的就是輸出的時候這些'?'真的是問號char(63)了，
數據如果是這樣就真的沒救了</font>
[test 2-3]: read hello.utf8.html: decoding as UTF8
string=Hello world ???? length=16
char[0]='H'     byte=72 \u48    short=72 \u48   BASIC_LATIN
char[1]='e'     byte=101 \u65   short=101 \u65  BASIC_LATIN
char[2]='l'     byte=108 \u6C   short=108 \u6C  BASIC_LATIN
char[3]='l'     byte=108 \u6C   short=108 \u6C  BASIC_LATIN
char[4]='o'     byte=111 \u6F   short=111 \u6F  BASIC_LATIN
char[5]=' '     byte=32 \u20    short=32 \u20   BASIC_LATIN
char[6]='w'     byte=119 \u77   short=119 \u77  BASIC_LATIN
char[7]='o'     byte=111 \u6F   short=111 \u6F  BASIC_LATIN
char[8]='r'     byte=114 \u72   short=114 \u72  BASIC_LATIN
char[9]='l'     byte=108 \u6C   short=108 \u6C  BASIC_LATIN
char[10]='d'    byte=100 \u64   short=100 \u64  BASIC_LATIN
char[11]=' '    byte=32 \u20    short=32 \u20   BASIC_LATIN
char[12]='?'    byte=22 \u16    short=19990 \u4E16      CJK_UNIFIED_IDEOGRAPHS
char[13]='?'    byte=76 \u4C    short=30028 \u754C      CJK_UNIFIED_IDEOGRAPHS
char[14]='?'    byte=96 \u60    short=20320 \u4F60      CJK_UNIFIED_IDEOGRAPHS
char[15]='?'    byte=125 \u7D   short=22909 \u597D      CJK_UNIFIED_IDEOGRAPHS
<font color="#0000ff">great! 字符雖然顯示為'?'，但實際上字符的解碼是正確的，
從相應的UNICODE MAPPING就可以看的出來。</font>

========Testing1: write hello world to files========
[test 1-1]: with system default encoding=GBK
string=Hello world 世界你好     length=16
char[0]='H'     byte=72 \u48    short=72 \u48   BASIC_LATIN
char[1]='e'     byte=101 \u65   short=101 \u65  BASIC_LATIN
char[2]='l'     byte=108 \u6C   short=108 \u6C  BASIC_LATIN
char[3]='l'     byte=108 \u6C   short=108 \u6C  BASIC_LATIN
char[4]='o'     byte=111 \u6F   short=111 \u6F  BASIC_LATIN
char[5]=' '     byte=32 \u20    short=32 \u20   BASIC_LATIN
char[6]='w'     byte=119 \u77   short=119 \u77  BASIC_LATIN
char[7]='o'     byte=111 \u6F   short=111 \u6F  BASIC_LATIN
char[8]='r'     byte=114 \u72   short=114 \u72  BASIC_LATIN
char[9]='l'     byte=108 \u6C   short=108 \u6C  BASIC_LATIN
char[10]='d'    byte=100 \u64   short=100 \u64  BASIC_LATIN
char[11]=' '    byte=32 \u20    short=32 \u20   BASIC_LATIN
char[12]='世'   byte=22 \u16    short=19990 \u4E16      CJK_UNIFIED_IDEOGRAPHS
char[13]='界'   byte=76 \u4C    short=30028 \u754C      CJK_UNIFIED_IDEOGRAPHS
char[14]='你'   byte=96 \u60    short=20320 \u4F60      CJK_UNIFIED_IDEOGRAPHS
char[15]='好'   byte=125 \u7D   short=22909 \u597D      CJK_UNIFIED_IDEOGRAPHS
<font color="#0000ff">注意：在新的語言環境中做以上測試需要將源程序重新編譯，
最早的字節流到字符流的解碼過程從JavaC編譯源文件就開始了，
這個測試和剛才最大的不同在於源文件中的「世界你好」這4個字是否按中文編碼方式
編譯導程序裡的，而不是按字節方式編譯成8個字符（實際上對應的是8個字節）在程序裡。</font>
[test 1-2]: getBytes with platform default encoding and decoding as gb2312:
string=Hello world 世界你好     length=16
char[0]='H'     byte=72 \u48    short=72 \u48   BASIC_LATIN
char[1]='e'     byte=101 \u65   short=101 \u65  BASIC_LATIN
char[2]='l'     byte=108 \u6C   short=108 \u6C  BASIC_LATIN
char[3]='l'     byte=108 \u6C   short=108 \u6C  BASIC_LATIN
char[4]='o'     byte=111 \u6F   short=111 \u6F  BASIC_LATIN
char[5]=' '     byte=32 \u20    short=32 \u20   BASIC_LATIN
char[6]='w'     byte=119 \u77   short=119 \u77  BASIC_LATIN
char[7]='o'     byte=111 \u6F   short=111 \u6F  BASIC_LATIN
char[8]='r'     byte=114 \u72   short=114 \u72  BASIC_LATIN
char[9]='l'     byte=108 \u6C   short=108 \u6C  BASIC_LATIN
char[10]='d'    byte=100 \u64   short=100 \u64  BASIC_LATIN
char[11]=' '    byte=32 \u20    short=32 \u20   BASIC_LATIN
char[12]='世'   byte=22 \u16    short=19990 \u4E16      CJK_UNIFIED_IDEOGRAPHS
char[13]='界'   byte=76 \u4C    short=30028 \u754C      CJK_UNIFIED_IDEOGRAPHS
char[14]='你'   byte=96 \u60    short=20320 \u4F60      CJK_UNIFIED_IDEOGRAPHS
char[15]='好'   byte=125 \u7D   short=22909 \u597D      CJK_UNIFIED_IDEOGRAPHS
<font color="#0000ff">在中文環境下，解碼和上面缺省的編碼是一致的，因此輸出一致</font>
[test 1-3]: convert string to UTF8
string=Hello world 涓栫?浣? length=18
char[0]='H'     byte=72 \u48    short=72 \u48   BASIC_LATIN
char[1]='e'     byte=101 \u65   short=101 \u65  BASIC_LATIN
char[2]='l'     byte=108 \u6C   short=108 \u6C  BASIC_LATIN
char[3]='l'     byte=108 \u6C   short=108 \u6C  BASIC_LATIN
char[4]='o'     byte=111 \u6F   short=111 \u6F  BASIC_LATIN
char[5]=' '     byte=32 \u20    short=32 \u20   BASIC_LATIN
char[6]='w'     byte=119 \u77   short=119 \u77  BASIC_LATIN
char[7]='o'     byte=111 \u6F   short=111 \u6F  BASIC_LATIN
char[8]='r'     byte=114 \u72   short=114 \u72  BASIC_LATIN
char[9]='l'     byte=108 \u6C   short=108 \u6C  BASIC_LATIN
char[10]='d'    byte=100 \u64   short=100 \u64  BASIC_LATIN
char[11]=' '    byte=32 \u20    short=32 \u20   BASIC_LATIN
char[12]='涓'   byte=-109 \uFFFFFF93    short=28051 \u6D93      CJK_UNIFIED_IDEOGRAPHS
char[13]='栫'   byte=43 \u2B    short=26667 \u682B      CJK_UNIFIED_IDEOGRAPHS
char[14]='?'   byte=107 \u6B   short=26219 \u666B      CJK_UNIFIED_IDEOGRAPHS
char[15]='浣'   byte=99 \u63    short=28003 \u6D63      CJK_UNIFIED_IDEOGRAPHS
char[16]='?'   byte=-78 \uFFFFFFB2     short=29362 \u72B2      CJK_UNIFIED_IDEOGRAPHS
char[17]=''   byte=-67 \uFFFFFFBD     short=12477 \u30BD      KATAKANA
<font color="#0000ff">其實我們用於測試的終端窗口就是一個GBK字符集的應用，
這個輸出其實都是把UNICODE按GBK字符集解碼的效果。</font>[code]
========Testing2: reading and decoding from files========
[test 2-1]: read hello.orig.html: decoding with system default encoding
string=Hello world 世界你好     length=16
char[0]='H'     byte=72 \u48    short=72 \u48   BASIC_LATIN
char[1]='e'     byte=101 \u65   short=101 \u65  BASIC_LATIN
char[2]='l'     byte=108 \u6C   short=108 \u6C  BASIC_LATIN
char[3]='l'     byte=108 \u6C   short=108 \u6C  BASIC_LATIN
char[4]='o'     byte=111 \u6F   short=111 \u6F  BASIC_LATIN
char[5]=' '     byte=32 \u20    short=32 \u20   BASIC_LATIN
char[6]='w'     byte=119 \u77   short=119 \u77  BASIC_LATIN
char[7]='o'     byte=111 \u6F   short=111 \u6F  BASIC_LATIN
char[8]='r'     byte=114 \u72   short=114 \u72  BASIC_LATIN
char[9]='l'     byte=108 \u6C   short=108 \u6C  BASIC_LATIN
char[10]='d'    byte=100 \u64   short=100 \u64  BASIC_LATIN
char[11]=' '    byte=32 \u20    short=32 \u20   BASIC_LATIN
char[12]='世'   byte=22 \u16    short=19990 \u4E16      CJK_UNIFIED_IDEOGRAPHS
char[13]='界'   byte=76 \u4C    short=30028 \u754C      CJK_UNIFIED_IDEOGRAPHS
char[14]='你'   byte=96 \u60    short=20320 \u4F60      CJK_UNIFIED_IDEOGRAPHS
char[15]='好'   byte=125 \u7D   short=22909 \u597D      CJK_UNIFIED_IDEOGRAPHS
[test 2-2]: read hello.gb2312.html: decoding as GB2312
string=Hello world 世界你好     length=16
char[0]='H'     byte=72 \u48    short=72 \u48   BASIC_LATIN
char[1]='e'     byte=101 \u65   short=101 \u65  BASIC_LATIN
char[2]='l'     byte=108 \u6C   short=108 \u6C  BASIC_LATIN
char[3]='l'     byte=108 \u6C   short=108 \u6C  BASIC_LATIN
char[4]='o'     byte=111 \u6F   short=111 \u6F  BASIC_LATIN
char[5]=' '     byte=32 \u20    short=32 \u20   BASIC_LATIN
char[6]='w'     byte=119 \u77   short=119 \u77  BASIC_LATIN
char[7]='o'     byte=111 \u6F   short=111 \u6F  BASIC_LATIN
char[8]='r'     byte=114 \u72   short=114 \u72  BASIC_LATIN
char[9]='l'     byte=108 \u6C   short=108 \u6C  BASIC_LATIN
char[10]='d'    byte=100 \u64   short=100 \u64  BASIC_LATIN
char[11]=' '    byte=32 \u20    short=32 \u20   BASIC_LATIN
char[12]='世'   byte=22 \u16    short=19990 \u4E16      CJK_UNIFIED_IDEOGRAPHS
char[13]='界'   byte=76 \u4C    short=30028 \u754C      CJK_UNIFIED_IDEOGRAPHS
char[14]='你'   byte=96 \u60    short=20320 \u4F60      CJK_UNIFIED_IDEOGRAPHS
char[15]='好'   byte=125 \u7D   short=22909 \u597D      CJK_UNIFIED_IDEOGRAPHS
[test 2-3]: read hello.utf8.html: decoding as UTF8
string=Hello world 世界你好     length=16
char[0]='H'     byte=72 \u48    short=72 \u48   BASIC_LATIN
char[1]='e'     byte=101 \u65   short=101 \u65  BASIC_LATIN
char[2]='l'     byte=108 \u6C   short=108 \u6C  BASIC_LATIN
char[3]='l'     byte=108 \u6C   short=108 \u6C  BASIC_LATIN
char[4]='o'     byte=111 \u6F   short=111 \u6F  BASIC_LATIN
char[5]=' '     byte=32 \u20    short=32 \u20   BASIC_LATIN
char[6]='w'     byte=119 \u77   short=119 \u77  BASIC_LATIN
char[7]='o'     byte=111 \u6F   short=111 \u6F  BASIC_LATIN
char[8]='r'     byte=114 \u72   short=114 \u72  BASIC_LATIN
char[9]='l'     byte=108 \u6C   short=108 \u6C  BASIC_LATIN
char[10]='d'    byte=100 \u64   short=100 \u64  BASIC_LATIN
char[11]=' '    byte=32 \u20    short=32 \u20   BASIC_LATIN
char[12]='世'   byte=22 \u16    short=19990 \u4E16      CJK_UNIFIED_IDEOGRAPHS
char[13]='界'   byte=76 \u4C    short=30028 \u754C      CJK_UNIFIED_IDEOGRAPHS
char[14]='你'   byte=96 \u60    short=20320 \u4F60      CJK_UNIFIED_IDEOGRAPHS
char[15]='好'   byte=125 \u7D   short=22909 \u597D      CJK_UNIFIED_IDEOGRAPHS

結論：如果後台數據採用UNICODE方式的存儲
然後根據需要指定字符集編碼、解碼方式，則應用幾乎可以不受前端應用所處
環境字符集設置的影響[/code]>

試驗2的一些結論：

所有的應用都是按照字節流=>字符流=>字節流方式進行的處理的：
byte_stream ==[input decoding]==> unicode_char_stream ==[outputencoding]==> byte_stream；
在Java字節流到字符流（或者反之）都是含有隱含的解碼處理的（缺省是按照系統缺省編碼方式）；
最早的字節流解碼過程從javac的代碼編譯就開始了；
Java中的字符character存儲單位是雙字節的UNICODE；

試驗3：WEB應用中的輸入輸出中的編碼問題：Java是為做國際化應用設計的， Servlet應根據瀏覽器語言設置自動切換字符集配置首先一個概念：即使是基於Java的WEB應用，在服務器和客戶端之間傳遞的仍然是字節流，比如我從一個中文客戶端的瀏覽器表單中提交「世界你好」這4個中文字到服務器時：首先瀏覽器按照GBK方式編碼成字節流CA C0 BD E7 C4 E3 BA C3，然後8個字節按照URLEncoding的規範轉成：%CA%C0%BD%E7%C4%E3%BA%C3，服務器端的Servlet接收到請求後應該按什麼解碼處理，輸出時又應該按什麼方式編碼行字節流呢？

在目前的Servlet的規範中，如果不指定的話通過WEB提交時的輸入ServletRequest和輸出時的ServletResponse缺省都是ISO-8859-1方式編/碼解碼的（注意，這裡的編碼/解碼方式是和操作系統環境中的語言環境是無關的）。因此，即使服務器操作系統的語言環境是中文，上面輸入的請求仍然按英文解碼成8個UNICODE字符，輸出時仍按照英文再編碼成8個字節，雖然這樣在瀏覽器端如果設置是中文能夠正確顯示，但實際上讀寫的是「字節」，正確的方式是應該根據客戶端瀏覽器設置ServletRequest和ServletResponse用相應語言的編碼方式進行輸入解碼/輸入編碼，
HelloUnicodeServlet.java 就是這樣一個監測客戶端瀏覽器語言設置的例子：

當根據瀏覽器的頭信息中的"Accept-Language"為zh-cn（中文）時，設置請求的解碼方式和輸出的字符集編碼方式使用GBK：

  //auto detect broswer's languages
        String clientLanguage = req.getHeader("Accept-Language");
        //for Simplied Chinese        
        if ( clientLanguage.equals("zh-cn") ) {            
        req.setCharacterEncoding("GBK");
        res.setContentType("text/html; charset=GBK");
        }

輸出為：

'世界你好' length=4
ServletRequest's Charset Encoding = GBK 
ServletResponse's Charset Encoding = GBK 
char[0]='世' byte=22 \u16 short=19990 \u4E16 CJK_UNIFIED_IDEOGRAPHS
char[1]='界' byte=76 \u4C short=30028 \u754C CJK_UNIFIED_IDEOGRAPHS
char[2]='你' byte=96 \u60 short=20320 \u4F60 CJK_UNIFIED_IDEOGRAPHS
char[3]='好' byte=125 \u7D short=22909 \u597D CJK_UNIFIED_IDEOGRAPHS

再做一個試驗：把程序開頭部分的瀏覽器自動檢測功能註釋掉，再次的輸出結果就是和目前很多應用一樣其實是按ISO-8859-1方式解碼/編碼的「字節應用」了：

'世界你好' length=8
ServletRequest's Charset Encoding = null 
ServletResponse's Charset Encoding = ISO-8859-1 
char[0]='? byte=-54 \uFFFFFFCA short=202 \uCA LATIN_1_SUPPLEMENT
char[1]='? byte=-64 \uFFFFFFC0 short=192 \uC0 LATIN_1_SUPPLEMENT
char[2]='? byte=-67 \uFFFFFFBD short=189 \uBD LATIN_1_SUPPLEMENT
char[3]='? byte=-25 \uFFFFFFE7 short=231 \uE7 LATIN_1_SUPPLEMENT
char[4]='? byte=-60 \uFFFFFFC4 short=196 \uC4 LATIN_1_SUPPLEMENT
char[5]='? byte=-29 \uFFFFFFE3 short=227 \uE3 LATIN_1_SUPPLEMENT
char[6]='? byte=-70 \uFFFFFFBA short=186 \uBA LATIN_1_SUPPLEMENT
char[7]='? byte=-61 \uFFFFFFC3 short=195 \uC3 LATIN_1_SUPPLEMENT

雖然這樣的輸出結果如果在瀏覽器中設置用中文字符集也能正確顯示，但實際上處理的已經是「字節」而不是處理中文「字符」了。ServletRequest 和 ServletResponse 缺省使用ISO-8859-1字符集解碼/編碼的具體定義請參考：
http://java.sun.com/products/servlet/2.3/javadoc/javax/servlet/ServletRequest.html#setCharacterEncoding(java.lang.String)
http://java.sun.com/products/servlet/2.3/javadoc/javax/servlet/ServletResponse.html#setContentType()

以前能夠配置讓一個WEB應用能夠在GBK方式編碼的中文Windows2000服務器上和按ISO-8859-1方式編碼的GNU/Linux上都能夠正確的顯示中文一直讓我迷惑了很久。我仔細想了一下，後來終於想明白了，在一個國際化的應用中：ServletRequest和 ServletResponse的編碼/解碼方式的確不應該根據服務器設置成固定的字符集，而應該是 面向客戶端語言環境進行輸入/輸出編碼方式的自適應 。一個按照國際化規範設計的WEB應用中：

在Servlet的源代碼中儘量不要有中文：因為在MVC模式中，Servlet主要是控制器（C）的角色，因此，應該通過 ResourceBundle機制由Servlet控制轉向到相應的顯示器（JSP或者XSLT）中，所以應該將與本地界面語言相關的界面顯示的部分從Servlet和後台的模塊中完全剝離出來，放到相應的
ResourceBundle 文件中或者XSLT文件中。這樣源程序裡完全是英文，編譯時完全不需要考慮字符集的問題。

如果Servlet實在需要包含中文，則需要設置應用服務器的Javac編譯選項，加上-encoding選項成系統缺省的字符集，如果把用中文編寫的字符按照英文方式解碼編譯，然後再按照英文方式輸出，雖然結果表面正確，實際上都成了面向「字節」編程。

在Servlet層，應該像GOOGLE搜索引擎那樣，設計成能夠根據客戶端瀏覽器的語言環境自適應輸出，為了判斷瀏覽器的語言Servlet中應該有類似以下的代碼：

    public void doGet (HttpServletRequest req, HttpServletResponse res)
          throws ServletException, IOException {
          //從HTTP請求的頭信息中獲取客戶端的語言設置
          String clientLanguage = req.getHeader("Accept-Language");
          //簡體中文瀏覽器     
          if ( clientLanguage.equals("zh-cn") ) {            
          req.setCharacterEncoding("GBK");
          res.setContentType("text/html; charset=GBK");
          }
          //繁體中文瀏覽器
          else if ( clientLanguage.equals("zh-tw") ) {
          req.setCharacterEncoding("BIG5");
          res.setContentType("text/html; charset=BIG5");
          }
          //日文瀏覽器
          else if ( clientLanguage.equals("jp") ) {
          req.setCharacterEncoding("SJIS");
          res.setContentType("text/html; charset=SJIS");
          }
          //缺省認為是英文瀏覽器
          else {
          req.setCharacterEncoding("ISO-8859-1");
          res.setContentType("text/html; charset=ISO-8859-1");
          }
          ...
          //設置好request的解碼方式和response的編碼方式後，進行後續的操作。
          //比如再轉向到HelloWorld.gbk.jsp HelloWorld.big5.jsp HelloWorld.jis.jsp等
          }

而SERVLET缺省將字符集設置為ISO-8859-1也許是標準制定者認為英文的瀏覽器佔大多數吧（而且按照ISO-8859-1方式輸出界面往往也是正確的）。

結論：

過以上幾個Java試驗程序得出的一些結論：

Java環境是基於操作系統上的一個虛擬機應用，因此，如果操作系統遵循國際化規範：JVM的缺省編碼方式可以通過修改操作系統的LOCALE設置實現。對於一個Java應用來說，只要將LINUX的缺省編碼方式設置成GBK，其文字編碼處理應該和中文Windows平台上的表現是一致的。
redhat6.X使用linux內核的是基於glibc2.1.X，不支持中文LOCALE，因此無法通過改變LOCALE設置改變JVM的缺省編碼方式，linux內核2.4開始基於glibc.2.2.x，對中文LOCALE有了比較好的支挼/textarea>

回覆

主題一覽的下方

討論串

前一個主題 | 下一個主題 | 頁首 |

| |

發表新主題

爪哇咖啡屋 : [轉貼]從 漢化 到 國際化

爪哇咖啡屋 : [轉貼]從漢化到國際化