至顶网›软件频道 ›Java中文处理, 资源包后缀详解

Java中文处理, 资源包后缀详解

扫一扫
分享文章到微信
扫一扫
关注官方公众号
至顶头条

很多国际化应用的让我理解了这么一个道理：Unicode是为更方便的做国际化应用设计的，而Java核心的字符是基于UNICODE的，这一机制为应用提供了对中文“字”的控制（而不是字节）。

作者：feng_sundy 来源：CSDN 2008年3月14日

不知道你有没有这样的感受：为什么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 English en_US English (United States) ar Arabic ar_AE Arabic (United Arab Emirates) ar_BH Arabic (Bahrain) ar_DZ Arabic (Algeria) ar_EG Arabic (Egypt) ar_IQ Arabic (Iraq) ar_JO Arabic (Jordan) ar_KW Arabic (Kuwait) ar_LB Arabic (Lebanon) ar_LY Arabic (Libya) ar_MA Arabic (Morocco) ar_OM Arabic (Oman) ar_QA Arabic (Qatar) ar_SA Arabic (Saudi Arabia) ar_SD Arabic (Sudan) ar_SY Arabic (Syria) ar_TN Arabic (Tunisia) ar_YE Arabic (Yemen) be Byelorussian be_BY Byelorussian (Belarus) bg Bulgarian bg_BG Bulgarian (Bulgaria) ca Catalan ca_ES Catalan (Spain) ca_ES_EURO Catalan (Spain,Euro) cs Czech cs_CZ Czech (Czech Republic) da Danish da_DK Danish (Denmark) de German de_AT German (Austria) de_AT_EURO German (Austria,Euro) de_CH German (Switzerland) de_DE German (Germany) de_DE_EURO German (Germany,Euro) de_LU German (Luxembourg) de_LU_EURO German (Luxembourg,Euro) el Greek el_GR Greek (Greece) en_AU English (Australia) en_CA English (Canada) en_GB English (United Kingdom) en_IE English (Ireland) en_IE_EURO English (Ireland,Euro) en_NZ English (New Zealand) en_ZA English (South Africa) es Spanish es_BO Spanish (Bolivia) es_AR Spanish (Argentina) es_CL Spanish (Chile) es_CO Spanish (Colombia) es_CR Spanish (Costa Rica) es_DO Spanish (Dominican Republic) es_EC Spanish (Ecuador) es_ES Spanish (Spain) es_ES_EURO Spanish (Spain,Euro) es_GT Spanish (Guatemala) es_HN Spanish (Honduras) es_MX Spanish (Mexico) es_NI Spanish (Nicaragua) et Estonian es_PA Spanish (Panama) es_PE Spanish (Peru) es_PR Spanish (Puerto Rico) es_PY Spanish (Paraguay) es_SV Spanish (El Salvador) es_UY Spanish (Uruguay) es_VE Spanish (Venezuela) et_EE Estonian (Estonia) fi Finnish fi_FI Finnish (Finland) fi_FI_EURO Finnish (Finland,Euro) fr French fr_BE French (Belgium) fr_BE_EURO French (Belgium,Euro) fr_CA French (Canada) fr_CH French (Switzerland) fr_FR French (France) fr_FR_EURO French (France,Euro) fr_LU French (Luxembourg) fr_LU_EURO French (Luxembourg,Euro) hr Croatian hr_HR Croatian (Croatia) hu Hungarian hu_HU Hungarian (Hungary) is Icelandic is_IS Icelandic (Iceland) it Italian it_CH Italian (Switzerland) it_IT Italian (Italy) it_IT_EURO Italian (Italy,Euro) iw Hebrew iw_IL Hebrew (Israel) ja Japanese ja_JP Japanese (Japan) ko Korean ko_KR Korean (South Korea) lt Lithuanian lt_LT Lithuanian (Lithuania) lv Latvian (Lettish) lv_LV Latvian (Lettish) (Latvia) mk Macedonian mk_MK Macedonian (Macedonia) nl Dutch nl_BE Dutch (Belgium) nl_BE_EURO Dutch (Belgium,Euro) nl_NL Dutch (Netherlands) nl_NL_EURO Dutch (Netherlands,Euro) no Norwegian no_NO Norwegian (Norway) no_NO_NY Norwegian (Norway,Nynorsk) pl Polish pl_PL Polish (Poland) pt Portuguese pt_BR Portuguese (Brazil) pt_PT Portuguese (Portugal) pt_PT_EURO Portuguese (Portugal,Euro) ro Romanian ro_RO Romanian (Romania) ru Russian ru_RU Russian (Russia) sh Serbo-Croatian sh_YU Serbo-Croatian (Yugoslavia) sk Slovak sk_SK Slovak (Slovakia) sl Slovenian sl_SI Slovenian (Slovenia) sq Albanian sq_AL Albanian (Albania) sr Serbian sr_YU Serbian (Yugoslavia) sv Swedish sv_SE Swedish (Sweden) th Thai th_TH Thai (Thailand) tr Turkish tr_TR Turkish (Turkey) uk Ukrainian uk_UA Ukrainian (Ukraine) zh Chinese zh_CN Chinese (China) zh_HK Chinese (Hong Kong) zh_TW Chinese (Taiwan) ======System property======== -- listing properties -- java.runtime.name=Java(TM) 2 Runtime Environment, Stand... sun.boot.library.path=/usr/java/jdk1.3.1_04/jre/lib/i386 java.vm.version=1.3.1_04-b02 java.vm.vendor=Sun Microsystems Inc. java.vendor.url=http://java.sun.com/ path.separator=: java.vm.name=Java HotSpot(TM) Client VM file.encoding.pkg=sun.io java.vm.specification.name=Java Virtual Machine Specification user.dir=/home/chedong/src/char_test java.runtime.version=1.3.1_04-b02 java.awt.graphicsenv=sun.awt.X11GraphicsEnvironment os.arch=i386 java.io.tmpdir=/tmp line.separator= java.vm.specification.vendor=Sun Microsystems Inc. java.awt.fonts= os.name=Linux java.library.path=/usr/java/jdk1.3.1_04/jre/lib/i386:/u... java.specification.name=Java Platform API Specification java.class.version=47.0 os.version=2.4.7-10 user.home=/home/chedong user.timezone=Asia/Shanghai java.awt.printerjob=sun.awt.motif.PSPrinterJob file.encoding=ISO-8859-1 java.specification.version=1.3user.name=chedong java.class.path=/home/chedong/classesjava.vm.specification.version=1.0 java.home=/usr/java/jdk1.3.1_04/jreuser.language=en java.specification.vendor=Sun Microsystems Inc.java.vm.info=mixed mode java.version=1.3.1_04java.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=littlesun.io.unicode.encoding=UnicodeLittle user.region=USsun.cpu.isalist=	Hello, it's: Tue Jul 30 11:07:34 CST 2002 ======System available locales:======== en 英文 en_US 英文 (美国) ar 阿拉伯文 ar_AE 阿拉伯文 (阿拉伯联合酋长国) ar_BH 阿拉伯文 (巴林) ar_DZ 阿拉伯文 (阿尔及利亚) ar_EG 阿拉伯文 (埃及) ar_IQ 阿拉伯文 (伊拉克) ar_JO 阿拉伯文 (约旦) ar_KW 阿拉伯文 (科威特) ar_LB 阿拉伯文 (黎巴嫩) ar_LY 阿拉伯文 (利比亚) ar_MA 阿拉伯文 (摩洛哥) ar_OM 阿拉伯文 (阿曼) ar_QA 阿拉伯文 (卡塔尔) ar_SA 阿拉伯文 (沙特阿拉伯) ar_SD 阿拉伯文 (苏丹) ar_SY 阿拉伯文 (叙利亚) ar_TN 阿拉伯文 (突尼斯) ar_YE 阿拉伯文 (也门) be 白俄罗斯文 be_BY 白俄罗斯文 (白俄罗斯) bg 保加利亚文 bg_BG 保加利亚文 (保加利亚) ca 加泰罗尼亚文 ca_ES 加泰罗尼亚文 (西班牙) ca_ES_EURO 加泰罗尼亚文 (西班牙,Euro) cs 捷克文 cs_CZ 捷克文 (捷克共和国) da 丹麦文 da_DK 丹麦文 (丹麦) de 德文 de_AT 德文 (奥地利) de_AT_EURO 德文 (奥地利,Euro) de_CH 德文 (瑞士) de_DE 德文 (德国) de_DE_EURO 德文 (德国,Euro) de_LU 德文 (卢森堡) de_LU_EURO 德文 (卢森堡,Euro) el 希腊文 el_GR 希腊文 (希腊) en_AU 英文 (澳大利亚) en_CA 英文 (加拿大) en_GB 英文 (英国) en_IE 英文 (爱尔兰) en_IE_EURO 英文 (爱尔兰,Euro) en_NZ 英文 (新西兰) en_ZA 英文 (南非) es 西班牙文 es_BO 西班牙文 (玻利维亚) es_AR 西班牙文 (阿根廷) es_CL 西班牙文 (智利) es_CO 西班牙文 (哥伦比亚) es_CR 西班牙文 (哥斯达黎加) es_DO 西班牙文 (多米尼加共和国) es_EC 西班牙文 (厄瓜多尔) es_ES 西班牙文 (西班牙) es_ES_EURO 西班牙文 (西班牙,Euro) es_GT 西班牙文 (危地马拉) es_HN 西班牙文 (洪都拉斯) es_MX 西班牙文 (墨西哥) es_NI 西班牙文 (尼加拉瓜) et 爱沙尼亚文 es_PA 西班牙文 (巴拿马) es_PE 西班牙文 (秘鲁) es_PR 西班牙文 (波多黎哥) es_PY 西班牙文 (巴拉圭) es_SV 西班牙文 (萨尔瓦多) es_UY 西班牙文 (乌拉圭) es_VE 西班牙文 (委内瑞拉) et_EE 爱沙尼亚文 (爱沙尼亚) fi 芬兰文 fi_FI 芬兰文 (芬兰) fi_FI_EURO 芬兰文 (芬兰,Euro) fr 法文 fr_BE 法文 (比利时) fr_BE_EURO 法文 (比利时,Euro) fr_CA 法文 (加拿大) fr_CH 法文 (瑞士) fr_FR 法文 (法国) fr_FR_EURO 法文 (法国,Euro) fr_LU 法文 (卢森堡) fr_LU_EURO 法文 (卢森堡,Euro) hr 克罗地亚文 hr_HR 克罗地亚文 (克罗地亚) hu 匈牙利文 hu_HU 匈牙利文 (匈牙利) is 冰岛文 is_IS 冰岛文 (冰岛) it 意大利文 it_CH 意大利文 (瑞士) it_IT 意大利文 (意大利) it_IT_EURO 意大利文 (意大利,Euro) iw 希伯来文 iw_IL 希伯来文 (以色列) ja 日文 ja_JP 日文 (日本) ko 朝鲜文 ko_KR 朝鲜文 (南朝鲜) lt 立陶宛文 lt_LT 立陶宛文 (立陶宛) lv 拉托维亚文(列托) lv_LV 拉托维亚文(列托) (拉脱维亚) mk 马其顿文 mk_MK 马其顿文 (马其顿王国) nl 荷兰文 nl_BE 荷兰文 (比利时) nl_BE_EURO 荷兰文 (比利时,Euro) nl_NL 荷兰文 (荷兰) nl_NL_EURO 荷兰文 (荷兰,Euro) no 挪威文 no_NO 挪威文 (挪威) no_NO_NY 挪威文 (挪威,Nynorsk) pl 波兰文 pl_PL 波兰文 (波兰) pt 葡萄牙文 pt_BR 葡萄牙文 (巴西) pt_PT 葡萄牙文 (葡萄牙) pt_PT_EURO 葡萄牙文 (葡萄牙,Euro) ro 罗马尼亚文 ro_RO 罗马尼亚文 (罗马尼亚) ru 俄文 ru_RU 俄文 (俄罗斯) sh 塞波尼斯-克罗地亚文 sh_YU 塞波尼斯-克罗地亚文 (南斯拉夫) sk 斯洛伐克文 sk_SK 斯洛伐克文 (斯洛伐克) sl 斯洛文尼亚文 sl_SI 斯洛文尼亚文 (斯洛文尼亚) sq 阿尔巴尼亚文 sq_AL 阿尔巴尼亚文 (阿尔巴尼亚) sr 塞尔维亚文 sr_YU 塞尔维亚文 (南斯拉夫) sv 瑞典文 sv_SE 瑞典文 (瑞典) th 泰文 th_TH 泰文 (泰国) tr 土耳其文 tr_TR 土耳其文 (土耳其) uk 乌克兰文 uk_UA 乌克兰文 (乌克兰) zh 中文 zh_CN 中文 (中国) zh_HK 中文 (香港) zh_TW 中文 (台湾) ======System property======== -- listing properties -- java.runtime.name=Java(TM) 2 Runtime Environment, Stand... sun.boot.library.path=/usr/java/jdk1.3.1_04/jre/lib/i386 java.vm.version=1.3.1_04-b02 java.vm.vendor=Sun Microsystems Inc. java.vendor.url=http://java.sun.com/ path.separator=: java.vm.name=Java HotSpot(TM) Client VM file.encoding.pkg=sun.io java.vm.specification.name=Java Virtual Machine Specification user.dir=/home/chedong/src/char_test java.runtime.version=1.3.1_04-b02 java.awt.graphicsenv=sun.awt.X11GraphicsEnvironment os.arch=i386 java.io.tmpdir=/tmp line.separator= java.vm.specification.vendor=Sun Microsystems Inc. java.awt.fonts= os.name=Linux java.library.path=/usr/java/jdk1.3.1_04/jre/lib/i386:/u... java.specification.name=Java Platform API Specification java.class.version=47.0 os.version=2.4.7-10 user.home=/home/chedong user.timezone=Asia/Shanghai java.awt.printerjob=sun.awt.motif.PSPrinterJob file.encoding=GBK java.specification.version=1.3user.name=chedong java.class.path=/home/chedong/classesjava.vm.specification.version=1.0 java.home=/usr/java/jdk1.3.1_04/jreuser.language=zh java.specification.vendor=Sun Microsystems Inc.java.vm.info=mixed mode java.version=1.3.1_04java.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=littlesun.io.unicode.encoding=UnicodeLittle user.region=CNsun.cpu.isalist=	Hello, it's: Tue Jul 30 11:49:36 CST 2002 ======System available locales:======== en English en_US English (United States) ar Arabic ar_AE Arabic (United Arab Emirates) ar_BH Arabic (Bahrain) ar_DZ Arabic (Algeria) ar_EG Arabic (Egypt) ar_IQ Arabic (Iraq) ar_JO Arabic (Jordan) ar_KW Arabic (Kuwait) ar_LB Arabic (Lebanon) ar_LY Arabic (Libya) ar_MA Arabic (Morocco) ar_OM Arabic (Oman) ar_QA Arabic (Qatar) ar_SA Arabic (Saudi Arabia) ar_SD Arabic (Sudan) ar_SY Arabic (Syria) ar_TN Arabic (Tunisia) ar_YE Arabic (Yemen) be Byelorussian be_BY Byelorussian (Belarus) bg Bulgarian bg_BG Bulgarian (Bulgaria) ca Catalan ca_ES Catalan (Spain) ca_ES_EURO Catalan (Spain,Euro) cs Czech cs_CZ Czech (Czech Republic) da Danish da_DK Danish (Denmark) de German de_AT German (Austria) de_AT_EURO German (Austria,Euro) de_CH German (Switzerland) de_DE German (Germany) de_DE_EURO German (Germany,Euro) de_LU German (Luxembourg) de_LU_EURO German (Luxembourg,Euro) el Greek el_GR Greek (Greece) en_AU English (Australia) en_CA English (Canada) en_GB English (United Kingdom) en_IE English (Ireland) en_IE_EURO English (Ireland,Euro) en_NZ English (New Zealand) en_ZA English (South Africa) es Spanish es_AR Spanish (Argentina) es_BO Spanish (Bolivia) es_CL Spanish (Chile) es_CO Spanish (Colombia) es_CR Spanish (Costa Rica) es_DO Spanish (Dominican Republic) es_EC Spanish (Ecuador) es_ES Spanish (Spain) es_ES_EURO Spanish (Spain,Euro) es_GT Spanish (Guatemala) es_HN Spanish (Honduras) es_MX Spanish (Mexico) es_NI Spanish (Nicaragua) es_PA Spanish (Panama) es_PE Spanish (Peru) es_PR Spanish (Puerto Rico) es_PY Spanish (Paraguay) es_SV Spanish (El Salvador) es_UY Spanish (Uruguay) es_VE Spanish (Venezuela) et Estonian et_EE Estonian (Estonia) fi Finnish fi_FI Finnish (Finland) fi_FI_EURO Finnish (Finland,Euro) fr French fr_BE French (Belgium) fr_BE_EURO French (Belgium,Euro) fr_CA French (Canada) fr_CH French (Switzerland) fr_FR French (France) fr_FR_EURO French (France,Euro) fr_LU French (Luxembourg) fr_LU_EURO French (Luxembourg,Euro) hr Croatian hr_HR Croatian (Croatia) hu Hungarian hu_HU Hungarian (Hungary) is Icelandic is_IS Icelandic (Iceland) it Italian it_CH Italian (Switzerland) it_IT Italian (Italy) it_IT_EURO Italian (Italy,Euro) iw Hebrew iw_IL Hebrew (Israel) ja Japanese ja_JP Japanese (Japan) ko 韩文 ko_KR 韩文 (大韩民国) lt Lithuanian lt_LT Lithuanian (Lithuania) lv Latvian (Lettish) lv_LV Latvian (Lettish) (Latvia) mk Macedonian mk_MK Macedonian (Macedonia) nl Dutch nl_BE Dutch (Belgium) nl_BE_EURO Dutch (Belgium,Euro) nl_NL Dutch (Netherlands) nl_NL_EURO Dutch (Netherlands,Euro) no Norwegian no_NO Norwegian (Norway) no_NO_NY Norwegian (Norway,Nynorsk) pl Polish pl_PL Polish (Poland) pt Portuguese pt_BR Portuguese (Brazil) pt_PT Portuguese (Portugal) pt_PT_EURO Portuguese (Portugal,Euro) ro Romanian ro_RO Romanian (Romania) ru Russian ru_RU Russian (Russia) sh Serbo-Croatian sh_YU Serbo-Croatian (Yugoslavia) sk Slovak sk_SK Slovak (Slovakia) sl Slovenian sl_SI Slovenian (Slovenia) sq Albanian sq_AL Albanian (Albania) sr Serbian sr_YU Serbian (Yugoslavia) sv Swedish sv_SE Swedish (Sweden) th Thai th_TH Thai (Thailand) tr Turkish tr_TR Turkish (Turkey) uk Ukrainian uk_UA Ukrainian (Ukraine) zh 中文 zh_CN 中文 (中华人民共和国) zh_HK 中文 (香港) zh_TW 中文 (台湾) ======System property======== -- listing properties -- java.runtime.name=Java(TM) 2 Runtime Environment, Stand... sun.boot.library.path=C:\PROGRAM FILES\JavaSOFT\JRE\1.3.0_0... java.vm.version=1.3.0_02 java.vm.vendor=Sun Microsystems Inc. java.vendor.url=http://java.sun.com/ path.separator=; java.vm.name=Java HotSpot(TM) Client VM file.encoding.pkg=sun.io java.vm.specification.name=Java Virtual Machine Specification user.dir=D:\java\src\char_test java.runtime.version=1.3.0_02 java.awt.graphicsenv=sun.awt.Win32GraphicsEnvironment os.arch=x86 java.io.tmpdir=D:\TEMP\ line.separator= java.vm.specification.vendor=Sun Microsystems Inc. java.awt.fonts= os.name=Windows 98 java.library.path=C:\WINDOWS;.;C:\WINDOWS\SYSTEM;C:\WIN... java.specification.name=Java Platform API Specification java.class.version=47.0 os.version=4.90 user.home=C:\WINDOWS user.timezone=Asia/Shanghai java.awt.printerjob=sun.awt.windows.WPrinterJob file.encoding=GBK java.specification.version=1.3user.name=Siccijava.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.WToolkitjava.vm.info=mixed modejava.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=littlesun.io.unicode.encoding=UnicodeLittle user.region=CNsun.cpu.isalist=pentium i486 i386	Hello, it's: Tue Jul 30 11:53:27 CST 2002 ======System available locales:======== en English en_US English (United States) ar Arabic ar_AE Arabic (United Arab Emirates) ar_BH Arabic (Bahrain) ar_DZ Arabic (Algeria) ar_EG Arabic (Egypt) ar_IQ Arabic (Iraq) ar_JO Arabic (Jordan) ar_KW Arabic (Kuwait) ar_LB Arabic (Lebanon) ar_LY Arabic (Libya) ar_MA Arabic (Morocco) ar_OM Arabic (Oman) ar_QA Arabic (Qatar) ar_SA Arabic (Saudi Arabia) ar_SD Arabic (Sudan) ar_SY Arabic (Syria) ar_TN Arabic (Tunisia) ar_YE Arabic (Yemen) be Byelorussian be_BY Byelorussian (Belarus) bg Bulgarian bg_BG Bulgarian (Bulgaria) ca Catalan ca_ES Catalan (Spain) ca_ES_EURO Catalan (Spain,Euro) cs Czech cs_CZ Czech (Czech Republic) da Danish da_DK Danish (Denmark) de German de_AT German (Austria) de_AT_EURO German (Austria,Euro) de_CH German (Switzerland) de_DE German (Germany) de_DE_EURO German (Germany,Euro) de_LU German (Luxembourg) de_LU_EURO German (Luxembourg,Euro) el Greek el_GR Greek (Greece) en_AU English (Australia) en_CA English (Canada) en_GB English (United Kingdom) en_IE English (Ireland) en_IE_EURO English (Ireland,Euro) en_NZ English (New Zealand) en_ZA English (South Africa) es Spanish es_AR Spanish (Argentina) es_BO Spanish (Bolivia) es_CL Spanish (Chile) es_CO Spanish (Colombia) es_CR Spanish (Costa Rica) es_DO Spanish (Dominican Republic) es_EC Spanish (Ecuador) es_ES Spanish (Spain) es_ES_EURO Spanish (Spain,Euro) es_GT Spanish (Guatemala) es_HN Spanish (Honduras) es_MX Spanish (Mexico) es_NI Spanish (Nicaragua) es_PA Spanish (Panama) es_PE Spanish (Peru) es_PR Spanish (Puerto Rico) es_PY Spanish (Paraguay) es_SV Spanish (El Salvador) es_UY Spanish (Uruguay) es_VE Spanish (Venezuela) et Estonian et_EE Estonian (Estonia) fi Finnish fi_FI Finnish (Finland) fi_FI_EURO Finnish (Finland,Euro) fr French fr_BE French (Belgium) fr_BE_EURO French (Belgium,Euro) fr_CA French (Canada) fr_CH French (Switzerland) fr_FR French (France) fr_FR_EURO French (France,Euro) fr_LU French (Luxembourg) fr_LU_EURO French (Luxembourg,Euro) hr Croatian hr_HR Croatian (Croatia) hu Hungarian hu_HU Hungarian (Hungary) is Icelandic is_IS Icelandic (Iceland) it Italian it_CH Italian (Switzerland) it_IT Italian (Italy) it_IT_EURO Italian (Italy,Euro) iw Hebrew iw_IL Hebrew (Israel) ja Japanese ja_JP Japanese (Japan) ko Korean ko_KR Korean (South Korea) lt Lithuanian lt_LT Lithuanian (Lithuania) lv Latvian (Lettish) lv_LV Latvian (Lettish) (Latvia) mk Macedonian mk_MK Macedonian (Macedonia) nl Dutch nl_BE Dutch (Belgium) nl_BE_EURO Dutch (Belgium,Euro) nl_NL Dutch (Netherlands) nl_NL_EURO Dutch (Netherlands,Euro) no Norwegian no_NO Norwegian (Norway) no_NO_NY Norwegian (Norway,Nynorsk) pl Polish pl_PL Polish (Poland) pt Portuguese pt_BR Portuguese (Brazil) pt_PT Portuguese (Portugal) pt_PT_EURO Portuguese (Portugal,Euro) ro Romanian ro_RO Romanian (Romania) ru Russian ru_RU Russian (Russia) sh Serbo-Croatian sh_YU Serbo-Croatian (Yugoslavia) sk Slovak sk_SK Slovak (Slovakia) sl Slovenian sl_SI Slovenian (Slovenia) sq Albanian sq_AL Albanian (Albania) sr Serbian sr_YU Serbian (Yugoslavia) sv Swedish sv_SE Swedish (Sweden) th Thai th_TH Thai (Thailand) tr Turkish tr_TR Turkish (Turkey) uk Ukrainian uk_UA Ukrainian (Ukraine) zh Chinese zh_CN Chinese (China) zh_HK Chinese (Hong Kong) zh_TW Chinese (Taiwan) ======System property======== -- listing properties -- java.runtime.name=Java(TM) 2 Runtime Environment, Stand... sun.boot.library.path=C:\PROGRAM FILES\JavaSOFT\JRE\1.3.0_0... java.vm.version=1.3.0_02 java.vm.vendor=Sun Microsystems Inc. java.vendor.url=http://java.sun.com/ path.separator=; java.vm.name=Java HotSpot(TM) Client VM file.encoding.pkg=sun.io java.vm.specification.name=Java Virtual Machine Specification user.dir=D:\java\src\char_test java.runtime.version=1.3.0_02 java.awt.graphicsenv=sun.awt.Win32GraphicsEnvironment os.arch=x86 java.io.tmpdir=D:\TEMP\ line.separator= java.vm.specification.vendor=Sun Microsystems Inc. java.awt.fonts= os.name=Windows 98 java.library.path=C:\WINDOWS;.;C:\WINDOWS\SYSTEM;C:\WIN... java.specification.name=Java Platform API Specification java.class.version=47.0 os.version=4.90 user.home=C:\WINDOWS user.timezone=Asia/Shanghai java.awt.printerjob=sun.awt.windows.WPrinterJob file.encoding=Cp1252 java.specification.version=1.3user.name=Siccijava.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.WToolkitjava.vm.info=mixed modejava.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=littlesun.io.unicode.encoding=UnicodeLittle user.region=GBsun.cpu.isalist=pentium i486 i386

