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编码(表现为编译生成的.class文件和加载进内存中的class字节码是UNICODE编码，而不是Java源文件为UNICODE编码，Java源文件可以为任意的编码类型)，所以在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编码格式保存的(通过一些文本编辑器如：notepade可以指定文件的编码格式，而不使用操作系统默认的编码格式)，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文件(因此使用国际版JDK编译产生的所有.class文件都是UNICODE编码格式的，而不依赖于特定的操作系统，因此跨平台指的是.class文件，而不是.java源文件)。对我们来说，我们最终获得的.class文件是内容以UNICODE编码格式保存的类文件，它内部包含我们源程序中的中文字符串，只不过此时它己经由file.encoding格式转化为UNICODE格式了。
PS:实验如下:
这里我新建了一个Hello.java文件，经过测试，使用的是OS默认的字符集GB2312，如下：
使用EditPlus打开该文件进行编辑，并且将当前文件的编码方式修改为UTF-8，保存：
使用自己编写的java程序进行测试，确实是UTF-8格式：
然后对该文件进行编译，正常，执行时发现乱码，如下：
这个是因为JDK在默认情况下使用了OS的字符集进行解码的结果，即使用了中文操作系统的GB2312字符集进行了解码，但实际上Hello.java文件使用的是UTF-8的方式编码，编码解码方式不一致就出现了乱码状态。
解决问题的方式如下：
即 使用-encoding utf-8参数对Hello.java源文件进行重新编译。
这样就告诉编译器 “这里的Hello.java使用的是UTF-8进行编码的，请按照UTF-8的方式进行解码然后编译 ”，随后编译器做完这些事情之后会使用UNICODE编码并存储编译好的.class文件。
这一步中，对于JSP源程序文件是不同的，对于JSP，这个过程是这样的：即WEB容器调用JSP编译器，JSP编译器先查看JSP文件中是否设置有文件编码格式，如果JSP文件中没有设置JSP文件的编码格式，则JSP编译器调用JDK先把JSP文件用JVM默认的字符编码格式(也即WEB容器所在的操作系统的默认的file.encoding)转化为临时的Servlet类(此时转化为.java临时文件存储于外存中，并且经过查看发现是UNICODE格式--tomcat)，然后再把它编译成UNICODE格式的class类，并保存在临时文件夹中。如：在中文win2k上，WEB容器就把JSP文件从GBK编码格式转化为UNICODE格式，然后编译成临时保存的Servlet类，以响应用户的请求。
注意：这里需要解释一下，JSP含有指令标签，pageEncoding属性指的是当前jsp页面文件在编写的时候指定的底层实际编码方式两者需要一致，如果JSP文件的具体编码方式与page指令元素指定的编码方式不有任何不一致的情况，则会发生乱码情况，这是因为web容器可以首先分析JSP页面，因为指定页面编码方式的page指令元素是标准的英文格式(任何字符集中都包含有标准英文字符集)，因此可以通过分析jsp文件获取到当前文件的编码格式，如例中的UTF-8，然后，再根据这个编码方式对当前JSP文件进行解码，随后被JSP编译器按照JAVA的UNICODE转换为Servlet类临时文件，最后被JRE加载入内存中相应用户的请求。
第三步，运行第二步编译出来的类，分为三种情况：
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更加明确的表示出来：
C、JSP代码和Servlet类
经过第二步后，JSP文件也被转化为Servlets类文件，只不过它不像标准的Servlets一校存在于classes目录中，它存在于WEB容器的临时目录中，故这一步中我们也把它做为Servlets来看。
对于Servlets，客户端请求它时，WEB容器调用它的JVM来运行Servlet，首先，JVM把Servlet的class类从系统中读出并装入内存中，内存中是以UNICODE编码的Servlet类的代码，然后JVM在内存中运行该Servlet类，如果Servlet在运行的过程中，需要接受从客户端传来的字符如：表单输入的值和URL中传入的值，此时如果程序中没有设定接受参数时采用的编码格式，则WEB容器(注意将WEB容器内部编码方式与JDK使用的编码方式进行区别，这是两个系统，WEB容器使用JDK进行编译运行)会默认采用ISO-8859-1编码格式来接受传入的值并在JVM中转化为UNICODE格式的保存在WEB容器的内存中。Servlet运行后生成输出，输出的字符串是UNICODE格式的，紧接着，容器将Servlet运行产生的UNICODE格式的串(如html语法，用户输出的串等)直接发送到客户端浏览器上并输出给用户，如果此时指定了发送时输出的编码格式，则按指定的编码格式输出到浏览器上，如果没有指定，则默认按ISO-8859-1编码发送到客户的浏览器上。这种JSP代码和Servlet类，它的转化过程可用图3更加明确地表示出来：
------------------------------------------------
JSP&Servlet实验：
这样来做几个实验：
从用户输入URL请求页面，到用户提交表单返回正确页面整个过程分析字符集的转换过程：
1>用户请求JSP页面：
A. JSP页面的page指令元素的 pageEncoding属性指定的是当前页面的编码格式，一定要与当前页面文件的实际编码格式一致，容器编译会发生乱码；
B. page指令元素的 contentType属性指定的是当前页面内容在内部的UNICODE格式经过处理之后转换为何种编码返回给用户浏览器，例如
指的是,在虚拟机内部将UNICODE编码格式的字符串转换为GBK的编码格式的字节流返回给用户的浏览器,而不是默认的ISO-8859-1返回给浏览器。
C. 在JSP中的脚本段 通过 response.setCharacterEncoding("utf-8");指定的返回字符编码格式将会覆盖掉指令元素 指定的字符编码格式.(经过测试)
如下:
Test Characterid:
name:
这样用户请求时,因为使用的是ISO-8859-1字符集不支持中文,因此提交两个字将会显示乱码,如下图:
然后通过jsp中设置response.setCharacterEncoding("utf-8");覆盖page指令元素中指定的字符集;
Test Characterid:
name:
显示正常，如下图：
解释：关于浏览器能够正常解码字节流的原因是HTTP协议中有相应字段指定了字节流的编码格式，这样浏览器就能够按照正常的字符集解析这些中文字符了(前提：浏览器所在OS需要有相应字符集的支持)
2>在表单中输入中文数据并提交过程：在表单中能够输入中文,所输入中文的编码方式是按照当前页面的编码方式转换成为字节流提交的，但是如果不指定的话将会默认按照utf-8的编码格式进行编码，如果在服务器端设置接收到字节流的解码字符集与客户端提交的实际字节流的编码方式不一致的时候会发生乱码情况，在服务端设置字符解码方式为：request.setCharacterEncoding("GBK");这样就能指定客户端返回给服务端字符的编码方式，并按照这种编码方式进行解码。如下图：
package cn.edu.bupt.charset;
import java.io.IOException;
import java.io.PrintWriter;
import javax.servlet.ServletException;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
public class CharTest extends HttpServlet
{
@Override
public void doGet(HttpServletRequest req, HttpServletResponse resp)
throws ServletException, IOException
{
//TODO Auto-generated method stub req.setCharacterEncoding("GBK"); //设置从客户端接收到的字符的编码格式,并按照这种编码格式进行解码 resp.setContentType("text/html;charset=utf-8"); //设置返回给客户端的字符的编码方式,通过http协议指定客户端按照这种编码方式进行解码转换 String name = req.getParameter("name");
String id = req.getParameter("id");
PrintWriter out = resp.getWriter();
out.println("
");
out.println("你所输入的中文字符串是:" + name);
out.println("
你输入的id是:" + id);
out.println("
");
}
@Override
public void doPost(HttpServletRequest req, HttpServletResponse resp)
throws ServletException, IOException
{
//TODO Auto-generated method stub this.doGet(req, resp);
}
}
在实验中,我将客户端的contentType 指定为utf-8，这样服务端按照GBK方式进行解码的时候就会产生乱码，如下图：
如果在服务端不显式指定请求字节流的解码方式的话，容器将会按照默认的字符集(ISO-8859-1)进行解码，这样就会发生乱码.
如下:
Test Characterid:
name:
这里显示指定了，提交表单的页面字符使用的是utf-8进行编码的。
package cn.edu.bupt.charset;
import java.io.IOException;
import java.io.PrintWriter;
import javax.servlet.ServletException;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
public class CharTest extends HttpServlet
{
@Override
public void doGet(HttpServletRequest req, HttpServletResponse resp)
throws ServletException, IOException
{
//TODO Auto-generated method stub//req.setCharacterEncoding("GBK");这里注释掉，将会使用容器默认的字符集进行解码 resp.setContentType("text/html;charset=utf-8");
String name = req.getParameter("name");
String id = req.getParameter("id");
PrintWriter out = resp.getWriter();
out.println("
");
out.println("你所输入的中文字符串是:" + name);
out.println("
你输入的id是:" + id);
out.println("
");
}
@Override
public void doPost(HttpServletRequest req, HttpServletResponse resp)
throws ServletException, IOException
{
//TODO Auto-generated method stub this.doGet(req, resp);
}
}
这样，页面将会出现乱码：
但是将客户端的页面的编码方式改为容器默认的编码方式ISO-8859-1，将会显示正常，如下jsp文件：
response.setCharacterEncoding("ISO-8859-1");%>
Test Characterid:
name:
服务端Servlet代码不改变，仍然使用web容器默认的编码方式，中文字符将显示正常，如下图：
这就证明，web容器默认使用的编码解码方式是ISO-8859-1。
这样整个请求页面，填充数据，返回给服务端，服务器经过处理返回处理结果页面整个过程已经完成。
注意：在字符数据每次经过一个系统，都要考虑底层该字符集所对应二进制字节流的转换，一旦某一个环节发生转换错误均很有可能产生中文乱码情况。因此尽量显式指定这些字符编码解码的方式，便于控制，而不是使用各个系统自己默认的字符集。
------------------------------------------------------------------
D、Java程序和数据库之间
对于几乎所有数据库的JDBC驱动程序，默认的在JAVA程序和数据库之间传递数据都是以ISO-8859-1为默认编码格式的，所以，我们的程序在向数据库内存储包含中文的数据时，JDBC首先是把程序内部的UNICODE编码格式的数据转化为ISO-8859-1的格式，然后传递到数据库中，在数据库保存数据时，它默认即以ISO-8859-1保存，所以，这是为什么我们常常在数据库中读出的中文数据是乱码。
对于JAVA程序和数据库之间的数据传递，我们可以用图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来处理的，这里类似于JDK内部编码方式是使用UNICODE。
注意：如果需要指定用户从浏览器中输入的表单数据的编码方式传递给服务器端，需要在HTML代码的
元素中的属性accept-charset指定其用户输入参数的传输编码方式，具体如下：例如：
在GBK编码的页面里指定用户输入的表单数据的编码传输方式为UTF-8，编写如下代码：
...
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和OutputStreamWriter用于将字节流按照指定的字符编码集转换到字符流，如：
InputStreamReader in = new InputStreamReader(System.in，"GB2312")；
流程如下：
1>首先从控制台获取到输入的字节流，这里需要知道字节流是采用何种字符集进行编码的，这里是GB2312；
2>程序使用GB2312字符集对输入程序的字节流进行解码，然后转换成为Java虚拟机内部使用的UNICODE格式；
3>通过InputStreamReader的方法获取到的字符流在程序中就变成了可用的UNICODE编码格式字符串。
OutputStreamWriter out = new OutputStreamWriter (System.out，"GB2312")；
流程如下：
1>程序中首先准备好字符或字符串，这里使用的是JDK内部的UNICODE编码方式的字符串；
2>对字符串通过UNICODE -> GB2312 进行字节流转码；
3>将转换后的字节流通过write()函数写入输出流中，这样输出流中的字节流就是原来字符串的GB2312编码方式得到的。
例如：采用如下的示例JAVA编码就达到了要求：
import java.util.*;
import java.io.*;
public class Read
{
public static void main(String[] args) throws IOException
{
String str = "/n中文测试,这是内部硬编码串" + "/n test English Character";
String str1 = "";
BufferedReader stdin = new BufferedReader(new InputStreamReader(System.in, "gb2312"));
BufferedWriter stdout = new BufferedWriter(new OutputStreamWriter(System.out, "gb2312"));
stdout.write("请输入");
stdout.flush();
str1 = stdin.readLine();
stdout.write("这是用户输入的字符串:" + str1);
stdout.write(str);
stdout.flush();
}
}
同时，在编译程序时，我们用以下方式来进行：
javac -encoding gb2312 Read.java
其运行结果如图5所示：
这里均指定gb2312字符集的原因是中文windows操作系统均使用GBK字符集编码和解码，(从控制台输入的字符和想控制台输出的字符一定要采用GB2312编码格式)如果在上面两步中换成了其他的字符集，则在控制台均会出现乱码：
2、 针对EJB类和不可以直接运行的支持类(如JavaBean类)
由于这种类它们本身被其它的类调用，不直接与用户交互，故对这种类来说，我们的建议的处理方式是内部程序中应该采用字符流来处理程序内部的中文字符串(具体如上面一节中一样)，同时，在编译类时用-encoding gb2312参数指示源文件是中文格式编码的即可。
3、 针对Servlet类
针对Servlet，我们建议用以下方法：
在编译Servlet类的源程序时，用-encoding指定编码为GBK或GB2312，且在向用户输出时的编码部分用response.setContentType("text/html;charset=GB2312");或GBK来设置输出编码格式，同样在接收用户浏览器方面的输入时，我们用request.setCharacterEncoding("GB2312");这样无论我们的servlet类移植到什么操作系统中，只有客户端的浏览器支持中文显示，就可以正确显示。如下是一个正确的示例：
//HelloWorld.javapackage 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("
");
out.println("Hello World! This is created by Servlet!测试中文!");
out.println("
");
}
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("
");
out.println("你传入的中文字串是：" + name);
out.println("
你输入的id是：" + id);
out.println("
");
}
public void destroy()
{
}
}
请用javac -encoding gb2312 HelloWorld.java来编译此程序。
测试此Servlet的程序如下所示：
functionSubmit() {//通过URL传递中文字符串值给Servletdocument.base.action= "./HelloWorld?name=中文";
document.base.method= "POST";
document.base.submit();
}
传给Servlet
扫一扫
748
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
