(转载)Java中文问题及最优解决方法

近日,由于中文问题的困饶，于是从csdn上,开始搜比较好的解决方案,这个方法不错,涉及到各个方面.基本上都可以处理所有在jsp.servlet.等j2ee开中所涉及到的中文乱码等问题....希望对你也有帮助.

转自:http://kb.csdn.net/java/articles/200507/e0250084-7ca0-4de4-be4b-53fdd9f233e8.html

Java中文问题及最优解决方法

作者： ∣来源： JavaResearch∣ 原文地址∣ 2005-7-9

由于Java编程中的中文问题是一个老生常谈的问题，在阅读了许多关于Java中文问题解决方法之后，结合作者的编程实践，我发现过去谈的许多方法都不能清晰地说明问题及解决问题，尤其是跨平台时的中文问题。于是我给出此篇文章，内容包括对控制台运行的class、Servelets、JSP及EJB类中的中文问题我剖析和建议解决办法。希望大家指教。 
　　Abstract：本文深入分析了Java程序设计中Java编译器对java源文件和JVM对class类文件的编码/解码过程，通过此过程的解析透视出了Java编程中中文问题产生的根本原因，最后给出了建议的最优化的解决Java中文问题的方法。 

　　1、中文问题的来源 

计算机最初的操作系统支持的编码是单字节的字符编码，于是，在计算机中一切处理程序最初都是以单字节编码的英文为准进行处理。随着计算机的发展，为了适应世界其它民族的语言（当然包括我们的汉字），人们提出了UNICODE编码，它采用双字节编码，兼容英文字符和其它民族的双字节字符编码，所以，目前，大多数国际性的软件内部均采用UNICODE编码，在软件运行时，它获得本地支持系统（多数时间是操作系统）默认支持的编码格式，然后再将软件内部的UNICODE转化为本地系统默认支持的格式显示出来。Java的JDK和JVM即是如此，我这里说的JDK是指国际版的JDK，我们大多数程序员使用的是国际化的JDK版本，以下所有的JDK均指国际化的JDK版本。我们的汉字是双字节编码语言，为了能让计算机处理中文，我们自己制定的gb2312、GBK、GBK2K等标准以适应计算机处理的需求。所以，大部分的操作系统为了适应我们处理中文的需求，均定制有中文操作系统，它们采用的是GBK,GB2312编码格式以正确显示我们的汉字。如：中文Win2K默认采用的是GBK编码显示，在中文WIN2k中保存文件时默认采用的保存文件的编码格式也是GBK的，即，所有在中文WIN2K中保存的文件它的内部编码默认均采用GBK编码，注意：GBK是在GB2312基础上扩充来的。

由于Java语言内部采用UNICODE编码，所以在JAVA程序运行时，就存在着一个从UNICODE编码和对应的操作系统及浏览器支持的编码格式转换输入、输出的问题，这个转换过程有着一系列的步骤，如果其中任何一步出错，则显示出来的汉字就会出是乱码，这就是我们常见的JAVA中文问题。

同时，Java是一个跨平台的编程语言，也即我们编写的程序不仅能在中文windows上运行，也能在中文Linux等系统上运行，同时也要求能在英文等系统上运行（我们经常看到有人把在中文win2k上编写的JAVA程序，移植到英文Linux上运行）。这种移植操作也会带来中文问题。

还有，有人使用英文的操作系统和英文的IE等浏览器，来运行带中文字符的程序和浏览中文网页，它们本身就不支持中文，也会带来中文问题。

几乎所有的浏览器默认在传递参数时都是以UTF-8编码格式来传递，而不是按中文编码传递，所以，传递中文参数时也会有问题，从而带来乱码现象。

总之，以上几个方面是JAVA中的中文问题的主要来源，我们把以上原因造成的程序不能正确运行而产生的问题称作：JAVA中文问题。

　　2、JAVA编码转换的详细过程 

我们常见的JAVA程序包括以下类别：
*直接在console上运行的类(包括可视化界面的类)
*JSP代码类（注：JSP是Servlets类的变型）
*Servelets类
*EJB类
*其它不可以直接运行的支持类