结论1：

JVM的缺省编码方式由系统的“本地语言环境”设置确定，和操作系统的类型无关。所以当设置成相同的LOCALE时，Linux和Windows下的缺省编码方式是没有区别的（可以认为cp1252=ISO-8859-1都是一样的西文编码方式，只包含255以下的拉丁字符），因此后面的测试2我只列出了GNU/Linux下LOCALE分别设置成zh_CN和en_US的测试结果输出。以下测试如果在Windows下分别按照不同的区域和字符集设置后试验的输出是一样的。

试验2：Java的输入输出过程中的字节流到字符流的转换过程

通过这个HelloUnicode.java程序，演示说明"Hello world 世界你好"这个字符串（16个字符）在不同缺省系统编码方式下的处理效果。在编码/解码的每个步骤之后，都打印出了相应字符串每个字符(Charactor)的byte值，short值和所在的UNICODE区间。

LANG=en_US LC_ALL=en_US

LANG=zh_CN LC_ALL=zh_CN.GBK

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

第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 UTF8string=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=GBK
string=Hello world 世界你好 length=16
char[0]='H' byte=72 \u48 short=72 \u48 BASIC_LATIN
char[1]='e' byte=101 \u65 short=101 \u65 BASIC_LATIN
char[2]='l' byte=108 \u6C short=108 \u6C BASIC_LATIN
char[3]='l' byte=108 \u6C short=108 \u6C BASIC_LATIN
char[4]='o' byte=111 \u6F short=111 \u6F BASIC_LATIN
char[5]=' ' byte=32 \u20 short=32 \u20 BASIC_LATIN
char[6]='w' byte=119 \u77 short=119 \u77 BASIC_LATIN
char[7]='o' byte=111 \u6F short=111 \u6F BASIC_LATIN
char[8]='r' byte=114 \u72 short=114 \u72 BASIC_LATIN
char[9]='l' byte=108 \u6C short=108 \u6C BASIC_LATIN
char[10]='d' byte=100 \u64 short=100 \u64 BASIC_LATIN
char[11]=' ' byte=32 \u20 short=32 \u20 BASIC_LATIN
char[12]='世' byte=22 \u16 short=19990 \u4E16 CJK_UNIFIED_IDEOGRAPHS
char[13]='界' byte=76 \u4C short=30028 \u754C CJK_UNIFIED_IDEOGRAPHS
char[14]='你' byte=96 \u60 short=20320 \u4F60 CJK_UNIFIED_IDEOGRAPHS
char[15]='好' byte=125 \u7D short=22909 \u597D CJK_UNIFIED_IDEOGRAPHS

