Java中文编码转换分析
通常，我们遇到中文问题的来源一般都是，在jsp等显示到页面时，出现问题。
若想知道为什么出现乱码，就要从了解jsp --- > servlet --- > class 开始
其实，问题主要在 servlet --- > class 上，也就是 javac <*.java> 文件时出现了问题，
也许你要问为什么？这就是我下面要和大家讨论的。
首先，大家要清楚java的内核是unicode的，就连class文件也是，然后，日常应用中很多都是使用字节流的，包括文件流的保存方式。因此java要对此进行转换。
char ---------- unicode
byte ---------- 字节
java中的byte / char 互转的函数在sun.io的包中。
public static bytetocharconverter getdefault() ; public static bytetocharconverter getconverter(string encoding);
如果你向converter指定encoding ，则系统会自动使用当前的encoding， gb平台上用gbk ，en平台上用 8859_1 。
下面，是我在中文xp系统下的一段代码：
import java.io.FileWriter;
import java.io.IOException;
public class testEncoding {
public void test(){
String str = "你";
try{
FileWriter write=new FileWriter("test.txt");
write.write(str);
write.close();
}catch(IOException e){
System.out.println("has not found test.txt file !");
}
}
public static void main(String[] args){
testEncoding instance = new testEncoding();
instance.test();
}
}
//javac -encoding gbk/iso8859-1/utf-8 [常用的编码方式]
//测试结果，默认不用-encoding编译 和 选用 -encoding gbk 都是正常显示 “你”；
//如果用 -encoding utf-8/ios8859-1 则显示乱码 “??”
分析：String和byte[]
String其实核心是char[]，然而要把byte转化成String(或者String --- > byte)，必须经过编码。 string.length()其实就是char数组的长度，如果使用不同的编码，很可能会错分，造成散字和乱码。就好像上面例子中，错用javac –encoding ios8859-1 testEncoding.java 后，运行后文件中显示 “??” 一样。
分析：reader，writer / inputstream，outputstream
reader和writer核心是char，inputstream和outputstream核心是byte。但是reader和writer的主要目的是要把char读/写inputstream/outputstream 。这里用不同的编码格式会对结果造成不一样的影响。
分析：javac –encoding 参数
我们常常没有用到encoding这个参数。其实encoding这个参数对于跨平台的操作是很重要的。 如果没有指定encoding，则按照系统的默认encoding，gb平台上是gb2312，英文平台上是iso8859_1。 --java的编译器实际上是调用sun.tools.javac.main的类，对文件进行编译，这个类的compile函数中间有一个encoding的变量,-encoding的参数其实直接传给encoding变量。 编译器就是根据这个变量来读取java文件的，然后按照设定的encoding格式编译成class文件。
总结：
如果我们只是自己写一个或2个文件，那编码格式无所谓，怎么解决都可以，但是，对于开发人员，我们面对的通常都是一个庞大的系统，快平台也是很正常的，所以在编码格式上很难全局控制，一个企业化的解决方案就是，在系统中，无论html，jsp，java，只要是中文，都不要直接输入，采用资源串的方式来编写。这样才能形成真正的产品。
中文/英文资源串 可以利用 java.util. Properties; 来处理 。
如果你的系统支持struts, 也可以利用 org.apache.struts.util.MessageResources来处理 。
利用资源串处理中英文字符问题还有另外4个好处：
[1]、很多地方的资源串都是可以重复使用的(当然，为了模块独立，不同模块就算同样的字符也建议在不同的资源串文件写)
[2]、当很多地方的同意个字符串需要修改时，只要改写一个地方就ok了
[3]、如果要求系统支持中英文转换，那么，只要在显示资源串时根据local判断就可以了
[4]、在编码转换上，有很好的平台移植性，不用每次都考虑服务器上的编码方式，本地的编码方式，然后再写n个转换库。性能是也会有一定的影响。
另外大家需要注意我们常用的应用服务器tomcat的默认编码格式：iso8859-1
定义位置：tomcat下的web.xml 第一行：
<?xml version="1.0" encoding="ISO-8859-1"?>
通常系统开发后，很多应用服务器都需要打包发布，首推工具当然是ant了(好东西啊！)。
在用ant编译系统时，设定编码方式：
<!-- ================================================================ -->
<!--Compiles the java source code in the local -->
<!--================================================================ -->
<target name="compile.java" depends="prepare">
<javac encoding="${encoding}" destdir="${build.dir}/WEB-INF/classes" debug="on" deprecation="off" optimize="off"
srcdir="${webapp.path}/WEB-INF/classes" classpathref="run.classpath">
<include name="com/**/*.java"/>
</javac>
<copy todir="${build.dir}/WEB-INF/classes/com/neusoft/ehr/replets/standard">
<fileset dir="${src.dir}/WEB-INF/classes/com/neusoft/ehr/replets/standard" includes="**/*.srt"/>
</copy>
</target>
在我现在工作的系统中，jsp全部通过
<%@page contentType="text/html;charset=UTF-8"%> 指定编码方式
从上到下，我们整个系统无论在页面，编译，都采用相同的编码格式(UTF-8)
当然你也可以根据自己的需要设定自己的格式，但一定要统一(否则，有很多问题会找你的)。
选择UTF-8原因：大部分浏览器ie其高级设置中始终以utf-8发送url的选项缺省是选上的。
以我们的系统举例，我们用Eclipse来开发系统平台，开发时，通常为了修改bug，都要在本地直接用本地源代码进行系统发布，如果此时在java中直接写中文，在中文系统是没问题，但如果用设定了utf-8的ant编译后，就会出现中文，因为Eclipse默认的编码方式是GBK，就像我在第一个例子中说的那样
javac -encoding gbk/utf-8 显示出了不同。
不用资源串的项目事例：
在此，也多提一下，曾经在上海财大，我们公司其他部门的兄弟们作了个系统，也是很大的系统，但是整个系统都没有采用资源串，直接用中文，他们采取的方法大概是：
1、 获得服务端的编码方式
2、 获得客户端的编码方式
3、 写n个转换库，对编码格式进行转换
4、 (很多服务器，例如 HPUnix，经常需要设定服务器的环境变量，以处理编码)
优点：写的时候很方便，改的时候也可以
缺点：跨平台性差，不能全局替换