这些类文件中，都有可能含有中文字符串，并且我们常用前三类JAVA程序和用户直接交互，用于输出和输入字符，如：我们在JSP和Servlet中得到客户端送来的字符，这些字符也包括中文字符。无论这些JAVA类的作用如何，这些JAVA程序的生命周期都是这样的：

*编程人员在一定的操作系统上选择一个合适的编辑软件来实现源程序代码并以.java扩展名保存在操作系统中，例如我们在中文win2k中用记事本编辑一个java源程序；
*编程人员用JDK中的javac.exe来编译这些源代码，形成.class类(JSP文件是由容器调用JDK来编译的)；
*直接运行这些类或将这些类布署到WEB容器中去运行，并输出结果。
那么，在这些过程中，JDK和JVM是如何将这些文件如何编码和解码并运行的呢？

这里，我们以中文win2k操作系统为例说明JAVA类是如何来编码和被解码的。 


第一步，我们在中文win2k中用编辑软件如记事本编写一个Java源程序文件(包括以上五类JAVA程序)，程序文件在保存时默认采用了操作系统默认支持GBK编码格式(操作系统默认支持的格式为file.encoding格式)形成了一个.java文件，也即，java程序在被编译前，我们的JAVA源程序文件是采用操作系统默认支持的file.encoding编码格式保存的，java源程序中含有中文信息字符和英文程序代码；要查看系统的file.encoding参数，可以用以下代码：
　　public class ShowSystemDefaultEncoding {
　　public static void main(String[] args) {
　　String encoding = System.getProperty("file.encoding");
　　System.out.println(encoding);
　　}}

第二步，我们用JDK的javac.exe文件编译我们的Java源程序，由于JDK是国际版的，在编译的时候，如果我们没有用-encoding参数指定我们的JAVA源程序的编码格式，则javac.exe首先获得我们操作系统默认采用的编码格式，也即在编译java程序时，若我们不指定源程序文件的编码格式，JDK首先获得操作系统的file.encoding参数(它保存的就是操作系统默认的编码格式，如WIN2k，它的值为GBK)，然后JDK就把我们的java源程序从file.encoding编码格式转化为JAVA内部默认的UNICODE格式放入内存中。然后，javac把转换后的unicode格式的文件进行编译成.class类文件，此时.class文件是UNICODE编码的，它暂放在内存中，紧接着，JDK将此以UNICODE编码的编译后的class文件保存到我们的操作系统中形成我们见到的.class文件。对我们来说，我们最终获得的.class文件是内容以UNICODE编码格式保存的类文件，它内部包含我们源程序中的中文字符串，只不过此时它己经由file.encoding格式转化为UNICODE格式了。

这一步中，对于JSP源程序文件是不同的，对于JSP，这个过程是这样的：即WEB容器调用JSP编译器，JSP编译器先查看JSP文件中是否设置有文件编码格式，如果JSP文件中没有设置JSP文件的编码格式，则JSP编译器调用JDK先把JSP文件用JVM默认的字符编码格式(也即WEB容器所在的操作系统的默认的file.encoding)转化为临时的Servlet类，然后再把它编译成UNICODE格式的class类，并保存在临时文件夹中。如：在中文win2k上，WEB容器就把JSP文件从GBK编码格式转化为UNICODE格式，然后编译成临时保存的Servlet类，以响应用户的请求。

第三步，运行第二步编译出来的类，分为三种情况：

A、 直接在console上运行的类
B、 EJB类和不可以直接运行的支持类(如JavaBean类)
C、 JSP代码和Servlet类
D、 JAVA程序和数据库之间
下面我们分这四种情况来看。
A、直接在console上运行的类