注意：在新的语言环境中做以上测试需要将源程序重新编译，
最早的字节流到字符流的解码过程从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 UTF8string=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=4
ServletRequest's Charset Encoding = GBK
ServletResponse's Charset Encoding = GBK
char[0]='世' byte=22 \u16 short=19990 \u4E16 CJK_UNIFIED_IDEOGRAPHS
char[1]='界' byte=76 \u4C short=30028 \u754C CJK_UNIFIED_IDEOGRAPHS
char[2]='你' byte=96 \u60 short=20320 \u4F60 CJK_UNIFIED_IDEOGRAPHS
char[3]='好' byte=125 \u7D short=22909 \u597D CJK_UNIFIED_IDEOGRAPHS

再做一个试验：把程序开头部分的浏览器自动检测功能注释掉，再次的输出结果就是和目前很多应用一样其实是按ISO-8859-1方式解码/编码的“字节应用”了：

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

虽然这样的输出结果如果在浏览器中设置用中文字符集也能正确显示，但实际上处理的已经是“字节”而不是处理中文“字符”了。ServletRequest 和 ServletResponse 缺省使用ISO-8859-1字符集解码/编码的具体定义请参考：

以前能够配置让一个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 JD

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

Java中文处理, 资源包后缀详解

Java中文处理, 资源包后缀详解

VIP专区

VIP用户

普通用户

邮件订阅

如果您非常迫切的想了解IT领域最新产品与技术信息，那么订阅至顶网技术邮件将是您的最佳途径之一。

重磅专题

往期文章

Java中文处理, 资源包后缀详解

业界热点: