要害词：linux java mutlibyte encoding locale i18n i10n
摘要：通过2个测试程序说明系统缺省编码方式和应用的编码策略对字符处理的影响，选择合适的编码处理策略，构建更符合国际化规范的通用应用。
测试程序-1
为了了解JAVA应用的编码处理的机制，首先要了解操作系统对JVM缺省编码方式的影响，因此我做了一个Env.java，用于打印显示不同系统下JVM的属性和系统支持的LOCALE。程序很简单：
/*
* Copyright (c) 2002 chedong@bigfoot.com
* $Id: Env.java,v 1.1 2002/07/30 09:48:12 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
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可以通过控制面板==区域设置 设置实现
列表1
结论：
JVM的缺省编码方式由系统的LOCALE设置确定，所以当设置成相同的LOCALE时，Linux和Windows下的缺省编码方式是没有区别的（可以认为cp1252=ISO-8859-1都是一样的西文编码方式，只包含255以下的拉丁字符），因此测试2我只列出了LINUX下LOCALE分别设置成zh_CN和en_US测试结果输出和在WINDOWS下分别按照不同的区域设置试验的输出结果是一样的。
测试程序-2
通过一个HelloUnicode.java程序，演示说明"Hello world 世界你好"这个字符串（16个字符）在不同缺省系统编码方式下的处理效果。在编码解码的每个步骤之后，都打印出了相应字符串每个字符(charactor)的byte值，short值和所在的UNICODE区间。
列表2
试验2的一些结论：
所有的应用都是按照字节流=字符流=字节流方式进行的处理的：
byte_stream ==(input decoding)== char_stream ==output(encoding)== byte_stream
在JAVA字节流到字符流（或者反之）都是含有隐含的解码处理的（缺省是按照系统缺省编码方式）；
最早的字节流解码过程从javac的代码编译就开始了，
JAVA中间的字符character存储单位是双字节的UNICODE，
结论：
从以上2个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字符集做集中存储，根据以上结论，设计一个适应多语言环境的应用，可以考虑一下处理模式：（客户端应用或本地化应用）根据LOCALE，让JAVA应用按照系统LOCALE的缺省的字符集设置进行处理
参考文档：
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/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
相关连接请点 这里