这种情况，运行该类首先需要JVM支持，即操作系统中必须安装有JRE。运行过程是这样的：首先java启动JVM，此时JVM读出操作系统中保存的class文件并把内容读入内存中，此时内存中为UNICODE格式的class类，然后JVM运行它，如果此时此类需要接收用户输入，则类会默认用file.encoding编码格式对用户输入的串进行编码并转化为unicode保存入内存（用户可以设置输入流的编码格式）。程序运行后，产生的字符串（UNICODE编码的）再回交给JVM，最后JRE把此字符串再转化为file.encoding格式(用户可以设置输出流的编码格式)传递给操作系统显示接口并输出到界面上。

对于这种直接在console上运行的类，它的转化过程可用图1更加明确的表示出来：

（不好意思，图传不上来，只好让大家自己去想像图的样子了，我想看了上文是可以想来图来的。）
以上每一步的转化都需要正确的编码格式转化，才能最终不出现乱码现象。

B、EJB类和不可以直接运行的支持类(如JavaBean类)

由于EJB类和不可以直接运行的支持类，它们一般不与用户直接交互输入和输出，它们常常与其它的类进行交互输入和输出，所以它们在第二步被编译后，就形成了内容是UNICODE编码的类保存在操作系统中了，以后只要它与其它的类之间的交互在参数传递过程中没有丢失，则它就会正确的运行。
这种EJB类和不可以直接运行的支持类, 它的转化过程可用图2更加明确的表示出来： 


图2
（不好意思，图传不上来，只好让大家自己去想像图的样子了，我想看了上文是可以想来图来的。）
C、JSP代码和Servlet类

经过第二步后，JSP文件也被转化为Servlets类文件，只不过它不像标准的Servlets一校存在于classes目录中，它存在于WEB容器的临时目录中，故这一步中我们也把它做为Servlets来看。

对于Servlets，客户端请求它时，WEB容器调用它的JVM来运行Servlet，首先，JVM把Servlet的class类从系统中读出并装入内存中，内存中是以UNICODE编码的Servlet类的代码，然后JVM在内存中运行该Servlet类，如果Servlet在运行的过程中，需要接受从客户端传来的字符如：表单输入的值和URL中传入的值，此时如果程序中没有设定接受参数时采用的编码格式，则WEB容器会默认采用ISO-8859-1编码格式来接受传入的值并在JVM中转化为UNICODE格式的保存在WEB容器的内存中。Servlet运行后生成输出，输出的字符串是UNICODE格式的，紧接着，容器将Servlet运行产生的UNICODE格式的串（如html语法，用户输出的串等）直接发送到客户端浏览器上并输出给用户，如果此时指定了发送时输出的编码格式，则按指定的编码格式输出到浏览器上，如果没有指定，则默认按ISO-8859-1编码发送到客户的浏览器上。这种JSP代码和Servlet类，它的转化过程可用图3更加明确地表示出来：

（不好意思，图传不上来，只好让大家自己去想像图的样子了，我想看了上文是可以想来图来的。）
D、Java程序和数据库之间 


对于几乎所有数据库的JDBC驱动程序，默认的在JAVA程序和数据库之间传递数据都是以ISO-8859-1为默认编码格式的，所以，我们的程序在向数据库内存储包含中文的数据时，JDBC首先是把程序内部的UNICODE编码格式的数据转化为ISO-8859-1的格式，然后传递到数据库中，在数据库保存数据时，它默认即以ISO-8859-1保存，所以，这是为什么我们常常在数据库中读出的中文数据是乱码。
对于JAVA程序和数据库之间的数据传递，我们可以用图4清晰地表示出来

图4（不好意思，图传不上来，只好让大家自己去想像图的样子了，我想看了上文是可以想来图来的。）

3、分析常见的JAVA中文问题几个必须清楚的原则

首先，经过上面的详细分析，我们可以清晰地看到，任何JAVA程序的生命期中，其编码转换的关键过程是在于：最初编译成class文件的转码和最终向用户输出的转码过程。
其次，我们必须了解JAVA在编译时支持的、常用的编码格式有以下几种：
*ISO-8859-1，8-bit, 同8859_1,ISO-8859-1,ISO_8859_1等编码
*Cp1252，美国英语编码，同ANSI标准编码
*UTF-8，同unicode编码
*GB2312，同gb2312-80,gb2312-1980等编码
*GBK , 同MS936，它是gb2312的扩充
及其它的编码，如韩文、日文、繁体中文等。同时，我们要注意这些编码间的兼容关体系如下：
unicode和UTF-8编码是一一对应的关系。GB2312可以认为是GBK的子集，即GBK编码是在gb2312上扩展来的。同时，GBK编码包含了20902个汉字，编码范围为：0x8140-0xfefe，所有的字符可以一一对应到UNICODE2.0中来。

再次，对于放在操作系统中的.java源程序文件，在编译时，我们可以指定它内容的编码格式，具体来说用-encoding来指定。注意：如果源程序中含有中文字符，而你用-encoding指定为其它的编码字符，显然是要出错的。用-encoding指定源文件的编码方式为GBK或gb2312，无论我们在什么系统上编译含有中文字符的JAVA源程序都不会有问题，它都会正确地将中文转化为UNICODE存储在class文件中。

然后，我们必须清楚，几乎所有的WEB容器在其内部默认的字符编码格式都是以ISO-8859-1为默认值的，同时，几乎所有的浏览器在传递参数时都是默认以UTF-8的方式来传递参数的。所以，虽然我们的Java源文件在出入口的地方指定了正确的编码方式，但其在容器内部运行时还是以ISO-8859-1来处理的。

4、中文问题的分类及其建议最优解决办法

了解以上JAVA处理文件的原理之后，我们就可以提出了一套建议最优的解决汉字问题的办法。
我们的目标是：我们在中文系统中编辑的含有中文字符串或进行中文处理的JAVA源程序经编译后可以移值到任何其它的操作系统中正确运行，或拿到其它操作系统中编译后能正确运行，能正确地传递中文和英文参数，能正确地和数据库交流中英文字符串。
我们的具体思路是：在JAVA程序转码的入口和出口及JAVA程序同用户有输入输出转换的地方限制编码方法使之正确即可。

具体解决办法如下：

1、 针对直接在console上运行的类
对于这种情况，我们建议在程序编写时，如果需要从用户端接收用户的可能含有中文的输入或含有中文的输出，程序中应该采用字符流来处理输入和输出，具体来说，应用以下面向字符型节点流类型：
对文件：FileReader，FileWrieter 
其字节型节点流类型为：FileInputStream，FileOutputStream
对内存（数组）：CharArrayReader，CharArrayWriter
其字节型节点流类型为：ByteArrayInputStream，ByteArrayOutputStream
对内存（字符串）：StringReader，StringWriter
对管道：PipedReader，PipedWriter
其字节型节点流类型为：PipedInputStream，PipedOutputStream
同时，应该用以下面向字符型处理流来处理输入和输出：
BufferedWriter，BufferedReader
其字节型的处理流为：BufferedInputeStream，BufferedOutputStream
InputStreamReader，OutputStreamWriter
其字节型的处理流为：DataInputStream，DataOutputStream
其中InputStreamReader和InputStreamWriter用于将字节流按照指定的字符编码集转换到字符流，如：
InputStreamReader in = new InputStreamReader(System.in，"GB2312")；
OutputStreamWriter out = new OutputStreamWriter (System.out，"GB2312")；
例如：采用如下的示例JAVA编码就达到了要求：

//Read.java
import java.io.*;
public class Read {
public static void main(String[] args) throws IOException {
String str = "/n中文测试，这是内部硬编码的串"+"/ntest english character";
String strin= "";
BufferedReader stdin = new BufferedReader(new InputStreamReader(System.in,"gb2312")); //设置输入接口按中文编码
BufferedWriter stdout = new BufferedWriter(new OutputStreamWriter(System.out,"gb2312")); //设置输出接口按中文编码
stdout.write("请输入:");
stdout.flush();
strin = stdin.readLine();
stdout.write("这是从用户输入的串："+strin);
stdout.write(str);
stdout.flush();
}}
同时，在编译程序时，我们用以下方式来进行：
javac -encoding gb2312 Read.java
其运行结果如图5所示：




