r2100
- 浏览: 29768 次
- 来自: ...
-
最新评论
Java中文处理学习笔记——Hello Unicode
作者： 车东 Email: chedongATbigfoot.com/chedongATchedong.com
写于：2002/07 最后更新： 09/09/2006 17:09:05
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-2 ISO-8859-4等……
ISO-8859-1
ISO-8859-7
其他语言
英文 其他西欧字符
ōē
英文 希腊字符
μγ
英文 其他单字节
字符集
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 LANG LC_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 Englishen_US English (United States)ar Arabicar_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 Byelorussianbe_BY Byelorussian (Belarus)bg Bulgarianbg_BG Bulgarian (Bulgaria)ca Catalanca_ES Catalan (Spain)ca_ES_EURO Catalan (Spain,Euro)cs Czechcs_CZ Czech (Czech Republic)da Danishda_DK Danish (Denmark)de Germande_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 Greekel_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 Spanishes_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 Estonianes_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 Finnishfi_FI Finnish (Finland)fi_FI_EURO Finnish (Finland,Euro)fr Frenchfr_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 Croatianhr_HR Croatian (Croatia)hu Hungarianhu_HU Hungarian (Hungary)is Icelandicis_IS Icelandic (Iceland)it Italianit_CH Italian (Switzerland)it_IT Italian (Italy)it_IT_EURO Italian (Italy,Euro)iw Hebrewiw_IL Hebrew (Israel)ja Japaneseja_JP Japanese (Japan)ko Koreanko_KR Korean (South Korea)lt Lithuanianlt_LT Lithuanian (Lithuania)lv Latvian (Lettish)lv_LV Latvian (Lettish) (Latvia)mk Macedonianmk_MK Macedonian (Macedonia)nl Dutchnl_BE Dutch (Belgium)nl_BE_EURO Dutch (Belgium,Euro)nl_NL Dutch (Netherlands)nl_NL_EURO Dutch (Netherlands,Euro)no Norwegianno_NO Norwegian (Norway)no_NO_NY Norwegian (Norway,Nynorsk)pl Polishpl_PL Polish (Poland)pt Portuguesept_BR Portuguese (Brazil)pt_PT Portuguese (Portugal)pt_PT_EURO Portuguese (Portugal,Euro)ro Romanianro_RO Romanian (Romania)ru Russianru_RU Russian (Russia)sh Serbo-Croatiansh_YU Serbo-Croatian (Yugoslavia)sk Slovaksk_SK Slovak (Slovakia)sl Sloveniansl_SI Slovenian (Slovenia)sq Albaniansq_AL Albanian (Albania)sr Serbiansr_YU Serbian (Yugoslavia)sv Swedishsv_SE Swedish (Sweden)th Thaith_TH Thai (Thailand)tr Turkishtr_TR Turkish (Turkey)uk Ukrainianuk_UA Ukrainian (Ukraine)zh Chinesezh_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/i386java.vm.version=1.3.1_04-b02java.vm.vendor=Sun Microsystems Inc.java.vendor.url=http://java.sun.com/path.separator=:java.vm.name=Java HotSpot(TM) Client VMfile.encoding.pkg=sun.iojava.vm.specification.name=Java Virtual Machine Specificationuser.dir=/home/chedong/src/char_testjava.runtime.version=1.3.1_04-b02java.awt.graphicsenv=sun.awt.X11GraphicsEnvironmentos.arch=i386java.io.tmpdir=/tmpline.separator=java.vm.specification.vendor=Sun Microsystems Inc.java.awt.fonts=os.name=Linuxjava.library.path=/usr/java/jdk1.3.1_04/jre/lib/i386:/u...java.specification.name=Java Platform API Specificationjava.class.version=47.0os.version=2.4.7-10user.home=/home/chedonguser.timezone=Asia/Shanghaijava.awt.printerjob=sun.awt.motif.PSPrinterJobfile.encoding=ISO-8859-1
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
user.language=en
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/i386java.vm.version=1.3.1_04-b02java.vm.vendor=Sun Microsystems Inc.java.vendor.url=http://java.sun.com/path.separator=:java.vm.name=Java HotSpot(TM) Client VMfile.encoding.pkg=sun.iojava.vm.specification.name=Java Virtual Machine Specificationuser.dir=/home/chedong/src/char_testjava.runtime.version=1.3.1_04-b02java.awt.graphicsenv=sun.awt.X11GraphicsEnvironmentos.arch=i386java.io.tmpdir=/tmpline.separator=java.vm.specification.vendor=Sun Microsystems Inc.java.awt.fonts=os.name=Linuxjava.library.path=/usr/java/jdk1.3.1_04/jre/lib/i386:/u...java.specification.name=Java Platform API Specificationjava.class.version=47.0os.version=2.4.7-10user.home=/home/chedonguser.timezone=Asia/Shanghaijava.awt.printerjob=sun.awt.motif.PSPrinterJobfile.encoding=GBK
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
user.language=zh
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 Englishen_US English (United States)ar Arabicar_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 Byelorussianbe_BY Byelorussian (Belarus)bg Bulgarianbg_BG Bulgarian (Bulgaria)ca Catalanca_ES Catalan (Spain)ca_ES_EURO Catalan (Spain,Euro)cs Czechcs_CZ Czech (Czech Republic)da Danishda_DK Danish (Denmark)de Germande_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 Greekel_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 Spanishes_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 Estonianet_EE Estonian (Estonia)fi Finnishfi_FI Finnish (Finland)fi_FI_EURO Finnish (Finland,Euro)fr Frenchfr_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 Croatianhr_HR Croatian (Croatia)hu Hungarianhu_HU Hungarian (Hungary)is Icelandicis_IS Icelandic (Iceland)it Italianit_CH Italian (Switzerland)it_IT Italian (Italy)it_IT_EURO Italian (Italy,Euro)iw Hebrewiw_IL Hebrew (Israel)ja Japaneseja_JP Japanese (Japan)ko 韩文ko_KR 韩文 (大韩民国)lt Lithuanianlt_LT Lithuanian (Lithuania)lv Latvian (Lettish)lv_LV Latvian (Lettish) (Latvia)mk Macedonianmk_MK Macedonian (Macedonia)nl Dutchnl_BE Dutch (Belgium)nl_BE_EURO Dutch (Belgium,Euro)nl_NL Dutch (Netherlands)nl_NL_EURO Dutch (Netherlands,Euro)no Norwegianno_NO Norwegian (Norway)no_NO_NY Norwegian (Norway,Nynorsk)pl Polishpl_PL Polish (Poland)pt Portuguesept_BR Portuguese (Brazil)pt_PT Portuguese (Portugal)pt_PT_EURO Portuguese (Portugal,Euro)ro Romanianro_RO Romanian (Romania)ru Russianru_RU Russian (Russia)sh Serbo-Croatiansh_YU Serbo-Croatian (Yugoslavia)sk Slovaksk_SK Slovak (Slovakia)sl Sloveniansl_SI Slovenian (Slovenia)sq Albaniansq_AL Albanian (Albania)sr Serbiansr_YU Serbian (Yugoslavia)sv Swedishsv_SE Swedish (Sweden)th Thaith_TH Thai (Thailand)tr Turkishtr_TR Turkish (Turkey)uk Ukrainianuk_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_02java.vm.vendor=Sun Microsystems Inc.java.vendor.url=http://java.sun.com/path.separator=;java.vm.name=Java HotSpot(TM) Client VMfile.encoding.pkg=sun.iojava.vm.specification.name=Java Virtual Machine Specificationuser.dir=D:\java\src\char_testjava.runtime.version=1.3.0_02java.awt.graphicsenv=sun.awt.Win32GraphicsEnvironmentos.arch=x86java.io.tmpdir=D:\TEMP\line.separator=java.vm.specification.vendor=Sun Microsystems Inc.java.awt.fonts=os.name=Windows 98java.library.path=C:\WINDOWS;.;C:\WINDOWS\SYSTEM;C:\WIN...java.specification.name=Java Platform API Specificationjava.class.version=47.0os.version=4.90user.home=C:\WINDOWSuser.timezone=Asia/Shanghaijava.awt.printerjob=sun.awt.windows.WPrinterJobfile.encoding=GBK
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
user.language=zh
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 Englishen_US English (United States)ar Arabicar_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 Byelorussianbe_BY Byelorussian (Belarus)bg Bulgarianbg_BG Bulgarian (Bulgaria)ca Catalanca_ES Catalan (Spain)ca_ES_EURO Catalan (Spain,Euro)cs Czechcs_CZ Czech (Czech Republic)da Danishda_DK Danish (Denmark)de Germande_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 Greekel_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 Spanishes_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 Estonianet_EE Estonian (Estonia)fi Finnishfi_FI Finnish (Finland)fi_FI_EURO Finnish (Finland,Euro)fr Frenchfr_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 Croatianhr_HR Croatian (Croatia)hu Hungarianhu_HU Hungarian (Hungary)is Icelandicis_IS Icelandic (Iceland)it Italianit_CH Italian (Switzerland)it_IT Italian (Italy)it_IT_EURO Italian (Italy,Euro)iw Hebrewiw_IL Hebrew (Israel)ja Japaneseja_JP Japanese (Japan)ko Koreanko_KR Korean (South Korea)lt Lithuanianlt_LT Lithuanian (Lithuania)lv Latvian (Lettish)lv_LV Latvian (Lettish) (Latvia)mk Macedonianmk_MK Macedonian (Macedonia)nl Dutchnl_BE Dutch (Belgium)nl_BE_EURO Dutch (Belgium,Euro)nl_NL Dutch (Netherlands)nl_NL_EURO Dutch (Netherlands,Euro)no Norwegianno_NO Norwegian (Norway)no_NO_NY Norwegian (Norway,Nynorsk)pl Polishpl_PL Polish (Poland)pt Portuguesept_BR Portuguese (Brazil)pt_PT Portuguese (Portugal)pt_PT_EURO Portuguese (Portugal,Euro)ro Romanianro_RO Romanian (Romania)ru Russianru_RU Russian (Russia)sh Serbo-Croatiansh_YU Serbo-Croatian (Yugoslavia)sk Slovaksk_SK Slovak (Slovakia)sl Sloveniansl_SI Slovenian (Slovenia)sq Albaniansq_AL Albanian (Albania)sr Serbiansr_YU Serbian (Yugoslavia)sv Swedishsv_SE Swedish (Sweden)th Thaith_TH Thai (Thailand)tr Turkishtr_TR Turkish (Turkey)uk Ukrainianuk_UA Ukrainian (Ukraine)zh Chinesezh_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_02java.vm.vendor=Sun Microsystems Inc.java.vendor.url=http://java.sun.com/path.separator=;java.vm.name=Java HotSpot(TM) Client VMfile.encoding.pkg=sun.iojava.vm.specification.name=Java Virtual Machine Specificationuser.dir=D:\java\src\char_testjava.runtime.version=1.3.0_02java.awt.graphicsenv=sun.awt.Win32GraphicsEnvironmentos.arch=x86java.io.tmpdir=D:\TEMP\line.separator=java.vm.specification.vendor=Sun Microsystems Inc.java.awt.fonts=os.name=Windows 98java.library.path=C:\WINDOWS;.;C:\WINDOWS\SYSTEM;C:\WIN...java.specification.name=Java Platform API Specificationjava.class.version=47.0os.version=4.90user.home=C:\WINDOWSuser.timezone=Asia/Shanghaijava.awt.printerjob=sun.awt.windows.WPrinterJobfile.encoding=Cp1252
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
user.language=en
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=GB
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-1string=Hello world 世界你好 length=20char[0]='H' byte=72 \u48 short=72 \u48 BASIC_LATINchar[1]='e' byte=101 \u65 short=101 \u65 BASIC_LATINchar[2]='l' byte=108 \u6C short=108 \u6C BASIC_LATINchar[3]='l' byte=108 \u6C short=108 \u6C BASIC_LATINchar[4]='o' byte=111 \u6F short=111 \u6F BASIC_LATINchar[5]=' ' byte=32 \u20 short=32 \u20 BASIC_LATINchar[6]='w' byte=119 \u77 short=119 \u77 BASIC_LATINchar[7]='o' byte=111 \u6F short=111 \u6F BASIC_LATINchar[8]='r' byte=114 \u72 short=114 \u72 BASIC_LATINchar[9]='l' byte=108 \u6C short=108 \u6C BASIC_LATINchar[10]='d' byte=100 \u64 short=100 \u64 BASIC_LATINchar[11]=' ' byte=32 \u20 short=32 \u20 BASIC_LATINchar[12]='? byte=-54 \uFFFFFFCA short=202 \uCA LATIN_1_SUPPLEMENTchar[13]='? byte=-64 \uFFFFFFC0 short=192 \uC0 LATIN_1_SUPPLEMENTchar[14]='? byte=-67 \uFFFFFFBD short=189 \uBD LATIN_1_SUPPLEMENTchar[15]='? byte=-25 \uFFFFFFE7 short=231 \uE7 LATIN_1_SUPPLEMENTchar[16]='? byte=-60 \uFFFFFFC4 short=196 \uC4 LATIN_1_SUPPLEMENTchar[17]='? byte=-29 \uFFFFFFE3 short=227 \uE3 LATIN_1_SUPPLEMENTchar[18]='? byte=-70 \uFFFFFFBA short=186 \uBA LATIN_1_SUPPLEMENTchar[19]='? byte=-61 \uFFFFFFC3 short=195 \uC3 LATIN_1_SUPPLEMENT第1步：在英文编码环境下，虽然屏幕上正确的显示了中文，但实际上它打印的是“半个”汉字，将结果写入第1个文件 hello.orig.html
[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
按系统缺省编码重新变成字节流，然后按照GB2312方式解码，这里虽然打印出的是问号（因为当前的英文环境下系统对于255以上的字符是不知道用什么字符表示的，因此全部用?显示）但从相应的UNICODE MAPPING和SHORT值我们可以知道字符是正确的中文但下一步的写入第2个文件html.gb2312.html，没有指定编码方式（按系统缺省的ISO-8859-1编码方式），因此从后面的测试2－2读取的结果是真的'？'了
[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
第3个试验，将字符流按照UTF8方式编码后，写入第3个测试文件hello.utf8.html，我们可以看到UTF8对英文没有影响，但对于其他文字使用了3字节编码方式，因此比GB2312编码方式的存储要大50%，
========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
按系统从中间存储hello.orig.html文件中读取相应文件，虽然是按字节方式（半个“字”）读取的，但由于能完整的还原，因此输出显示没有错误。其实PHP等应用很少出现字符集问题其实就是这个原因，全程都是按字节流方式处理，很好的还原了输入，但这样处理的同时也失去了对字符的控制
[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
最惨的就是输出的时候这些'?'真的是问号char(63)了，数据如果是这样就真的没救了
[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
great! 字符虽然显示为'?'，但实际上字符的解码是正确的，从相应的UNICODE MAPPING就可以看的出来。
========Testing1: write hello world to files========[test 1-1]: with system default encoding=GBKstring=Hello world 世界你好 length=16char[0]='H' byte=72 \u48 short=72 \u48 BASIC_LATINchar[1]='e' byte=101 \u65 short=101 \u65 BASIC_LATINchar[2]='l' byte=108 \u6C short=108 \u6C BASIC_LATINchar[3]='l' byte=108 \u6C short=108 \u6C BASIC_LATINchar[4]='o' byte=111 \u6F short=111 \u6F BASIC_LATINchar[5]=' ' byte=32 \u20 short=32 \u20 BASIC_LATINchar[6]='w' byte=119 \u77 short=119 \u77 BASIC_LATINchar[7]='o' byte=111 \u6F short=111 \u6F BASIC_LATINchar[8]='r' byte=114 \u72 short=114 \u72 BASIC_LATINchar[9]='l' byte=108 \u6C short=108 \u6C BASIC_LATINchar[10]='d' byte=100 \u64 short=100 \u64 BASIC_LATINchar[11]=' ' byte=32 \u20 short=32 \u20 BASIC_LATINchar[12]='世' byte=22 \u16 short=19990 \u4E16 CJK_UNIFIED_IDEOGRAPHSchar[13]='界' byte=76 \u4C short=30028 \u754C CJK_UNIFIED_IDEOGRAPHSchar[14]='你' byte=96 \u60 short=20320 \u4F60 CJK_UNIFIED_IDEOGRAPHSchar[15]='好' byte=125 \u7D short=22909 \u597D CJK_UNIFIED_IDEOGRAPHS注意：在新的语言环境中做以上测试需要将源程序重新编译，最早的字节流到字符流的解码过程从JavaC编译源文件就开始了，这个测试和刚才最大的不同在于源文件中的“世界你好”这4个字是否按中文编码方式编译导程序里的，而不是按字节方式编译成8个字符（实际上对应的是8个字节）在程序里。
[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
在中文环境下，解码和上面缺省的编码是一致的，因此输出一致
[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
其实我们用于测试的终端窗口就是一个GBK字符集的应用，这个输出其实都是把UNICODE按GBK字符集解码的效果。
========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方式的存储然后根据需要指定字符集编码、解码方式，则应用几乎可以不受前端应用所处环境字符集设置的影响
试验2的一些结论：
所有的应用都是按照字节流=>字符流=>字节流方式进行的处理的：
byte_stream ==[input decoding]==> unicode_char_stream ==[output encoding]==> 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=4ServletRequest's Charset Encoding = GBK ServletResponse's Charset Encoding = GBK char[0]='世' byte=22 \u16 short=19990 \u4E16 CJK_UNIFIED_IDEOGRAPHSchar[1]='界' byte=76 \u4C short=30028 \u754C CJK_UNIFIED_IDEOGRAPHSchar[2]='你' byte=96 \u60 short=20320 \u4F60 CJK_UNIFIED_IDEOGRAPHSchar[3]='好' byte=125 \u7D short=22909 \u597D CJK_UNIFIED_IDEOGRAPHS
再做一个试验：把程序开头部分的浏览器自动检测功能注释掉，再次的输出结果就是和目前很多应用一样其实是按ISO-8859-1方式解码/编码的“字节应用”了：
'世界你好' length=8ServletRequest's Charset Encoding = null ServletResponse's Charset Encoding = ISO-8859-1 char[0]='? byte=-54 \uFFFFFFCA short=202 \uCA LATIN_1_SUPPLEMENTchar[1]='? byte=-64 \uFFFFFFC0 short=192 \uC0 LATIN_1_SUPPLEMENTchar[2]='? byte=-67 \uFFFFFFBD short=189 \uBD LATIN_1_SUPPLEMENTchar[3]='? byte=-25 \uFFFFFFE7 short=231 \uE7 LATIN_1_SUPPLEMENTchar[4]='? byte=-60 \uFFFFFFC4 short=196 \uC4 LATIN_1_SUPPLEMENTchar[5]='? byte=-29 \uFFFFFFE3 short=227 \uE3 LATIN_1_SUPPLEMENTchar[6]='? byte=-70 \uFFFFFFBA short=186 \uBA LATIN_1_SUPPLEMENTchar[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平台上的表现是一致的。
redhat 6.X使用linux内核的是基于glibc2.1.X，不支持中文LOCALE，因此无法通过改变LOCALE设置改变JVM的缺省编码方式，linux内核2.4开始基于glibc.2.2.x，对中文LOCALE有了比较好的支持。
不同的JVM对字符集的支持程度不同：
比如：IBM的JVM1.3.0开始支持GB18030，SUN的JVM从1.4开始支持GB18030
正确的编码方式不一定表示能正确的显示，正确的显示还要需要相应的前端显示系统（字库）的支持
但对于Linux上的服务应用来说，往往只要能确认字符正确的按照指定的方式编码就够了
如果应用的是基于UNICODE的编码方式处理并使用UTF8字符集做集中存储，这样最便于根据客户端语言环境做本地化输出；
根据以上结论，设计一个适应多语言环境的应用，可以考虑一下2个应用处理模式：
（客户端应用或本地化应用）根据LOCALE，让Java应用根据系统LOCALE的缺省的字符集设置进行切换，按系统缺省的字符集进行编码解码，减少应用在编码处理上的复杂程度。
输入字节流 ==>按系统语言字符集设置将字节流解码==> UNICODE处理 ==> 按系统语言字符集设置将UNICODE编码成字节流 ==> 输出字节流
（服务器端或跨语言平台应用）：在应用的最外端：数据输入输出判断用户语言环境，核心按照UNICODE方式处理存储。可以把各种区域性的字符集（GB2312 BIG5）看成是UNICODE的一个子集。UNICODE存储的数据可以方便的转换成任意字符集。
应用使用UTF8方式存储虽然要增加了存储空间，但也可以大大简化前端应用本地化(i10n)的复杂程度。
简体中文输入 繁体中文输入 简体中文输出 繁体中文输出 \ / \ / 判断用户语言环境：解码 判断用户语言环境：编码 \ / 中间处理过程：UNICODE | UTF8编码存储
随着UNICODE被愈来愈多的系统和平台支持：Python Perl Glibc等，但我们应该珍惜一开始就按照国际化规范设计Java，并将其和新发展起来的XML规范相配合，相信符合国际化规范的应用设计从长远来看会展现出更多的优势。
TODO：
数据库应用中的字符集问题试验：MySQL Oracle JDBC
参考文档：
Java的国际化设计
http://java.sun.com/docs/books/tutorial/i18n/index.html
Linux 国际化本地化和中文化
http://www.linuxforum.net/doc/i18n-new.html
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
不同版本的JVM支持的编码方式
http://java.sun.com/j2se/1.3/docs/guide/intl/encoding.doc.html
http://java.sun.com/j2se/1.4/docs/guide/intl/encoding.doc.html
附录：
A. The Unicode 2.0 Character Set
Characters
Description
\u0000 - \u1FFF
Alphabets
\u0020 - \u007F
Basic Latin
\u0080 - \u00FF
Latin-1 supplement
\u0100 - \u017F
Latin extended-A
\u0180 - \u024F
Latin extended-B
\u0250 - \u02AF
IPA extensions
\u02B0 - \u02FF
Spacing modifier letters
\u0300 - \u036F
Combining diacritical marks
\u0370 - \u03FF
Greek
\u0400 - \u04FF
Cyrillic
\u0530 - \u058F
Armenian
\u0590 - \u05FF
Hebrew
\u0600 - \u06FF
Arabic
\u0900 - \u097F
Devanagari
\u0980 - \u09FF
Bengali
\u0A00 - \u0A7F
Gurmukhi
\u0A80 - \u0AFF
Gujarati
\u0B00 - \u0B7F
Oriya
\u0B80 - \u0BFF
Tamil
\u0C00 - \u0C7F
Telugu
\u0C80 - \u0CFF
Kannada
\u0D00 - \u0D7F
Malayalam
\u0E00 - \u0E7F
Thai
\u0E80 - \u0EFF
Lao
\u0F00 - \u0FBF
Tibetan
\u10A0 - \u10FF
Georgian
\u1100 - \u11FF
Hangul Jamo
\u1E00 - \u1EFF
Latin extended additional
\u1F00 - \u1FFF
Greek extended
\u2000 - \u2FFF
Symbols and punctuation
\u2000 - \u206F
General punctuation
\u2070 - \u209F
Superscripts and subscripts
\u20A0 - \u20CF
Currency symbols
\u20D0 - \u20FF
Combining diacritical marks for symbols
\u2100 - \u214F
Letterlike symbols
\u2150 - \u218F
Number forms
\u2190 - \u21FF
Arrows
\u2200 - \u22FF
Mathematical operators
\u2300 - \u23FF
Miscellaneous technical
\u2400 - \u243F
Control pictures
\u2440 - \u245F
Optical character recognition
\u2460 - \u24FF
Enclosed alphanumerics
\u2500 - \u257F
Box drawing
\u2580 - \u259F
Block elements
\u25A0 - \u25FF
Geometric shapes
\u2600 - \u26FF
Miscellaneous symbols
\u2700 - \u27BF
Dingbats
\u3000 - \u33FF
CJK auxiliary
\u3000 - \u303F
CJK symbols and punctuation
\u3040 - \u309F
Hiragana
\u30A0 - \u30FF
Katakana
\u3100 - \u312F
Bopomofo
\u3130 - \u318F
Hangul compatibility Jamo
\u3190 - \u319F
Kanbun
\u3200 - \u32FF
Enclosed CJK letters and months
\u3300 - \u33FF
CJK compatibility
\u4E00 - \u9FFF
CJK unified ideographs: Han characters used in China, Japan, Korea, Taiwan, and Vietnam
\uAC00 - \uD7A3
Hangul syllables
\uD800 - \uDFFF
Surrogates
\uD800 - \uDB7F
High surrogates
\uDB80 - \uDBFF
High private use surrogates
\uDC00 - \uDFFF
Low surrogates
\uE000 - \uF8FF
Private use
\uF900 - \uFFFF
Miscellaneous
\uF900 - \uFAFF
CJK compatibility ideographs
\uFB00 - \uFB4F
Alphabetic presentation forms
\uFB50 - \uFDFF
Arabic presentation forms-A
\uFE20 - \uFE2F
Combing half marks
\uFE30 - \uFE4F
CJK compatibility forms
\uFE50 - \uFE6F
Small form variants
\uFE70 - \uFEFE
Arabic presentation forms-B
\uFEFF
Specials
\uFF00 - \uFFEF
Halfwidth and fullwidth forms
\uFFF0 - \uFFFF
Specials
原文出处：<a href="http://www.chedong.com/tech/hello_unicode.html">http://www.chedong.com/tech/hello_unicode.html</a>
<<返回
<<返回首页
作者： 车东 Email: chedongATbigfoot.com/chedongATchedong.com
写于：2002/07 最后更新： 09/09/2006 17:09:05
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-2 ISO-8859-4等……
ISO-8859-1
ISO-8859-7
其他语言
英文 其他西欧字符
ōē
英文 希腊字符
μγ
英文 其他单字节
字符集
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 LANG LC_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 Englishen_US English (United States)ar Arabicar_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 Byelorussianbe_BY Byelorussian (Belarus)bg Bulgarianbg_BG Bulgarian (Bulgaria)ca Catalanca_ES Catalan (Spain)ca_ES_EURO Catalan (Spain,Euro)cs Czechcs_CZ Czech (Czech Republic)da Danishda_DK Danish (Denmark)de Germande_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 Greekel_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 Spanishes_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 Estonianes_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 Finnishfi_FI Finnish (Finland)fi_FI_EURO Finnish (Finland,Euro)fr Frenchfr_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 Croatianhr_HR Croatian (Croatia)hu Hungarianhu_HU Hungarian (Hungary)is Icelandicis_IS Icelandic (Iceland)it Italianit_CH Italian (Switzerland)it_IT Italian (Italy)it_IT_EURO Italian (Italy,Euro)iw Hebrewiw_IL Hebrew (Israel)ja Japaneseja_JP Japanese (Japan)ko Koreanko_KR Korean (South Korea)lt Lithuanianlt_LT Lithuanian (Lithuania)lv Latvian (Lettish)lv_LV Latvian (Lettish) (Latvia)mk Macedonianmk_MK Macedonian (Macedonia)nl Dutchnl_BE Dutch (Belgium)nl_BE_EURO Dutch (Belgium,Euro)nl_NL Dutch (Netherlands)nl_NL_EURO Dutch (Netherlands,Euro)no Norwegianno_NO Norwegian (Norway)no_NO_NY Norwegian (Norway,Nynorsk)pl Polishpl_PL Polish (Poland)pt Portuguesept_BR Portuguese (Brazil)pt_PT Portuguese (Portugal)pt_PT_EURO Portuguese (Portugal,Euro)ro Romanianro_RO Romanian (Romania)ru Russianru_RU Russian (Russia)sh Serbo-Croatiansh_YU Serbo-Croatian (Yugoslavia)sk Slovaksk_SK Slovak (Slovakia)sl Sloveniansl_SI Slovenian (Slovenia)sq Albaniansq_AL Albanian (Albania)sr Serbiansr_YU Serbian (Yugoslavia)sv Swedishsv_SE Swedish (Sweden)th Thaith_TH Thai (Thailand)tr Turkishtr_TR Turkish (Turkey)uk Ukrainianuk_UA Ukrainian (Ukraine)zh Chinesezh_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/i386java.vm.version=1.3.1_04-b02java.vm.vendor=Sun Microsystems Inc.java.vendor.url=http://java.sun.com/path.separator=:java.vm.name=Java HotSpot(TM) Client VMfile.encoding.pkg=sun.iojava.vm.specification.name=Java Virtual Machine Specificationuser.dir=/home/chedong/src/char_testjava.runtime.version=1.3.1_04-b02java.awt.graphicsenv=sun.awt.X11GraphicsEnvironmentos.arch=i386java.io.tmpdir=/tmpline.separator=java.vm.specification.vendor=Sun Microsystems Inc.java.awt.fonts=os.name=Linuxjava.library.path=/usr/java/jdk1.3.1_04/jre/lib/i386:/u...java.specification.name=Java Platform API Specificationjava.class.version=47.0os.version=2.4.7-10user.home=/home/chedonguser.timezone=Asia/Shanghaijava.awt.printerjob=sun.awt.motif.PSPrinterJobfile.encoding=ISO-8859-1
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
user.language=en
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/i386java.vm.version=1.3.1_04-b02java.vm.vendor=Sun Microsystems Inc.java.vendor.url=http://java.sun.com/path.separator=:java.vm.name=Java HotSpot(TM) Client VMfile.encoding.pkg=sun.iojava.vm.specification.name=Java Virtual Machine Specificationuser.dir=/home/chedong/src/char_testjava.runtime.version=1.3.1_04-b02java.awt.graphicsenv=sun.awt.X11GraphicsEnvironmentos.arch=i386java.io.tmpdir=/tmpline.separator=java.vm.specification.vendor=Sun Microsystems Inc.java.awt.fonts=os.name=Linuxjava.library.path=/usr/java/jdk1.3.1_04/jre/lib/i386:/u...java.specification.name=Java Platform API Specificationjava.class.version=47.0os.version=2.4.7-10user.home=/home/chedonguser.timezone=Asia/Shanghaijava.awt.printerjob=sun.awt.motif.PSPrinterJobfile.encoding=GBK
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
user.language=zh
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 Englishen_US English (United States)ar Arabicar_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 Byelorussianbe_BY Byelorussian (Belarus)bg Bulgarianbg_BG Bulgarian (Bulgaria)ca Catalanca_ES Catalan (Spain)ca_ES_EURO Catalan (Spain,Euro)cs Czechcs_CZ Czech (Czech Republic)da Danishda_DK Danish (Denmark)de Germande_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 Greekel_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 Spanishes_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 Estonianet_EE Estonian (Estonia)fi Finnishfi_FI Finnish (Finland)fi_FI_EURO Finnish (Finland,Euro)fr Frenchfr_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 Croatianhr_HR Croatian (Croatia)hu Hungarianhu_HU Hungarian (Hungary)is Icelandicis_IS Icelandic (Iceland)it Italianit_CH Italian (Switzerland)it_IT Italian (Italy)it_IT_EURO Italian (Italy,Euro)iw Hebrewiw_IL Hebrew (Israel)ja Japaneseja_JP Japanese (Japan)ko 韩文ko_KR 韩文 (大韩民国)lt Lithuanianlt_LT Lithuanian (Lithuania)lv Latvian (Lettish)lv_LV Latvian (Lettish) (Latvia)mk Macedonianmk_MK Macedonian (Macedonia)nl Dutchnl_BE Dutch (Belgium)nl_BE_EURO Dutch (Belgium,Euro)nl_NL Dutch (Netherlands)nl_NL_EURO Dutch (Netherlands,Euro)no Norwegianno_NO Norwegian (Norway)no_NO_NY Norwegian (Norway,Nynorsk)pl Polishpl_PL Polish (Poland)pt Portuguesept_BR Portuguese (Brazil)pt_PT Portuguese (Portugal)pt_PT_EURO Portuguese (Portugal,Euro)ro Romanianro_RO Romanian (Romania)ru Russianru_RU Russian (Russia)sh Serbo-Croatiansh_YU Serbo-Croatian (Yugoslavia)sk Slovaksk_SK Slovak (Slovakia)sl Sloveniansl_SI Slovenian (Slovenia)sq Albaniansq_AL Albanian (Albania)sr Serbiansr_YU Serbian (Yugoslavia)sv Swedishsv_SE Swedish (Sweden)th Thaith_TH Thai (Thailand)tr Turkishtr_TR Turkish (Turkey)uk Ukrainianuk_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_02java.vm.vendor=Sun Microsystems Inc.java.vendor.url=http://java.sun.com/path.separator=;java.vm.name=Java HotSpot(TM) Client VMfile.encoding.pkg=sun.iojava.vm.specification.name=Java Virtual Machine Specificationuser.dir=D:\java\src\char_testjava.runtime.version=1.3.0_02java.awt.graphicsenv=sun.awt.Win32GraphicsEnvironmentos.arch=x86java.io.tmpdir=D:\TEMP\line.separator=java.vm.specification.vendor=Sun Microsystems Inc.java.awt.fonts=os.name=Windows 98java.library.path=C:\WINDOWS;.;C:\WINDOWS\SYSTEM;C:\WIN...java.specification.name=Java Platform API Specificationjava.class.version=47.0os.version=4.90user.home=C:\WINDOWSuser.timezone=Asia/Shanghaijava.awt.printerjob=sun.awt.windows.WPrinterJobfile.encoding=GBK
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
user.language=zh
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 Englishen_US English (United States)ar Arabicar_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 Byelorussianbe_BY Byelorussian (Belarus)bg Bulgarianbg_BG Bulgarian (Bulgaria)ca Catalanca_ES Catalan (Spain)ca_ES_EURO Catalan (Spain,Euro)cs Czechcs_CZ Czech (Czech Republic)da Danishda_DK Danish (Denmark)de Germande_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 Greekel_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 Spanishes_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 Estonianet_EE Estonian (Estonia)fi Finnishfi_FI Finnish (Finland)fi_FI_EURO Finnish (Finland,Euro)fr Frenchfr_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 Croatianhr_HR Croatian (Croatia)hu Hungarianhu_HU Hungarian (Hungary)is Icelandicis_IS Icelandic (Iceland)it Italianit_CH Italian (Switzerland)it_IT Italian (Italy)it_IT_EURO Italian (Italy,Euro)iw Hebrewiw_IL Hebrew (Israel)ja Japaneseja_JP Japanese (Japan)ko Koreanko_KR Korean (South Korea)lt Lithuanianlt_LT Lithuanian (Lithuania)lv Latvian (Lettish)lv_LV Latvian (Lettish) (Latvia)mk Macedonianmk_MK Macedonian (Macedonia)nl Dutchnl_BE Dutch (Belgium)nl_BE_EURO Dutch (Belgium,Euro)nl_NL Dutch (Netherlands)nl_NL_EURO Dutch (Netherlands,Euro)no Norwegianno_NO Norwegian (Norway)no_NO_NY Norwegian (Norway,Nynorsk)pl Polishpl_PL Polish (Poland)pt Portuguesept_BR Portuguese (Brazil)pt_PT Portuguese (Portugal)pt_PT_EURO Portuguese (Portugal,Euro)ro Romanianro_RO Romanian (Romania)ru Russianru_RU Russian (Russia)sh Serbo-Croatiansh_YU Serbo-Croatian (Yugoslavia)sk Slovaksk_SK Slovak (Slovakia)sl Sloveniansl_SI Slovenian (Slovenia)sq Albaniansq_AL Albanian (Albania)sr Serbiansr_YU Serbian (Yugoslavia)sv Swedishsv_SE Swedish (Sweden)th Thaith_TH Thai (Thailand)tr Turkishtr_TR Turkish (Turkey)uk Ukrainianuk_UA Ukrainian (Ukraine)zh Chinesezh_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_02java.vm.vendor=Sun Microsystems Inc.java.vendor.url=http://java.sun.com/path.separator=;java.vm.name=Java HotSpot(TM) Client VMfile.encoding.pkg=sun.iojava.vm.specification.name=Java Virtual Machine Specificationuser.dir=D:\java\src\char_testjava.runtime.version=1.3.0_02java.awt.graphicsenv=sun.awt.Win32GraphicsEnvironmentos.arch=x86java.io.tmpdir=D:\TEMP\line.separator=java.vm.specification.vendor=Sun Microsystems Inc.java.awt.fonts=os.name=Windows 98java.library.path=C:\WINDOWS;.;C:\WINDOWS\SYSTEM;C:\WIN...java.specification.name=Java Platform API Specificationjava.class.version=47.0os.version=4.90user.home=C:\WINDOWSuser.timezone=Asia/Shanghaijava.awt.printerjob=sun.awt.windows.WPrinterJobfile.encoding=Cp1252
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
user.language=en
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=GB
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-1string=Hello world 世界你好 length=20char[0]='H' byte=72 \u48 short=72 \u48 BASIC_LATINchar[1]='e' byte=101 \u65 short=101 \u65 BASIC_LATINchar[2]='l' byte=108 \u6C short=108 \u6C BASIC_LATINchar[3]='l' byte=108 \u6C short=108 \u6C BASIC_LATINchar[4]='o' byte=111 \u6F short=111 \u6F BASIC_LATINchar[5]=' ' byte=32 \u20 short=32 \u20 BASIC_LATINchar[6]='w' byte=119 \u77 short=119 \u77 BASIC_LATINchar[7]='o' byte=111 \u6F short=111 \u6F BASIC_LATINchar[8]='r' byte=114 \u72 short=114 \u72 BASIC_LATINchar[9]='l' byte=108 \u6C short=108 \u6C BASIC_LATINchar[10]='d' byte=100 \u64 short=100 \u64 BASIC_LATINchar[11]=' ' byte=32 \u20 short=32 \u20 BASIC_LATINchar[12]='? byte=-54 \uFFFFFFCA short=202 \uCA LATIN_1_SUPPLEMENTchar[13]='? byte=-64 \uFFFFFFC0 short=192 \uC0 LATIN_1_SUPPLEMENTchar[14]='? byte=-67 \uFFFFFFBD short=189 \uBD LATIN_1_SUPPLEMENTchar[15]='? byte=-25 \uFFFFFFE7 short=231 \uE7 LATIN_1_SUPPLEMENTchar[16]='? byte=-60 \uFFFFFFC4 short=196 \uC4 LATIN_1_SUPPLEMENTchar[17]='? byte=-29 \uFFFFFFE3 short=227 \uE3 LATIN_1_SUPPLEMENTchar[18]='? byte=-70 \uFFFFFFBA short=186 \uBA LATIN_1_SUPPLEMENTchar[19]='? byte=-61 \uFFFFFFC3 short=195 \uC3 LATIN_1_SUPPLEMENT第1步：在英文编码环境下，虽然屏幕上正确的显示了中文，但实际上它打印的是“半个”汉字，将结果写入第1个文件 hello.orig.html
[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
按系统缺省编码重新变成字节流，然后按照GB2312方式解码，这里虽然打印出的是问号（因为当前的英文环境下系统对于255以上的字符是不知道用什么字符表示的，因此全部用?显示）但从相应的UNICODE MAPPING和SHORT值我们可以知道字符是正确的中文但下一步的写入第2个文件html.gb2312.html，没有指定编码方式（按系统缺省的ISO-8859-1编码方式），因此从后面的测试2－2读取的结果是真的'？'了
[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
第3个试验，将字符流按照UTF8方式编码后，写入第3个测试文件hello.utf8.html，我们可以看到UTF8对英文没有影响，但对于其他文字使用了3字节编码方式，因此比GB2312编码方式的存储要大50%，
========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
按系统从中间存储hello.orig.html文件中读取相应文件，虽然是按字节方式（半个“字”）读取的，但由于能完整的还原，因此输出显示没有错误。其实PHP等应用很少出现字符集问题其实就是这个原因，全程都是按字节流方式处理，很好的还原了输入，但这样处理的同时也失去了对字符的控制
[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
最惨的就是输出的时候这些'?'真的是问号char(63)了，数据如果是这样就真的没救了
[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
great! 字符虽然显示为'?'，但实际上字符的解码是正确的，从相应的UNICODE MAPPING就可以看的出来。
========Testing1: write hello world to files========[test 1-1]: with system default encoding=GBKstring=Hello world 世界你好 length=16char[0]='H' byte=72 \u48 short=72 \u48 BASIC_LATINchar[1]='e' byte=101 \u65 short=101 \u65 BASIC_LATINchar[2]='l' byte=108 \u6C short=108 \u6C BASIC_LATINchar[3]='l' byte=108 \u6C short=108 \u6C BASIC_LATINchar[4]='o' byte=111 \u6F short=111 \u6F BASIC_LATINchar[5]=' ' byte=32 \u20 short=32 \u20 BASIC_LATINchar[6]='w' byte=119 \u77 short=119 \u77 BASIC_LATINchar[7]='o' byte=111 \u6F short=111 \u6F BASIC_LATINchar[8]='r' byte=114 \u72 short=114 \u72 BASIC_LATINchar[9]='l' byte=108 \u6C short=108 \u6C BASIC_LATINchar[10]='d' byte=100 \u64 short=100 \u64 BASIC_LATINchar[11]=' ' byte=32 \u20 short=32 \u20 BASIC_LATINchar[12]='世' byte=22 \u16 short=19990 \u4E16 CJK_UNIFIED_IDEOGRAPHSchar[13]='界' byte=76 \u4C short=30028 \u754C CJK_UNIFIED_IDEOGRAPHSchar[14]='你' byte=96 \u60 short=20320 \u4F60 CJK_UNIFIED_IDEOGRAPHSchar[15]='好' byte=125 \u7D short=22909 \u597D CJK_UNIFIED_IDEOGRAPHS注意：在新的语言环境中做以上测试需要将源程序重新编译，最早的字节流到字符流的解码过程从JavaC编译源文件就开始了，这个测试和刚才最大的不同在于源文件中的“世界你好”这4个字是否按中文编码方式编译导程序里的，而不是按字节方式编译成8个字符（实际上对应的是8个字节）在程序里。
[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
在中文环境下，解码和上面缺省的编码是一致的，因此输出一致
[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
其实我们用于测试的终端窗口就是一个GBK字符集的应用，这个输出其实都是把UNICODE按GBK字符集解码的效果。
========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方式的存储然后根据需要指定字符集编码、解码方式，则应用几乎可以不受前端应用所处环境字符集设置的影响
试验2的一些结论：
所有的应用都是按照字节流=>字符流=>字节流方式进行的处理的：
byte_stream ==[input decoding]==> unicode_char_stream ==[output encoding]==> 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=4ServletRequest's Charset Encoding = GBK ServletResponse's Charset Encoding = GBK char[0]='世' byte=22 \u16 short=19990 \u4E16 CJK_UNIFIED_IDEOGRAPHSchar[1]='界' byte=76 \u4C short=30028 \u754C CJK_UNIFIED_IDEOGRAPHSchar[2]='你' byte=96 \u60 short=20320 \u4F60 CJK_UNIFIED_IDEOGRAPHSchar[3]='好' byte=125 \u7D short=22909 \u597D CJK_UNIFIED_IDEOGRAPHS
再做一个试验：把程序开头部分的浏览器自动检测功能注释掉，再次的输出结果就是和目前很多应用一样其实是按ISO-8859-1方式解码/编码的“字节应用”了：
'世界你好' length=8ServletRequest's Charset Encoding = null ServletResponse's Charset Encoding = ISO-8859-1 char[0]='? byte=-54 \uFFFFFFCA short=202 \uCA LATIN_1_SUPPLEMENTchar[1]='? byte=-64 \uFFFFFFC0 short=192 \uC0 LATIN_1_SUPPLEMENTchar[2]='? byte=-67 \uFFFFFFBD short=189 \uBD LATIN_1_SUPPLEMENTchar[3]='? byte=-25 \uFFFFFFE7 short=231 \uE7 LATIN_1_SUPPLEMENTchar[4]='? byte=-60 \uFFFFFFC4 short=196 \uC4 LATIN_1_SUPPLEMENTchar[5]='? byte=-29 \uFFFFFFE3 short=227 \uE3 LATIN_1_SUPPLEMENTchar[6]='? byte=-70 \uFFFFFFBA short=186 \uBA LATIN_1_SUPPLEMENTchar[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平台上的表现是一致的。
redhat 6.X使用linux内核的是基于glibc2.1.X，不支持中文LOCALE，因此无法通过改变LOCALE设置改变JVM的缺省编码方式，linux内核2.4开始基于glibc.2.2.x，对中文LOCALE有了比较好的支持。
不同的JVM对字符集的支持程度不同：
比如：IBM的JVM1.3.0开始支持GB18030，SUN的JVM从1.4开始支持GB18030
正确的编码方式不一定表示能正确的显示，正确的显示还要需要相应的前端显示系统（字库）的支持
但对于Linux上的服务应用来说，往往只要能确认字符正确的按照指定的方式编码就够了
如果应用的是基于UNICODE的编码方式处理并使用UTF8字符集做集中存储，这样最便于根据客户端语言环境做本地化输出；
根据以上结论，设计一个适应多语言环境的应用，可以考虑一下2个应用处理模式：
（客户端应用或本地化应用）根据LOCALE，让Java应用根据系统LOCALE的缺省的字符集设置进行切换，按系统缺省的字符集进行编码解码，减少应用在编码处理上的复杂程度。
输入字节流 ==>按系统语言字符集设置将字节流解码==> UNICODE处理 ==> 按系统语言字符集设置将UNICODE编码成字节流 ==> 输出字节流
（服务器端或跨语言平台应用）：在应用的最外端：数据输入输出判断用户语言环境，核心按照UNICODE方式处理存储。可以把各种区域性的字符集（GB2312 BIG5）看成是UNICODE的一个子集。UNICODE存储的数据可以方便的转换成任意字符集。
应用使用UTF8方式存储虽然要增加了存储空间，但也可以大大简化前端应用本地化(i10n)的复杂程度。
简体中文输入 繁体中文输入 简体中文输出 繁体中文输出 \ / \ / 判断用户语言环境：解码 判断用户语言环境：编码 \ / 中间处理过程：UNICODE | UTF8编码存储
随着UNICODE被愈来愈多的系统和平台支持：Python Perl Glibc等，但我们应该珍惜一开始就按照国际化规范设计Java，并将其和新发展起来的XML规范相配合，相信符合国际化规范的应用设计从长远来看会展现出更多的优势。
TODO：
数据库应用中的字符集问题试验：MySQL Oracle JDBC
参考文档：
Java的国际化设计
http://java.sun.com/docs/books/tutorial/i18n/index.html
Linux 国际化本地化和中文化
http://www.linuxforum.net/doc/i18n-new.html
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
不同版本的JVM支持的编码方式
http://java.sun.com/j2se/1.3/docs/guide/intl/encoding.doc.html
http://java.sun.com/j2se/1.4/docs/guide/intl/encoding.doc.html
附录：
A. The Unicode 2.0 Character Set
Characters
Description
\u0000 - \u1FFF
Alphabets
\u0020 - \u007F
Basic Latin
\u0080 - \u00FF
Latin-1 supplement
\u0100 - \u017F
Latin extended-A
\u0180 - \u024F
Latin extended-B
\u0250 - \u02AF
IPA extensions
\u02B0 - \u02FF
Spacing modifier letters
\u0300 - \u036F
Combining diacritical marks
\u0370 - \u03FF
Greek
\u0400 - \u04FF
Cyrillic
\u0530 - \u058F
Armenian
\u0590 - \u05FF
Hebrew
\u0600 - \u06FF
Arabic
\u0900 - \u097F
Devanagari
\u0980 - \u09FF
Bengali
\u0A00 - \u0A7F
Gurmukhi
\u0A80 - \u0AFF
Gujarati
\u0B00 - \u0B7F
Oriya
\u0B80 - \u0BFF
Tamil
\u0C00 - \u0C7F
Telugu
\u0C80 - \u0CFF
Kannada
\u0D00 - \u0D7F
Malayalam
\u0E00 - \u0E7F
Thai
\u0E80 - \u0EFF
Lao
\u0F00 - \u0FBF
Tibetan
\u10A0 - \u10FF
Georgian
\u1100 - \u11FF
Hangul Jamo
\u1E00 - \u1EFF
Latin extended additional
\u1F00 - \u1FFF
Greek extended
\u2000 - \u2FFF
Symbols and punctuation
\u2000 - \u206F
General punctuation
\u2070 - \u209F
Superscripts and subscripts
\u20A0 - \u20CF
Currency symbols
\u20D0 - \u20FF
Combining diacritical marks for symbols
\u2100 - \u214F
Letterlike symbols
\u2150 - \u218F
Number forms
\u2190 - \u21FF
Arrows
\u2200 - \u22FF
Mathematical operators
\u2300 - \u23FF
Miscellaneous technical
\u2400 - \u243F
Control pictures
\u2440 - \u245F
Optical character recognition
\u2460 - \u24FF
Enclosed alphanumerics
\u2500 - \u257F
Box drawing
\u2580 - \u259F
Block elements
\u25A0 - \u25FF
Geometric shapes
\u2600 - \u26FF
Miscellaneous symbols
\u2700 - \u27BF
Dingbats
\u3000 - \u33FF
CJK auxiliary
\u3000 - \u303F
CJK symbols and punctuation
\u3040 - \u309F
Hiragana
\u30A0 - \u30FF
Katakana
\u3100 - \u312F
Bopomofo
\u3130 - \u318F
Hangul compatibility Jamo
\u3190 - \u319F
Kanbun
\u3200 - \u32FF
Enclosed CJK letters and months
\u3300 - \u33FF
CJK compatibility
\u4E00 - \u9FFF
CJK unified ideographs: Han characters used in China, Japan, Korea, Taiwan, and Vietnam
\uAC00 - \uD7A3
Hangul syllables
\uD800 - \uDFFF
Surrogates
\uD800 - \uDB7F
High surrogates
\uDB80 - \uDBFF
High private use surrogates
\uDC00 - \uDFFF
Low surrogates
\uE000 - \uF8FF
Private use
\uF900 - \uFFFF
Miscellaneous
\uF900 - \uFAFF
CJK compatibility ideographs
\uFB00 - \uFB4F
Alphabetic presentation forms
\uFB50 - \uFDFF
Arabic presentation forms-A
\uFE20 - \uFE2F
Combing half marks
\uFE30 - \uFE4F
CJK compatibility forms
\uFE50 - \uFE6F
Small form variants
\uFE70 - \uFEFE
Arabic presentation forms-B
\uFEFF
Specials
\uFF00 - \uFFEF
Halfwidth and fullwidth forms
\uFFF0 - \uFFFF
Specials
原文出处：<a href="http://www.chedong.com/tech/hello_unicode.html">http://www.chedong.com/tech/hello_unicode.html</a>
<<返回
<<返回首页
分享到：
发表评论
-
JAVA字符集和字符串的编码
2006-10-20 19:17 4333先提出问题： 都知道，windows XP 的默认编码方式 ... -
java增补字符
2006-10-20 19:16 1435摘要 本文介绍 Java 平台支持增补字符的方式。增补字符是 ... -
Linux下GB2313与UTF8的相互转换
2006-10-20 19:16 2363int code_convert(char *from_cha ... -
Unicode 问答集
2006-10-20 19:15 1053问：什么是Unicode？ 答 ... -
谈谈Unicode编码，简要解释UCS、UTF、BMP、BOM等名词
2006-10-20 19:14 1053这是一篇程序员写给程 ... -
关于utf-8,unicode字符集
2006-10-20 19:12 2116utf-8是unicode的一个新的编码标准,其实unicod ... -
java编码中的一些经验和教训
2006-10-20 19:11 844这几天集中时间重拾388备份文件格式研究，使用的工具主要是ne ...
相关推荐
Java学习笔记 1、连接数据库步骤 2、不同数据库的驱动程序和连接字符串 3、连接数据库常见问题 4、B/S结构和C/S结构的区别 5、如何处理中文乱码问题 6、使用JavaMail发送注册验证邮件 7、不安全的用户名密码验证 8、...
MySQL入Ar ]很简单学习笔记李国华.dox Oracle查看表结构.txt SQL作业代理禁用.txt sql.txt SQL-Transaction事物一起执行.txt sq和oracle的区别.txt sysobjects中type字段值意思txt W3School例句.txt 按照中文首字母...
{1}Java基础}{17}{chapter.1} {1.1}基本语法}{17}{section.1.1} {1.2}数字表达方式}{17}{section.1.2} {1.3}补码}{19}{section.1.3} {1.3.1}总结}{23}{subsection.1.3.1} {1.4}数据类型}{23}{section.1.4} {...
c#学习笔记(1) 51099在线学习网发布 文章来源：网络收集 发布时间：2006-05-25 字体： [大 中 小] 51099在线学习网 http://www.51099.com 1, 结构(struct) 与 类(class) [attributes] [modifiers] struct ...
十、 Action属性接收参数中文问题 12 十一、 简单数据验证 12 十二、 访问Web元素 14 一、 方法一：ActionContext方式 15 二、 方式二：Ioc(控制反转)—推荐使用 15 三、 方式三：获取原类型 16 四、 方式四：获取原...
[目录]Java学习笔记(推荐) 6. [目录]JDBC文档 7. [目录]RMI 文档 2. [目录]Java资源(文档－书籍－下载－注册码) 1. [目录]License 和注册码 2. [目录]好书推荐 3. [目录]关于Java的...
学习建议：算法和数据结构的内容，用最简单的C语言描述会比较清楚，没有必要使用C++和Java的面向对象描述。面向对象编程在这里没啥用处，反而冲淡了学习主题。初学者，先学习Weiss的《数据结构与算法分析 C语言描述...
Guava学习笔记笔记的大部分中文翻译内容来源于以下译者: 沉义扬，罗立树，何一昕，武祖校对：方腾飞感谢给我们带来的这一系列好文章。引言Guava工程包含了若干被Google的Java项目广泛依赖的核心库，例如：集合...
笔记: chinese-ocr项目 | 《深度卷积网络：原理与实践》读书笔记 | 手写汉字识别调研 经典分类网络： LeNet-5 | AlexNet | VGGNet | GoogleNet | ResNet | DenseNet | Xception | EfficientNet 经典检测网络： SSD...
java版飞机大战源码 open-src 开源项目资料整理 Machine Learning[机器学习] ...吴恩达《深度学习》学习笔记(xmind)、代码、代码视频讲解 深度学习500问，以问答形式对常用的概率知识、线性代数、机器学习、深
word源码java MyStar 整理一下我的收藏 (2019-05-26,截止到RefineDet-tensorflow) Learning AiLearning: 机器学习 - MachineLearning - ML、深度学习 - DeepLearning - DL、自然语言处理 NLP Paper Lists for Graph ...
系统设计 1 jive设计思路 2 jive的工作内幕 3 Jive源代码研究 4 Jive中的设计模式 5 jive学习笔记 <br> 设计模式 1 大道至简-Java之23种模式一点就通 2 设计模式...
中文的库是PTM或semi类型的，在java版sphinx中无法使用。 2、Sphinx的训练指哪些内容？ 在Sphinx中有语言模型、声学模型等概念，如果你不想了解这些，请参考以下内容： a1、中文每个字的标准发音已经有一个较为...
java版商城源码下载 2018年12月3日 Git笔记 Git是一款免费、开源的分布式版本控制系统 特点Git是一个开源的分布式版本控制系统，可以有效，高速的处理从很小到非常 大的项目版本管理 配置Git在根目录 1.配置用户名...
系统设计 1 jive设计思路 2 jive的工作内幕 3 Jive源代码研究 4 Jive中的设计模式 5 jive学习笔记 <br> <br> 数据库设计 1 Jive Forums数据库说明(英文) 2 Jive KB...
算法/NLP/深度学习/机器学习面试笔记 GitHub 地址： 算法/深度学习/机器学习面试问题整理，想法最初来源于这个. 此外，还包括我看到的所有机器学习/深度学习面经中的问题。 除了其中 DL/ML 相关的，其他与算法岗相关...
需要说明的是，定长编码便于计算机处理（注意GB2312/GBK不是定长编码），而unicode又可以用来表示所有字符，所以在很多软件内部是使用unicode编码来处理的，比如java。 Unicode当然是一个很大的集合，现在的规模...
VS2005 ASP.NET本地化学习笔记&感受 在自定义Server Control中捆绑JS文件 Step by Step 深度解析Asp.Net2.0中的Callback机制 使用 Web 标准生成 ASP.NET 2.0 Web 站点 ASP.NET 2.0基于SQLSERVER 2005的aspnetdb.mdf...
深度学习教程笔记和代码。 7 了解数据结构和算法。 8 每个pythoner都应该知道的（主要是）技术知识的集合。 9 一个在线微信降价编辑器。 10 框架和组件的源代码分析。 如何加入 如果你想走得快，就一个人去。 想走远...