jboss 中文

JAVA_OPTS="$JAVA_OPTS -Dfile.encoding=GB18030 -Xrunjdwp:transport=dt_socket,address=8787,server=y,suspend=n"

关于字符集的准备知识：
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则是一个更复杂的字符集，采用变长字节的编码方式，能够支持 更多的字符。关于汉字的编码方式比较详细的定义规范可以参考：

ASCII（英文） ==> 西欧文字 ==> 东欧字符集（俄文，希腊语等） ==> 东亚字符集（GB2312 BIG5 SJIS等）==> 扩展字符集GBK GB18030这个发展过程基本上也反映了字符集标准的发展过程，但这么随着时间的推移，尤其是互联网让跨语言的信息的交互变得越来越多的时候，太多多针 对本地语言的编码标准的出现导致一个应用程序的国际化变得成本非常高。尤其是你要编写一个同时包含法文和简体中文的文档，这时候一般都会想到要是用一个通 用的字符集能够显示所有语言的所有文字就好了，而且这样做应用也能够比较方便的国际化，为了达到这个目标，即使应用牺牲一些空间和程序效率也是非常值得 的。UNICODE就是这样一个通用的解决方案。
UNICODE双字节字符集
所以你可以把UNICODE想象成这样：让所有的字符（包括英文）都用2个字节（2个8位）表示，这样就有了一个2^(8*2) = 256 * 256 = 65536个格子的大棋盘。在这个棋盘中，这样中（简繁）日韩（还包括越南）文字作为CJK字符集都放在一定的区位内，为了减少重复，各种语言中写法一样 的字共享一个“棋格”。详细的区位见
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缺省编码方式的影响，因此我做了一个，用于打印显示不同系统下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.toString() + "\t" + list.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 命令可以显示系统当前的