图5（不好意思，图传不上来，只好让大家自己去想像图的样子了，我想看了上文是可以想来图来的。）

2、 针对EJB类和不可以直接运行的支持类(如JavaBean类)

由于这种类它们本身被其它的类调用，不直接与用户交互，故对这种类来说，我们的建议的处理方式是内部程序中应该采用字符流来处理程序内部的中文字符串（具体如上面一节中一样），同时，在编译类时用-encoding gb2312参数指示源文件是中文格式编码的即可。


3、 针对Servlet类

针对Servlet，我们建议用以下方法：

在编译Servlet类的源程序时，用-encoding指定编码为GBK或GB2312，且在向用户输出时的编码部分用response对象的setContentType("text/html;charset=GBK");或gb2312来设置输出编码格式，同样在接收用户输入时，我们用request.setCharacterEncoding("GB2312")；这样无论我们的servlet类移植到什么操作系统中，只有客户端的浏览器支持中文显示，就可以正确显示。如下是一个正确的示例：

//HelloWorld.java
package hello;
import java.io.*;
import javax.servlet.*;
import javax.servlet.http.*;
public class HelloWorld extends HttpServlet
{
public void init() throws ServletException { }
public void doGet(HttpServletRequest request, HttpServletResponse response) throws IOException, ServletException
{
request.setCharacterEncoding("GB2312"); //设置输入编码格式
response.setContentType("text/html;charset=GB2312"); //设置输出编码格式
PrintWriter out = response.getWriter(); //建议使用PrintWriter输出
out.println("<hr>");
out.println("Hello World! This is created by Servlet!测试中文!");
out.println("<hr>");
}
public void doPost(HttpServletRequest request, HttpServletResponse response) throws IOException, ServletException
{
request.setCharacterEncoding("GB2312"); //设置输入编码格式
response.setContentType("text/html;charset=GB2312"); //设置输出编码格式
String name = request.getParameter("name");
String id = request.getParameter("id");
if(name==null) name="";
if(id==null) id="";
PrintWriter out = response.getWriter(); //建议使用PrintWriter输出
out.println("<hr>");
out.println("你传入的中文字串是：" + name);
out.println("<hr>你输入的id是：" + id);
out.println("<hr>");
}
public void destroy() { }
}
请用javac -encoding gb2312 HelloWorld.java来编译此程序。
测试此Servlet的程序如下所示：
<%@page contentType="text/html; charset=gb2312"%>
<%request.setCharacterEncoding("GB2312");%>
<html><head><title></title>
<Script language="JavaScript">
function Submit() {
//通过URL传递中文字符串值给Servlet
document.base.action = "./HelloWorld?name=中文";
document.base.method = "POST";
document.base.submit();
}
</Script>
</head>

<body bgcolor="#FFFFFF" text="#000000" topmargin="5">
<form name="base" method = "POST" target="_self">
<input name="id" type="text" value="" size="30">
<a href = "JavaScript:Submit()">传给Servlet</a>
</form></body></html>
其运行结果如图6所示：




图6（不好意思，图传不上来，只好让大家自己去想像图的样子了，我想看了上文是可以想来图来的。）

4、 JAVA程序和数据库之间

为避免JAVA程序和数据库之间数据传递出现乱码现象，我们建议采用以下最优方法来处理：
1、 对于JAVA程序的处理方法按我们指定的方法处理。
2、 把数据库默认支持的编码格式改为GBK或GB2312的。

如：在mysql中，我们可以在配置文件my.ini中加入以下语句实现：
在[mysqld]区增加：
default-character-set=gbk
并增加：
[client]
default-character-set=gbk
在SQL Server2K中，我们可以将数据库默认的语言设置为Simplified Chinese来达到目的。

5、 针对JSP代码

由于JSP是在运行时，由WEB容器进行动态编译的，如果我们没有指定JSP源文件的编码格式，则JSP编译器会获得服务器操作系统的file.encoding值来对JSP文件编译的，它在移植时最容易出问题，如在中文win2k中可以很好运行的jsp文件拿到英文linux中就不行，尽管客户端都是一样的，那是因为容器在编译JSP文件时获取的操作系统的编码不同造成的（在中文wink中的file.encoding和在英文Linux中file.encoding是不同的，且英文Linux的file.encoding对中文不支持，所以编译出来的JSP类就会有问题）。网络上讨论的大多数是此类问题，多是因为JSP文件移植平台时不能正确显示的问题，对于这类问题，我们了解了JAVA中程序编码转换的原理，解决起来就容易多了。我们建议的解决办法如下：

1、我们要保证JSP向客户端输出时是采用中文编码方式输出的，即无论如何我们首先在我们的JSP源代编中加入以下一行：

<%@page contentType="text/html; charset=gb2312"%>
2、为了让JSP能正确获得传入的参数，我们在JSP源文件头加入下面一句：
<%request.setCharacterEncoding("GB2312");%>
3、为了让JSP编译器能正确地解码我们的含有中文字符的JSP文件，我们需要在JSP源文件中指定我们的JSP源文件的编码格式，具体来说，我们在JSP源文件头上加入下面的一句即可：
<%@page pageEncoding="GB2312"%>或<%@page pageEncoding="GBK"%>
这是JSP规范2.0新增加的指令。
我们建议使用此方法来解JSP文件中的中文问题，下面的代码是一个正确做法的JSP文件的测试程序：

//testchinese.jsp
<%@page pageEncoding="GB2312"%>
<%@page contentType="text/html; charset=gb2312"%>
<%request.setCharacterEncoding("GB2312");%>
<%
String action = request.getParameter("ACTION");
String name = "";
String str = "";
if(action!=null && action.equals("SENT"))
{
name = request.getParameter("name");
str = request.getParameter("str");
}
%>
<html>
<head>
<title></title>
<Script language="JavaScript">
function Submit()
{
document.base.action = "?ACTION=SENT&str=传入的中文";
document.base.method = "POST";
document.base.submit();
}
</Script>
</head>
<body bgcolor="#FFFFFF" text="#000000" topmargin="5">
<form name="base" method = "POST" target="_self">
<input type="text" name="name" value="" size="30">
<a href = "JavaScript:Submit()">提交</a>
</form>
<%
if(action!=null && action.equals("SENT"))
{
out.println("<br>你输入的字符为："+name);
out.println("<br>你通过URL传入的字符为："+str);
}
%>
</body>
</html>
如图7是此程序运行的结果示意图：




图7（不好意思，图传不上来，只好让大家自己去想像图的样子了，我想看了上文是可以想来图来的。）


5、总结

在上面的详细分析中，我们清晰地给出了JAVA在处理源程序过程中的详细转换过程，为我们正确解决JAVA编程中的中文问题提供了基础。同时，我们给出了认为是最优的解决JAVA中文问题的办法。


 


再谈Java中文问题 
 
我来说一下tomcat如何实现JSP的你就明白了。
预备知识：
　1.字节和unicode
　　Java内核是unicode的，就连class文件也是，但是很多媒体，包括文件/流的保存方式
　　是使用字节流的。 因此Java要对这些字节流经行转化。char是unicode的，而byte是字节.
　　Java中byte/char互转的函数在sun.io的包中间有。其中ByteToCharConverter类是中调度，
　　可以用来告诉你，你用的Convertor。其中两个很常用的静态函数是
　　 public static ByteToCharConverter getDefault() ;
　　 public static ByteToCharConverter getConverter(String encoding);
　　如果你不指定converter，则系统会自动使用当前的Encoding,GB平台上用GBK,EN平台上用
　　8859_1
　　
　　我们来就一个简单的例子：
　　　　　"你"的gb码是：0xC4E3 ,unicode是0x4F60
　　　　　你用:
　　　　　--encoding="gb2312";
　　　　　--byte b[]={(byte)'/u00c4',(byte)'/u00E3'};
　　　　　--convertor=ByteToCharConverter.getConverter(encoding);
　　　　　--char [] c=converter.convertAll(b);
　　　　　--for(int i=0;i<c.length;c++)
　　　　　--{
　　　　　-- System.out.println(Integer.toHexString(c[i]));
　　　　　--}
　　　　　--打印出来是0x4F60
　　　　　--但是如果使用8859_1的编码，打印出来是
　　　　　--0x00C4,0x00E3
　　　　　----例１
　　　　 反过来：
　　　　 --encoding="gb2312";
　　　　 　　　char c[]={'/u4F60'};
　　　　　　　 convertor=ByteToCharConverter.getConverter(encoding);
　　　　　--byte [] b=converter.convertAll(c);
　　　　　--for(int i=0;i<b.length;c++)
　　　　　--{
　　　　　-- System.out.println(Integer.toHexString(b[i]));
　　　　　--}
　　　　　　--打印出来是：0xC4,0xE3
　　　　　　----例２
　　　　　　--如果用8859_1就是0x3F，?号，表示无法转化　　　　　　--
　　　　　 很多中文问题就是从这两个最简单的类派生出来的。而却有很多类　　
　　不直接支持把Encoding输入，这给我们带来诸多不便。很多程序难得用encoding
　　了，直接用default的encoding，这就给我们移植带来了很多困难
　　--
　　2.UTF-8
　　--UTF-8是和Unicode一一对应的，其实现很简单
　　--
　　 -- 7位的Unicode: 0 _ _ _ _ _ _ _
　　--11位的Unicode: 1 1 0 _ _ _ _ _ 1 0 _ _ _ _ _ _
　　--16位的Unicode: 1 1 1 0 _ _ _ _ 1 0 _ _ _ _ _ _ 1 0 _ _ _ _ _ _
　　--21位的Unicode: 1 1 1 1 0 _ _ _ 1 0 _ _ _ _ _ _ 1 0 _ _ _ _ _ _ 1 0 _ _ _ _ _ _
　　--大多数情况是只使用到16位以下的Unicode:
　　--"你"的gb码是：0xC4E3 ,unicode是0x4F60
　　--我们还是用上面的例子
　　--　　--例１：0xC4E3的二进制：
　　--　　--　　　 1 1 0 0 0 1 0 0 1 1 1 0 0 0 1 1
　　--　　--　　　 由于只有两位我们按照两位的编码来排，但是我们发现这行不通，
　　--　　--　　　 因为第７位不是0因此，返回"?"
　　--　　--　　　 
　　--　　--例２：0x4F60的二进制：
　　--　　--　　　 0 1 0 0 1 1 1 1 0 1 1 0 0 0 0 0 
　　--　　--　　　 我们用UTF-8补齐，变成：
　　--　　--　　　 11100100 10111101 10100000
　　--　　--　　　 E4--BD-- A0
　　--　　--　　　 于是返回0xE4,0xBD,0xA0
　　--　　--
　　3.String和byte[]
　　--String其实核心是char[],然而要把byte转化成String，必须经过编码。
　　--String.length()其实就是char数组的长度，如果使用不同的编码，很可
　　--能会错分，造成散字和乱码。
　　--例：
　　----byte [] b={(byte)'/u00c4',(byte)'/u00e3'};
　　----String str=new String(b,encoding);　　----
　　----如果encoding=8859_1，会有两个字，但是encoding=gb2312只有一个字　　----
　　--这个问题在处理分页是经常发生
　　4.Reader,Writer/InputStream,OutputStream
　　--Reader和Writer核心是char，InputStream和OutputStream核心是byte。
　　--但是Reader和Writer的主要目的是要把Char读/写InputStream/OutputStream
--一个reader的例子：
--文件test.txt只有一个"你"字，0xC4,0xE3--
--String encoding=;
--InputStreamReader reader=new InputStreamReader(
----new FileInputStream("text.txt"),encoding);
--char []c=new char[10];
--int length=reader.read(c);
--for(int i=0;i<c.length;i++)
----System.out.println(c[i]);
　　--如果encoding是gb2312，则只有一个字符，如果encoding=8859_1，则有两个字符
　　--------
--
--
　　
　　 ----
　2.我们要对Java的编译器有所了解：
　--javac -encoding
　 我们常常没有用到ENCODING这个参数。其实Encoding这个参数对于跨平台的操作是很重要的。
　 如果没有指定Encoding，则按照系统的默认Encoding,gb平台上是gb2312，英文平台上是ISO8859_1。　 
　--Java的编译器实际上是调用sun.tools.javac.Main的类，对文件进行编译，这个类　--
　有compile函数中间有一个encoding的变量,-encoding的参数其实直接传给encoding变量。
　编译器就是根据这个变量来读取java文件的，然后把用UTF-8形式编译成class文件。
　一个例子：
　--public void test()
　--{
　----String str="你";
　----FileWriter write=new FileWriter("test.txt");
　----write.write(str);
　----write.close();
　--}
　----例３
--如果用gb2312编译，你会找到E4 BD A0的字段
--
--如果用8859_1编译，
--00C4 00E3的二进制：
--00000000 11000100 00000000 11100011--
--因为每个字符都大于7位，因此用11位编码：
--11000001 10000100 11000011 10100011 
--C1-- 84--　C3--　 A3
--你会找到C1 84 C3 A3 --
　　　　
　　但是我们往往忽略掉这个参数，因此这样往往会有跨平台的问题：
　　--　　例３在中文平台上编译，生成ZhClass
　　--　　例３在英文平台上编译，输出EnClass
　　--1.　 ZhClass在中文平台上执行OK,但是在英文平台上不行
　　--2.　 EnClass在英文平台上执行OK,但是在中文平台上不行
　　原因：
　--1.在中文平台上编译后，其实str在运行态的char[]是0x4F60,　----
　--在中文平台上运行，FileWriter的缺省编码是gb2312,因此
　--CharToByteConverter会自动用调用gb2312的converter,把str转化
　--成byte输入到FileOutputStream中，于是0xC4,0xE3放进了文件。
　--但是如果是在英文平台下，CharToByteConverter的缺省值是8859_1,
　--FileWriter会自动调用8859_1去转化str,但是他无法解释，因此他会
　--输出"?"　----
　--2.　在英文平台上编译后，其实str在运行态的char[]是0x00C4 0x00E3,　----
　--在中文平台上运行，中文无法识别，因此会出现??
　--　　在英文平台上，0x00C4-->0xC4,0x00E3->0xE3，因此0xC4,0xE3被放进了
　--文件
----
1.对于JSP正文的解释：
--Tomcat首先看一下你的叶面中有没有"<%@page include的符号。有，则在相同
--地方设定response.setContentType(..);按照encoding的来读，没有他按照8859_1
--读取文件，然后用UTF-8写成.java文件，然后用sun.tools.Main去读取这个文件，
--（当然它使用UTF-8去读），然后编译成class文件
--setContentType改变的是out的属性，out变量缺省的encoding是8859_1

2.对Parameter的解释
--很不幸Parameter只有ISO8859_1的解释，这个质料可以在servlet的实现代码中找到。

3.对include的解释
格式的，但是很不幸，由于那个写"org.apache.jasper.compiler.Parser"的人
在数组JspUtil.ValidAttribute[]忘记加了一个参数：encoding,因此导致不支
持这种方式。你完全可以编译源代码，加上对encoding的支持

总结：

如果你在NT底下，最简单的方法就是欺骗java,不加任何Encoding变量：
<html>
你好<%=request.getParameter("value")%>
</html>

http://localhost/test/test.jsp?value=你

结果:你好你

但这种方法局限性较大，比如对上传的文章分段，这样的做法是死定的，最好的
解决方案是用这种方案：
<%@ page contentType="text/html;charset=gb2312" %>
<html>
你好<%=new String(request.getParameter("value").getBytes("8859_1"),"gb2312")%>
</html>