BlogJava-人生就是努力!-文章分类-J2EE技术

JSP乱码解决大全

白露 — Wed, 19 Mar 2008 07:51:00 GMT

一、JSP页面显示乱码

二、表单提交中文时出现乱码

三、数据库连接

大家在JSP的开发过程中，经常出现中文乱码的问题，可能一至困扰着您，我现在把我在JSP开发中遇到

的中文乱码的问题及解决办法写出来供大家参考。

一、JSP页面显示乱码
下面的显示页面(display.jsp)就出现乱码：

JSP的中文处理

<%
out.print("JSP的中文处理");
%>

对不同的WEB服务器和不同的JDK版本，处理结果就不一样。原因：服务器使用的编码方式不同和浏览器

对不同的字符显示结果不同而导致的。解决办法：在JSP页面中指定编码方式(gb2312),即在页面的第一

行加上：<%@ page contentType="text/html; charset=gb2312"%>，就可以消除乱码了。完整页面如下

：
<%@ page contentType="text/html; charset=gb2312"%>

JSP的中文处理

<%
out.print("JSP的中文处理");
%>

二、表单提交中文时出现乱码
下面是一个提交页面(submit.jsp)，代码如下：

JSP的中文处理

下面是处理页面(process.jsp)代码：
<%@ page contentType="text/html; charset=gb2312"%>

JSP的中文处理

<%=request.getParameter("name")%>

如果submit.jsp提交英文字符能正确显示，如果提交中文时就会出现乱码。原因：浏览器默认使用UTF

-8编码方式来发送请求，而UTF- 8和GB2312编码方式表示字符时不一样，这样就出现了不能识别字符。

解决办法:通过request.seCharacterEncoding ("gb2312")对请求进行统一编码，就实现了中文的正常

显示。修改后的process.jsp代码如下：
<%@ page contentType="text/html; charset=gb2312"%>
<%
request.seCharacterEncoding("gb2312");
%>

JSP的中文处理

<%=request.getParameter("name")%>

三、数据库连接出现乱码
只要涉及中文的地方全部是乱码，解决办法：在数据库的数据库URL中加上
useUnicode=true&characterEncoding=GBK 就OK了。

四、数据库的显示乱码
在mysql4.1.0中,varchar类型，text类型就会出现中文乱码，对于varchar类型把它设为binary属性就

可以解决中文问题，对于text类型就要用一个编码转换类来处理，实现如下：
public class Convert {

public static String ISOtoGB(String iso){
String gb;
try{
if(iso.equals("") || iso == null){
return "";
}
else{
iso = iso.trim();
gb = new String(iso.getBytes("ISO-8859-1"),"GB2312");
return gb;
}
}
catch(Exception e){
System.err.print("编码转换错误："+e.getMessage());
return "";
}
}
}
把它编译成class，就可以调用Convert类的静态方法ISOtoGB()来转换编码。

如果你还有什么不懂之处：我给大家推荐一个好的JSP-JAVA网站：

http://www.phy.hbnu.edu.cn/dsp/

总结：

1.  在jsp中<%@ page contentType="text/html; charset=A" %>如果指定了，那么在改jsp中所有构造

的String（不是引用），如果沒有指定编码，那么这些String的编码是A的。
从request的得到的String如果沒有指定request的编码的话，他是iso-8859-1的
从别的地方得到的String是使用原來初始的编码的，比如从数据库得到String,如果数据库的编码

是B,那么该String的编码是B而不是A的，也不是系统默认的。
此时，如果要输出的String的编码不是A,那么，很可能显示乱码的，所以首先要将String正確转化

为编码A的String,然后输出。

2.  在jsp中<%@ page contentType="text/html; charset=A" %>沒有指定，那么相当于指定了<%@

page contentType="text/html; charset=ISO-8859-1" %>

3． Servelte中如果执行了像 response.setContentType("text/html;charset=A");説明将response的

字符输出流编码设置为A,所有要输出的String的编码要转化为A的，否則会得到乱码的。
Servelet中从request得到的String的编码和jsp中一样的，但是在servlet java文件中构造的

String是使用的系统默认的编码的。在servelt中从外部得到的String 是使用原来的编码的，比如从编

码为B的数据库得到的数据是编码为B的,不是A,也不是系统默认的编码。

//////////////////////////////////////////////////////////////////////////////////////////
转载：JSP中文乱码问题解决方法小结
　　在使用JSP的过程中，最使人头疼的一个问题就是中文乱码问题，以下是我在软件开发中遇到的乱

码问题以及解决方法。

1、JSP页面乱码
　　这种乱码的原因是应为没有在页面里指定使用的字符集编码，解决方法：只要在页面开始地方用下

面代码指定字符集编码即可，

2、数据库乱码
　　这种乱码会使你插入数据库的中文变成乱码，或者读出显示时也是乱码，解决方法如下：
　　在数据库连接字符串中加入编码字符集
　　String Url="jdbc:mysql://localhost/digitgulf?

user=root&password=root&useUnicode=true&characterEncoding=GB2312";
　　并在页面中使用如下代码：
　　response.setContentType("text/html;charset=gb2312");
　　request.setCharacterEncoding("gb2312");

3、中文作为参数传递乱码
　　当我们把一段中文字符作为参数传递个另一页面时，也会出现乱码情况，解决方法如下：
　　在参数传递时对参数编码，比如
　　RearshRes.jsp?keywords=" + java.net.URLEncoder.encode(keywords)
　　然后在接收参数页面使用如下语句接收
　　keywords=new String(request.getParameter("keywords").getBytes("8859_1"));

4、JSP页面乱码加这句
<%@ page contentType="text/html; charset=gb2312" language="java" import="java.sql.*"

errorPage="err.jsp" %>
/////////////////////////////////////////////////////////////////////////////////////////
JSP/JDBC MySQL乱码问题~~~
作者：佚名  来源：本站整理  发布时间：2005-7-1 12:24:30
綠起：
JSP的request 默认为ISO8859_1，所以在处理中文的时候，
要显示中文的话，必须转成GBK的，如下
String str=new String(request.getParameter("name").getBytes("ISO8859-1"),"GBK");
out.println(str);
这样就可以显示中文了

MYSQL操作时的中文问题：
这个要看MySQL的默认编码了，一般不调整的话为latin1其实和ISO8859_1一样，所以操作的时候要处理

和他一致，不然就会乱码的

1.插入中文：
String sql2="INSERT INTO test (name) VALUES('"+request.getParameter("name")+"')";
stmt.executeUpdate(sql2);
不用编码就可以插入了

2.显示插入的中文：
因为存入的是latin，所以显示的时候就要GBK一下
String x=new String((rs.getString("title")).getBytes("ISO8859_1"),"GBK");
out.println(x);

3.设定存储编码：
当然在MySQL为latin1编码时，也可以存的时候用GBK了
Connection con=DriverManager.getConnection("jdbc:mysql://localhost:3306/jsp?

useUnicode=true&characterEncoding=GBK","root","");
str1="中文";
String sql2="INSERT INTO test (name) VALUES('"+str1+"')";
这样也可以很成功的插入了，呵呵
////////////////////////////////////////////////////////////////////////////////////////
JSP/Servlet 中的汉字编码问题
（作者：张建芳，转自IBM DeveloperWorks 中国网站　2001年04月18日 15:08）

　　网上就 JSP/Servlet 中 DBCS 字符编码问题有许多优秀的文章和讨论，本文对它们作一些整理，

并结合 IBM WebSphere Application Server 3.5（WAS）的解决方法作一些说明，希望它不是多余的。

1.问题的起源
　　每个国家（或区域）都规定了计算机信息交换用的字符编码集，如美国的 ASCII，中国的 GB2312

-80，日本的 JIS 等，作为该国家/区域内信息处理的基础，有着统一编码的重要作用。字符编码集按

长度分为 SBCS（单字节字符集），DBCS（双字节字符集）两大类。早期的软件（尤其是操作系统），

为了解决本地字符信息的计算机处理，出现了各种本地化版本（L10N），为了区分，引进了 LANG，

Codepage 等概念。但是由于各个本地字符集代码范围重叠，相互间信息交换困难；软件各个本地化版

本独立维护成本较高。因此有必要将本地化工作中的共性抽取出来，作一致处理，将特别的本地化处理

内容降低到最少。这也就是所谓的国际化（I18N）。各种语言信息被进一步规范为 Locale 信息。处理

的底层字符集变成了几乎包含了所有字形的 Unicode。

　　现在大部分具有国际化特征的软件核心字符处理都是以 Unicode 为基础的，在软件运行时根据当

时的 Locale/Lang/Codepage 设置确定相应的本地字符编码设置，并依此处理本地字符。在处理过程中

需要实现 Unicode 和本地字符集的相互转换，甚或以 Unicode 为中间的两个不同本地字符集的相互转

换。这种方式在网络环境下被进一步延伸，任何网络两端的字符信息也需要根据字符集的设置转换成可

接受的内容。

　　Java 语言内部是用 Unicode 表示字符的，遵守 Unicode V2.0。Java 程序无论是从/往文件系统

以字符流读/写文件，还是往 URL 连接写 HTML 信息，或从 URL 连接读取参数值，都会有字符编码的

转换。这样做虽然增加了编程的复杂度，容易引起混淆，但却是符合国际化的思想的。

　　从理论上来说，这些根据字符集设置而进行的字符转换不应该产生太多问题。而事实是由于应用程

序的实际运行环境不同，Unicode 和各个本地字符集的补充、完善，以及系统或应用程序实现的不规范

，转码时出现的问题时时困扰着程序员和用户。

2.GB2312-80，GBK，GB18030-2000 汉字字符集
　　其实解决 JAVA 程序中的汉字编码问题的方法往往很简单，但理解其背后的原因，定位问题，还需

要了解现有的汉字编码和编码转换。

　　GB2312-80 是在国内计算机汉字信息技术发展初始阶段制定的，其中包含了大部分常用的一、二级

汉字，和 9 区的符号。该字符集是几乎所有的中文系统和国际化的软件都支持的中文字符集，这也是

最基本的中文字符集。其编码范围是高位0xa1－0xfe，低位也是 0xa1-0xfe；汉字从 0xb0a1 开始，结

束于 0xf7fe；

　　GBK 是 GB2312-80 的扩展，是向上兼容的。它包含了 20902 个汉字，其编码范围是 0x8140-

0xfefe，剔除高位 0x80 的字位。其所有字符都可以一对一映射到 Unicode 2.0，也就是说 JAVA 实际

上提供了 GBK 字符集的支持。这是现阶段 Windows 和其它一些中文操作系统的缺省字符集，但并不是

所有的国际化软件都支持该字符集，感觉是他们并不完全知道 GBK 是怎么回事。值得注意的是它不是

国家标准，而只是规范。随着 GB18030-2000国标的发布，它将在不久的将来完成它的历史使命。

　　GB18030-2000(GBK2K) 在 GBK 的基础上进一步扩展了汉字，增加了藏、蒙等少数民族的字形。

GBK2K 从根本上解决了字位不够，字形不足的问题。它有几个特点：

　　●它并没有确定所有的字形，只是规定了编码范围，留待以后扩充。

　　●编码是变长的，其二字节部分与 GBK 兼容；四字节部分是扩充的字形、字位，其编码范围是首

字节 0x81-0xfe、二字节0x30-0x39、三字节 0x81-0xfe、四字节0x30-0x39。

　　●它的推广是分阶段的，首先要求实现的是能够完全映射到 Unicode 3.0 标准的所有字形。

　　●它是国家标准，是强制性的。

　　现在还没有任何一个操作系统或软件实现了 GBK2K 的支持，这是现阶段和将来汉化的工作内容。

3.JSP/Servlet 汉字编码问题及在 WAS 中的解决办法
　　3.1 常见的 encoding 问题的现象

　　网上常出现的 JSP/Servlet encoding 问题一般都表现在 browser 或应用程序端，如:

　　●浏览器中看到的 Jsp/Servlet 页面中的汉字怎么都成了 ’?’ ?

　　●浏览器中看到的 Servlet 页面中的汉字怎么都成了乱码？

　　●JAVA 应用程序界面中的汉字怎么都成了方块？

　　●Jsp/Servlet 页面无法显示 GBK 汉字。

　　●Jsp/Servlet 不能接收 form 提交的汉字。

　　●JSP/Servlet 数据库读写无法获得正确的内容。

　　隐藏在这些问题后面的是各种错误的字符转换和处理（除第3个外，是因为 Java font 设置错误引

起的）。解决类似的字符 encoding 问题，需要了解 Jsp/Servlet 的运行过程，检查可能出现问题的

各个点。

　　3.2 JSP/Servlet web 编程时的 encoding 问题

　　运行于Java 应用服务器的 JSP/Servlet 为 Browser 提供 HTML 内容，其过程如下图所示：

　　其中有字符编码转换的地方有：

　　a.JSP 编译。Java 应用服务器将根据 JVM 的 file.encoding 值读取 JSP 源文件，并转换为内部

字符编码进行 JSP 编译，生成 JAVA 源文件，根据 file.encoding 值写回文件系统。如果当前系统语

言支持 GBK，那么这时候不会出现 encoding 问题。如果是英文的系统，如 LANG 是 en_US 的 Linux,

AIX 或 Solaris，则要将 JVM 的 file.encoding 值置成 GBK 。系统语言如果是 GB2312，则根据需要

，确定要不要设置 file.encoding，将 file.encoding 设为 GBK 可以解决潜在的 GBK 字符乱码问题

。

　　b.Java 需要被编译为 .class 才能在 JVM 中执行，这个过程存在与a.同样的 file.encoding 问

题。从这里开始 servlet 和 jsp 的运行就类似了，只不过 Servlet 的编译不是自动进行的。

　　c.Servlet 需要将 HTML 页面内容转换为 browser 可接受的 encoding 内容发送出去。依赖于各

JAVA App Server 的实现方式，有的将查询 Browser 的 accept-charset 和 accept-language 参数或

以其它猜的方式确定 encoding 值，有的则不管。因此 constant-encoding 也许是最好的解决方法。

对于中文网页，可在 JSP 或 Servlet 中设置 contentType="text/html; charset=GB2312"；如果页面

中有GBK字符，则设置为contentType="text/html; charset=GBK"，由于IE 和 Netscape对GBK的支持程

度不一样，作这种设置时需要测试一下。

　　因为16位 JAVA char在网络传送时高8位会被丢弃，也为了确保Servlet页面中的汉字（包括内嵌的

和servlet运行过程中得到的）是期望的内码，可以用 PrintWriter out=res.getWriter() 取代

ServletOutputStream out=res.getOutputStream(), PrinterWriter 将根据contentType中指定的

charset作转换(ContentType需在此之前指定！);也可以用OutputStreamWriter封装

ServletOutputStream 类并用write(String)输出汉字字符串。

对于 JSP，JAVA Application Server 应当能够确保在这个阶段将嵌入的汉字正确传送出去。

　　d.这是 URL 字符 encoding 问题。如果通过 get/post 方式从 browser 返回的值中包含汉字信息

， servlet 将无法得到正确的值。SUN的 J2SDK 中，HttpUtils.parseName 在解析参数时根本没有考

虑 browser 的语言设置，而是将得到的值按 byte 方式解析。这是网上讨论得最多的 encoding 问题

。因为这是设计缺陷，只能以 bin 方式重新解析得到的字符串；或者以 hack HttpUtils 类的方式解

决。参考文章 2、3 均有介绍，不过最好将其中的中文 encoding GB2312、 CP1381 都改为 GBK，否则

遇到 GBK 汉字时，还是会有问题。

　　Servlet API 2.3 提供一个新的函数 HttpServeletRequest.setCharacterEncoding 用于在调用

request.getParameter(“param_name”) 前指定应用程序希望的 encoding，这将有助于彻底解决这个

问题。

　　WebSphere Application Server 对标准的 Servlet API 2.x 作了扩展，提供较好的多语言支持。

上述c,d情况，WAS 都要查询 Browser 的语言设置，在缺省状况下zh、zh-cn 等均被映射为 JAVA

encoding CP1381（注意：CP1381 只是等同于 GB2312 的一个 codepage，没有 GBK 支持）。这样做我

想是因为无法确认 Browser 运行的操作系统是支持GB2312, 还是 GBK，所以取其小。但是实际的应用

系统还是要求页面中出现 GBK 汉字，最著名的是朱总理名字中的“?”(rong2 ，0xe946，\u9555)，所

以有时还是需要将 Encoding/Charset 指定为 GBK。当然 WAS 中变更缺省的 encoding 没有上面说的

那么麻烦，针对 a,b，参考文章 5 ），在 Application Server 的命令行参数中指定 -

Dfile.encoding=GBK 即可；针对 d，在 Application Server 的命令行参数中指定-

Ddefault.client.encoding=GBK。如果指定了-Ddefault.client.encoding=GBK，那么c情况下可以不再

指定charset。

　　3.3 数据库读写时的 encoding 问题

　　JSP/Servlet 编程中经常出现 encoding 问题的另一个地方是读写数据库中的数据。

　　流行的关系数据库系统都支持数据库 encoding，也就是说在创建数据库时可以指定它自己的字符

集设置，数据库的数据以指定的编码形式存储。当应用程序访问数据时，在入口和出口处都会有

encoding 转换。对于中文数据，应当保证数据的完整性。GB2312，GBK，UTF-8 等都是可选的数据库

encoding；如果选择 ISO8859-1(8-bit SBCS)，那么应用程序在写数据之前须将 16Bit 的一个汉字或

Unicode 拆分成两个 8-bit 的字符，读数据之后则需将两个字节合并起来，同时还有判别其中的 SBCS

字符。没有充分利用数据库 encoding 的作用，反而增加了编程的复杂度，ISO8859-1不是推荐的数据

库 encoding。JSP/Servlet编程时，可以先用数据库管理系统提供的功能检查其中的中文数据是否正确

。

　　然后应当注意的是读出来的数据的 encoding，JAVA 程序中一般得到的是 Unicode。写数据时则相

反。

　　3.4 定位问题时常用的技巧

　　定位中文encoding问题通常采用最笨的也是最有效的办法——在你认为有嫌疑的程序处理后打印字

符串的内码。通过打印字符串的内码，你可以发现什么时候中文字符被转换成Unicode，什么时候

Unicode被转回中文内码，什么时候一个中文字成了两个 Unicode 字符，什么时候中文字符串被转成了

一串问号，什么时候中文字符串的高位被截掉了……

　　取用合适的样本字符串也有助于区分问题的类型。如：”aa啊aa?aa” 等中英相间、GB、GBK特征

字符均有的字符串。一般来说，英文字符无论怎么转换或处理，都不会失真（如果遇到了，可以尝试着

增加连续的英文字母长度）。

4.结束语
　　其实 JSP/Servlet 的中文encoding 并没有想像的那么复杂，虽然定位和解决问题没有定规，各种

运行环境也各不尽然，但后面的原理是一样的。了解字符集的知识是解决字符问题的基础。不过，随着

中文字符集的变化，不仅仅是 java 编程，中文信息处理中的问题还是会存在一段时间的。

5.参考文章
1) Character Problem Review
2) Java 编程技术中汉字问题的分析及解决
3) NLS Characters in WebSphere: SBCS/DBCS display on same page
4) GB18030
5) Setting language encoding in web applications: Websphere applications Server
作者简介

白露 2008-03-19 15:51 发表评论

Servlet及JSP中的多线程同步问题

白露 — Wed, 19 Mar 2008 07:46:00 GMT

　Servlet/JSP技术和ASP、PHP等相比，由于其多线程运行而具有很高的执行效率。由于Servlet/JSP默认是以多线程模式执行的，所以，在编写代码时需要非常细致地考虑多线程的同步问题。然而，很多人编写Servlet/JSP程序时并没有注意到多线程同步的问题，这往往造成编写的程序在少量用户访问时没有任何问题，而在并发用户上升到一定值时，就会经常出现一些莫明其妙的问题，对于这类随机性的问题调试难度也很大。
　在Servlet/JSP中的几种变量类型

　　在编写Servlet/JSP程序时，对实例变量一定要小心使用。因为实例变量是非线程安全的。在Servlet/JSP中，变量可以归为下面的几类：

　　1. 类变量

　　request，response，session，config，application，以及JSP页面内置的page, pageContext。其中除了application外，其它都是线程安全的。

　　2. 实例变量

　　实例变量是实例所有的，在堆中分配。在Servlet/JSP容器中，一般仅实例化一个Servlet/JSP实例，启动多个该实例的线程来处理请求。而实例变量是该实例所有的线程所共享，所以，实例变量不是线程安全的。

　　3. 局部变量

　　局部变量在堆栈中分配，因为每一个线程有自己的执行堆栈，所以，局部变量是线程安全的。

文章引用自：

白露 2008-03-19 15:46 发表评论

JSP/Servlet 中的汉字编码问题

白露 — Wed, 19 Mar 2008 07:45:00 GMT

网上就 JSP/Servlet 中 DBCS字符编码问题有许多优秀的文章和讨论，本文对它们作一些整理，并结合IBM WebSphere Application Server3.5（WAS）的解决方法作一些说明，希望它不是多余的。
问题的起源
每个国家（或区域）都规定了计算机信息交换用的字符编码集，如美国的扩展 ASCII码, 中国的 GB2312-80，日本的 JIS 等，作为该国家/区域内信息处理的基础，有着统一编码的重要作用。字符编码集按长度分为 SBCS（单字节字符集），DBCS（双字节字符集）两大类。早期的软件（尤其是操作系统），为了解决本地字符信息的计算机处理，出现了各种本地化版本（L10N），为了区分，引进了 LANG, Codepage 等概念。但是由于各个本地字符集代码范围重叠，相互间信息交换困难；软件各个本地化版本独立维护成本较高。因此有必要将本地化工作中的共性抽取出来，作一致处理，将特别的本地化处理内容降低到最少。这也就是所谓的国际化（I18N）。各种语言信息被进一步规范为 Locale 信息。处理的底层字符集变成了几乎包含了所有字形的 Unicode。

现在大部分具有国际化特征的软件核心字符处理都是以 Unicode 为基础的，在软件运行时根据当时的 Locale/Lang/Codepage 设置确定相应的本地字符编码设置，并依此处理本地字符。在处理过程中需要实现 Unicode 和本地字符集的相互转换，甚或以 Unicode 为中间的两个不同本地字符集的相互转换。这种方式在网络环境下被进一步延伸，任何网络两端的字符信息也需要根据字符集的设置转换成可接受的内容。

Java 语言内部是用 Unicode 表示字符的，遵守 Unicode V2.0。Java 程序无论是从/往文件系统以字符流读/写文件，还是往 URL 连接写 HTML 信息，或从 URL 连接读取参数值，都会有字符编码的转换。这样做虽然增加了编程的复杂度，容易引起混淆，但却是符合国际化的思想的。

从理论上来说，这些根据字符集设置而进行的字符转换不应该产生太多问题。而事实是由于应用程序的实际运行环境不同，Unicode 和各个本地字符集的补充、完善，以及系统或应用程序实现的不规范，转码时出现的问题时时困扰着程序员和用户。

GB2312-80，GBK，GB18030-2000 汉字字符集及 Encoding
其实解决 JAVA 程序中的汉字编码问题的方法往往很简单，但理解其背后的原因，定位问题，还需要了解现有的汉字编码和编码转换。

GB2312-80 是在国内计算机汉字信息技术发展初始阶段制定的，其中包含了大部分常用的一、二级汉字，和 9 区的符号。该字符集是几乎所有的中文系统和国际化的软件都支持的中文字符集，这也是最基本的中文字符集。其编码范围是高位0xa1－0xfe，低位也是 0xa1-0xfe；汉字从 0xb0a1 开始，结束于 0xf7fe；

GBK 是 GB2312-80 的扩展，是向上兼容的。它包含了 20902 个汉字，其编码范围是 0x8140-0xfefe，剔除高位 0x80 的字位。其所有字符都可以一对一映射到 Unicode 2.0，也就是说 JAVA 实际上提供了 GBK 字符集的支持。这是现阶段 Windows 和其它一些中文操作系统的缺省字符集，但并不是所有的国际化软件都支持该字符集，感觉是他们并不完全知道 GBK 是怎么回事。值得注意的是它不是国家标准，而只是规范。随着 GB18030-2000国标的发布，它将在不久的将来完成它的历史使命。

GB18030-2000(GBK2K) 在 GBK 的基础上进一步扩展了汉字，增加了藏、蒙等少数民族的字形。GBK2K 从根本上解决了字位不够，字形不足的问题。它有几个特点，

它并没有确定所有的字形，只是规定了编码范围，留待以后扩充。
编码是变长的，其二字节部分与 GBK 兼容；四字节部分是扩充的字形、字位，其编码范围是首字节 0x81-0xfe、二字节0x30-0x39、三字节 0x81-0xfe、四字节0x30-0x39。
它的推广是分阶段的，首先要求实现的是能够完全映射到 Unicode 3.0 标准的所有字形。
它是国家标准，是强制性的。
现在还没有任何一个操作系统或软件实现了 GBK2K 的支持，这是现阶段和将来汉化的工作内容。

Unicode 的介绍......就免了吧。

JAVA 支持的encoding中与中文编程相关的有：(有几个在JDK文档中未列出)

ASCII 7-bit, 同 ascii7
ISO8859-1 8-bit, 同 8859_1,ISO-8859-1,ISO_8859-1,latin1...
GB2312-80 同gb2312,gb2312-1980,EUC_CN,euccn,1381,Cp1381, 1383, Cp1383, ISO2022CN,ISO2022CN_GB......
GBK (注意大小写),同MS936
UTF8 UTF-8
GB18030 (现在只有IBM JDK1.3.?有支持), 同Cp1392,1392

JAVA 语言采用Unicode处理字符. 但从另一个角度来说，在java程序中也可以采用非Unicode的转码，重要的是保证程序入口和出口的汉字信息不失真。如完全采用ISO-8859-1来处理汉字也能达到正确的结果。网络上流行的许多解决方法，都属于这种类型。为了不致引起混淆，本文不对这种方法作讨论。

中文转码时'?'、乱码的由来
两个方向转换都有可能得到错误的结果：

Unicode-->Byte, 如果目标代码集不存在对应的代码，则得到的结果是0x3f.
如：
"u00d6u00ecu00e9u0046u00bbu00f9".getBytes("GBK") 的结果是 "?ìéF?ù", Hex 值是3fa8aca8a6463fa8b4.

仔细看一下上面的结果，你会发现u00ec被转换为0xa8ac, u00e9被转换为xa8a6... 它的实际有效位变长了！这是因为GB2312符号区中的一些符号被映射到一些公共的符号编码，由于这些符号出现在ISO-8859-1或其它一些SBCS字符集中，故它们在Unicode中编码比较靠前，有一些其有效位只有8位，和汉字的编码重叠(其实这种映射只是编码的映射，在显示时仔细不是一样的。Unicode 中的符号是单字节宽，汉字中的符号是双字节宽) . 在Unicodeu00a0--u00ff 之间这样的符号有20个。了解这个特征非常重要！由此就不难理解为什么JAVA编程中，汉字编码的错误结果中常常会出现一些乱码(其实是符号字符), 而不全是'?'字符, 就比如上面的例子。

Byte-->Unicode, 如果Byte标识的字符在源代码集不存在，则得到的结果是0xfffd.
如：
Byte ba[] = {(byte)0x81,(byte)0x40,(byte)0xb0,(byte)0xa1}; new String(ba,"gb2312");

结果是"?啊", hex 值是"ufffdu554a". 0x8140 是GBK字符，按GB2312转换表没有对应的值，取ufffd. (请注意：在显示该uniCode时，因为没有对应的本地字符，所以也适用上一种情况，显示为一个"?".)

实际编程中，JSP/Servlet 程序得到错误的汉字信息，往往是这两个过程的叠加，有时甚至是两个过程叠加后反复作用的结果.

JSP/Servlet 汉字编码问题及在 WAS 中的解决办法

4.1 常见的 encoding 问题的现象
网上常出现的 JSP/Servlet encoding 问题一般都表现在 browser 或应用程序端，如:

浏览器中看到的 Jsp/Servlet 页面中的汉字怎么都成了 ’?’ ?
浏览器中看到的 Servlet 页面中的汉字怎么都成了乱码？
JAVA 应用程序界面中的汉字怎么都成了方块？
Jsp/Servlet 页面无法显示 GBK 汉字。
JSP 页面中内嵌在<%...%>,<%=...%>等Tag包含的 JAVA code 中的中文成了乱码，但页面的其它汉字是对的。
Jsp/Servlet 不能接收 form 提交的汉字。
JSP/Servlet 数据库读写无法获得正确的内容。
隐藏在这些问题后面的是各种错误的字符转换和处理（除第3个外，是因为 Java font 设置错误引起的）。解决类似的字符 encoding 问题，需要了解 Jsp/Servlet 的运行过程，检查可能出现问题的各个点。

4.2 JSP/Servlet web 编程时的 encoding 问题
运行于Java 应用服务器的 JSP/Servlet 为 Browser 提供 HTML 内容，其过程如下图所示：

其中有字符编码转换的地方有:

JSP 编译。Java 应用服务器将根据 JVM 的 file.encoding 值读取 JSP 源文件，编译生成 JAVA 源文件，再根据 file.encoding 值写回文件系统。如果当前系统语言支持 GBK，那么这时候不会出现 encoding 问题。如果是英文的系统，如 LANG 是 en_US 的 Linux, AIX 或 Solaris，则要将 JVM 的 file.encoding 值置成 GBK 。系统语言如果是 GB2312，则根据需要，确定要不要设置 file.encoding，将 file.encoding 设为 GBK 可以解决潜在的 GBK 字符乱码问题

Java 需要被编译为 .class 才能在 JVM 中执行，这个过程存在与a.同样的 file.encoding 问题。从这里开始 servlet 和 jsp 的运行就类似了，只不过 Servlet 的编译不是自动进行的。对于JSP程序, 对产生的JAVA 中间文件的编译是自动进行的(在程序中直接调用sun.tools.javac.Main类). 因此如果在这一步出现问题的话, 也要检查encoding和OS的语言环境，或者将内嵌在JSP JAVA Code 中的静态汉字转为 Unicode, 要么静态文本输出不要放在 JAVA code 中。对于Servlet, javac 编译时手工指定-encoding 参数就可以了。

Servlet 需要将 HTML 页面内容转换为 browser 可接受的 encoding 内容发送出去。依赖于各 JAVA App Server 的实现方式，有的将查询 Browser 的 accept-charset 和 accept-language 参数或以其它猜的方式确定 encoding 值，有的则不管。因此采用固定encoding 也许是最好的解决方法。对于中文网页，可在 JSP 或 Servlet 中设置 contentType="text/html; charset=GB2312"；如果页面中有GBK字符，则设置为contentType="text/html; charset=GBK"，由于IE 和 Netscape对GBK的支持程度不一样，作这种设置时需要测试一下。因为16位 JAVA char在网络传送时高8位会被丢弃，也为了确保Servlet页面中的汉字（包括内嵌的和servlet运行过程中得到的）是期望的内码，可以用 PrintWriter out=res.getWriter() 取代 ServletOutputStream out=res.getOutputStream(). PrinterWriter 将根据contentType中指定的charset作转换 (ContentType需在此之前指定！); 也可以用OutputStreamWriter封装 ServletOutputStream 类并用write(String)输出汉字字符串。对于 JSP，JAVA Application Server 应当能够确保在这个阶段将嵌入的汉字正确传送出去。

这是解释 URL 字符 encoding 问题。如果通过 get/post 方式从 browser 返回的参数值中包含汉字信息， servlet 将无法得到正确的值。SUN的 J2SDK 中，HttpUtils.parseName 在解析参数时根本没有考虑 browser 的语言设置，而是将得到的值按 byte 方式解析。这是网上讨论得最多的 encoding 问题。因为这是设计缺陷，只能以 bin 方式重新解析得到的字符串；或者以 hack HttpUtils 类的方式解决。参考文章 2 均有介绍，不过最好将其中的中文 encoding GB2312、 CP1381 都改为 GBK，否则遇到 GBK 汉字时，还是会有问题。 Servlet API 2.3 提供一个新的函数 HttpServeletRequest.setCharacterEncoding 用于在调用 request.getParameter(“param_name”) 前指定应用程序希望的 encoding，这将有助于彻底解决这个问题。

4.3 IBM Websphere Application Server 中的解决方法
WebSphere Application Server 对标准的 Servlet API 2.x 作了扩展，提供较好的多语言支持。运行在中文的操作系统中，可以不作任何设置就可以很好地处理汉字。下面的说明只是对WAS是运行在英文的系统中，或者需要有GBK支持时有效。

上述c,d情况，WAS 都要查询 Browser 的语言设置，在缺省状况下， zh, zh-cn 等均被映射为 JAVA encoding CP1381（注意： CP1381 只是等同于 GB2312 的一个 codepage，没有 GBK 支持）。这样做我想是因为无法确认 Browser 运行的操作系统是支持GB2312, 还是 GBK，所以取其小。但是实际的应用系统还是要求页面中出现 GBK 汉字，最著名的是朱总理名字中的“�F"(rong2 ，0xe946，u9555)，所以有时还是需要将 Encoding/Charset 指定为 GBK。当然 WAS 中变更缺省的 encoding 没有上面说的那么麻烦，针对 a,b，参考文章 5，在 Application Server 的命令行参数中指定 -Dfile.encoding=GBK 即可；针对 d，在 Application Server 的命令行参数中指定-Ddefault.client.encoding=GBK。如果指定了-Ddefault.client.encoding=GBK，那么c情况下可以不再指定charset。

上面列出的问题中还有一个关于Tag<%...%>,<%=...%>中的 JAVA 代码里包含的静态文本未能正确显示的问题，在WAS中的解决方法是除了设置正确的file.encoding, 还需要以相同方法设置-Duser.language=zh -Duser.region=CN。这与JAVA locale的设置有关。

4.4 数据库读写时的 encoding 问题
JSP/Servlet 编程中经常出现 encoding 问题的另一个地方是读写数据库中的数据。

流行的关系数据库系统都支持数据库 encoding，也就是说在创建数据库时可以指定它自己的字符集设置，数据库的数据以指定的编码形式存储。当应用程序访问数据时，在入口和出口处都会有 encoding 转换。对于中文数据，数据库字符编码的设置应当保证数据的完整性. GB2312，GBK，UTF-8 等都是可选的数据库 encoding；也可以选择 ISO8859-1 (8-bit)，那么应用程序在写数据之前须将 16Bit 的一个汉字或 Unicode 拆分成两个 8-bit 的字符，读数据之后则需将两个字节合并起来，同时还要判别其中的 SBCS 字符。没有充分利用数据库 encoding 的作用，反而增加了编程的复杂度，ISO8859-1不是推荐的数据库 encoding。JSP/Servlet编程时，可以先用数据库管理系统提供的管理功能检查其中的中文数据是否正确。

然后应当注意的是读出来的数据的 encoding，JAVA 程序中一般得到的是 Unicode。写数据时则相反。

4.5 定位问题时常用的技巧
定位中文encoding问题通常采用最笨的也是最有效的办法??在你认为有嫌疑的程序处理后打印字符串的内码。通过打印字符串的内码，你可以发现什么时候中文字符被转换成Unicode，什么时候Unicode被转回中文内码，什么时候一个中文字成了两个 Unicode 字符，什么时候中文字符串被转成了一串问号，什么时候中文字符串的高位被截掉了……

取用合适的样本字符串也有助于区分问题的类型。如：”aa啊aa�@aa” 等中英相间、GB、GBK特征字符均有的字符串。一般来说，英文字符无论怎么转换或处理，都不会失真（如果遇到了，可以尝试着增加连续的英文字母长度）。

结束语
其实 JSP/Servlet 的中文encoding 并没有想像的那么复杂，虽然定位和解决问题没有定规，各种运行环境也各不尽然，但后面的原理是一样的。了解字符集的知识是解决字符问题的基础。不过，随着中文字符集的变化，不仅仅是 java 编程，中文信息处理中的问题还是会存在一段时间的。

参考资料

Character Problem Review

Java 编程技术中汉字问题的分析及解决

GB18030

白露 2008-03-19 15:45 发表评论

Tomcat 5.0.x中使用 include file的中文乱码问题

白露 — Wed, 19 Mar 2008 07:43:00 GMT

在jsp中，包含其他页面的格式如下：
<%@include file="文件名"%>

例如：
<%@include file="header.jsp"%>

在jsp中，指定页面编码方式的格式为：
<%@page language="java" contentType="<编码方式>" %>

例如：
<%@page language="java" contentType="text/html; charset=GBK" %>

<%@page contentType="text/html; charset=gb2312"%>

在tomcat 4中，被include的页面文件中不需要也不能指定页面编码方式。但在tomcat 5.0.x中，被include的文件需要指定编码方式，否则可能出现乱码。
即：主页面文件和被包含页面文件中，都需要加入：
<%@page language="java" contentType="text/html; charset=GB2312" %>

这样的页面，使用Jbuilder 7编译是不能通过的。

为了让tomcat 5.0.x能象tomcat 4那样处理include页面，保证JBuidler的正常编译，需要修改项目WEB-INFO/web.xml文件，进行如下配置把默认的字符集设置成GBK或GB2312就可以了，代码如下：

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd"
version="2.4">

Special property group for JSP Configuration JSP example.

JSPConfiguration

*.jsp

true

GBK

false

Special property group for JSP Configuration JSP example.

JSPConfiguration

*.html

true

GBK

false

白露 2008-03-19 15:43 发表评论

web.xml配置详解

白露 — Wed, 19 Mar 2008 07:41:00 GMT

web.xml配置详解（2)

7 指定欢迎页

假如用户提供了一个像http: //host/webAppPrefix/directoryName/ 这样的包含一个目录名但没有包含文件名的URL，会发生什么事情呢？用户能得到一个目录表？一个错误？还是标准文件的内容？如果得到标准文件内容，是 index.html、index.jsp、default.html、default.htm或别的什么东西呢？
Welcome-file-list 元素及其辅助的welcome-file元素解决了这个模糊的问题。例如，下面的web.xml项指出，如果一个URL给出一个目录名但未给出文件名，服务器应该首先试用index.jsp，然后再试用index.html。如果两者都没有找到，则结果有赖于所用的服务器（如一个目录列表）。

index.jsp

index.html

虽然许多服务器缺省遵循这种行为，但不一定必须这样。因此，明确地使用welcom-file-list保证可移植性是一种良好的习惯。

8 指定处理错误的页面

现在我了解到，你在开发servlet和JSP页面时从不会犯错误，而且你的所有页面是那样的清晰，一般的程序员都不会被它们的搞糊涂。但是，是人总会犯错误的，用户可能会提供不合规定的参数，使用不正确的URL或者不能提供必需的表单字段值。除此之外，其它开发人员可能不那么细心，他们应该有些工具来克服自己的不足。
error-page元素就是用来克服这些问题的。它有两个可能的子元素，分别是：error-code和exception- type。第一个子元素error-code指出在给定的HTTP错误代码出现时使用的URL。第二个子元素excpetion-type指出在出现某个给定的Java异常但未捕捉到时使用的URL。error-code和exception-type都利用location元素指出相应的URL。此 URL必须以/开始。location所指出的位置处的页面可通过查找HttpServletRequest对象的两个专门的属性来访问关于错误的信息，这两个属性分别是：javax.servlet.error.status_code和javax.servlet.error.message。
可回忆一下，在web.xml内以正确的次序声明web-app的子元素很重要。这里只要记住，error-page出现在web.xml文件的末尾附近，servlet、servlet-name和welcome-file-list之后即可。

8.1 error-code元素
为了更好地了解error-code元素的值，可考虑一下如果不正确地输入文件名，大多数站点会作出什么反映。这样做一般会出现一个404错误信息，它表示不能找到该文件，但几乎没提供更多有用的信息。另一方面，可以试一下在www.microsoft.com、www.ibm.com 处或者特别是在www.bea.com 处输出未知的文件名。这是会得出有用的消息，这些消息提供可选择的位置，以便查找感兴趣的页面。提供这样有用的错误页面对于Web应用来说是很有价值得。事实上rm-error-page子元素）。由form-login-page给出的HTML表单必须具有一个j_security_check的 ACTION属性、一个名为j_username的用户名文本字段以及一个名为j_password的口令字段。
例如，程序清单5-19指示服务器使用基于表单的验证。Web应用的顶层目录中的一个名为login.jsp的页面将收集用户名和口令，并且失败的登陆将由相同目录中名为login-error.jsp的页面报告。

程序清单5-19 web.xml（说明login-config的摘录）

PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN"
"http://java.sun.com/dtd/web-app_2_3.dtd">

...

FORM

/login.jsp

/login-error.jsp

9.2 限制对Web资源的访问
现在，可以指示服务器使用何种验证方法了。"了不起，"你说道，"除非我能指定一个来收到保护的 URL，否则没有多大用处。"没错。指出这些URL并说明他们应该得到何种保护正是security-constriaint元素的用途。此元素在 web.xml中应该出现在login-config的紧前面。它包含是个可能的子元素，分别是：web-resource-collection、 auth-constraint、user-data-constraint和display-name。下面各小节对它们进行介绍。
l web-resource-collection
此元素确定应该保护的资源。所有security-constraint元素都必须包含至少一个web-resource-collection项。此元素由一个给出任意标识名称的web-resource-name元素、一个确定应该保护的URL的url-pattern元素、一个指出此保护所适用的 HTTP命令（GET、POST等，缺省为所有方法）的http-method元素和一个提供资料的可选description元素组成。例如，下面的 Web-resource-collection项（在security-constratint元素内）指出Web应用的proprietary目录中所有文档应该受到保护。

Proprietary

/propritary

public class ContextReporter implements ServletContextListener {
public void contextInitialized(ServletContextEvent event) {
System.out.println("Context created on " +
new Date() + ".");
}

public void contextDestroyed(ServletContextEvent event) {
System.out.println("Context destroyed on " +
new Date() + ".");
}
}

程序清单5-21 web.xml（声明一个监听程序的摘录）

PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN"
"

http://java.sun.com/dtd/web-app_2_3.dtd">

…

package.ListenerClass

...

15 J2EE元素

本节描述用作J2EE环境组成部分的Web应用的web.xml元素。这里将提供一个简明的介绍，详细内容可以参阅http://java.sun.com/j2ee/j2ee-1_3-fr-spec.pdf的Java 2 Plantform Enterprise Edition版本1.3规范的第5章。
l distributable
distributable 元素指出，Web应用是以这样的方式编程的：即，支持集群的服务器可安全地在多个服务器上分布Web应用。例如，一个可分布的应用必须只使用 Serializable对象作为其HttpSession对象的属性，而且必须避免用实例变量（字段）来实现持续性。distributable元素直接出现在discription元素之后，并且不包含子元素或数据，它只是一个如下的标志。

l resource-env-ref
resource -env-ref元素声明一个与某个资源有关的管理对象。此元素由一个可选的description元素、一个resource-env-ref- name元素（一个相对于java:comp/env环境的JNDI名）以及一个resource-env-type元素（指定资源类型的完全限定的类），如下所示：

jms/StockQueue

javax.jms.Queue

l env-entry
env -entry元素声明Web应用的环境项。它由一个可选的description元素、一个env-entry-name元素（一个相对于java: comp/env环境JNDI名）、一个env-entry-value元素（项值）以及一个env-entry-type元素（java.lang程序包中一个类型的完全限定类名，java.lang.Boolean、java.lang.String等）组成。下面是一个例子：

minAmout

100.00

minAmout

l ejb-ref
ejb -ref元素声明对一个EJB的主目录的应用。它由一个可选的description元素、一个ejb-ref-name元素（相对于java: comp/env的EJB应用）、一个ejb-ref-type元素（bean的类型，Entity或Session）、一个home元素（bean的主目录接口的完全限定名）、一个remote元素（bean的远程接口的完全限定名）以及一个可选的ejb-link元素（当前bean链接的另一个 bean的名称）组成。
l ejb-local-ref
ejb-local-ref元素声明一个EJB的本地主目录的引用。除了用local-home代替home外，此元素具有与ejb-ref元素相同的属性并以相同的方式使用。

给你的session加个监听器

有人问我怎么实现在网页里显示在线用户的名称——他已经使用了session，但是无法处理用户离开的情况，然后导致在线用户列表的无限增大。跟他说了自己在application中进行超时检查，更新application的时候就比较当前所有列表中的session是否超过自己指定的时间间隔。后来想了想，又给他提了使用给session加监听器的方法。但是提的时候自己也没有做过，所以只是说这种方式很复杂，建议他还是自己进行超时检查。刚才又看了看资料，发现实际上给session加监听器的方式很简单，不禁觉得自己有点误人子弟了，现在将方法写在这，借以告诫自己以后要严谨。
首先写一个SessionBinder类,它实现了HttpSessionBindingListener接口的valueBound方法和valueUnbound方法，示例代码如下：
public class SessionBinder implements HttpSessionBindingListener {
public void valueBound(HttpSessionBindingEvent event){
//you can do anything you want!this method will be called when this binder is bind with any session.
}

public void valueUnbound(HttpSessionBindingEvent event) {
//you can do something while this session is invalidate
}
}
现在写好了SessionBinder，我们现在选择在一个servlet中向session中加入这个监听器——在jsp中的代码书写与此相同
//省略前面的代码，此操作可能发生在servlet的doGet方法中，也可能是doPost方法中
HttpSession session = req.getSession(true);//首先获得需要加入监听器的session对象，req是HttpRequest对象
SessionBinder sb = new SessionBinder();//建立一个监听器对象
session.putValue("BinderObject",sb);//将监听器加入此session中，从此时开始执行sb的valueBound方法
//省略后面的代码
随后，如果整个session超时或者被用户中止之后，sb的valueUnbound自动执行
呵呵，以上代码以供参考

白露 2008-03-19 15:41 发表评论

tomcat6 + oracle9i 的数据源配置

白露 — Wed, 19 Mar 2008 07:38:00 GMT

tomcat6 + oracle9i 的数据源配置

很少写技术文章，但网上关于tomcat6.x的数据源配置没有一个让我满意的答案，希望能对别人有所帮助，另外也算是对我忙活这一晚上的纪念。

网上搜出来的文章很多是tomcat5.x及以前的方法，比如更改conf/server.xml。还有，从tomcat6开始，安装包里已经没有admin控制台了，比如输入http://localhost:8080/admin 显示的网页会提示你需要另外安装admin包。官方网站上能找到的admin只有5.x版本的，我参照一篇文章的做法安装并配置后，仍然是不行，显示的是空白网页，所以没有办法用图形界面的方法配置数据源了。

其实最权威的方法无疑是官方的，我按照官方网页上的指示进行配置，一次就成功了，而且很简单。另外需要说明的是，以下方法对于Oracle8i和10g同样适用。

下面是配置的具体步骤：

1、将ora92\jdbc\lib中的classes12.jar拷贝到Tomcat 6.0\lib中，注意一定要是jar文件而不能是zip

2、将下面这段代码加到Tomcat 6.0\conf\context.xml中

               type="javax.sql.DataSource" driverClassName="oracle.jdbc.OracleDriver"
               url="jdbc:oracle:thin:@127.0.0.1:1521:mydb"
               username="name" password="psw" maxActive="20" maxIdle="10"
               maxWait="-1" removeAbandoned="true" removeAbandonedTimeout="60"
               logAbandoned="true"/>

其中最后三项是优化用的，可以不写。"jdbc/myoracle"是数据源名称，可变。从9i以后，driverClassName推荐使用"oracle.jdbc.OracleDriver"而不是"oracle.jdbc.driver.OracleDriver",因为后者将会在Oracle以后的版本中淘汰。thin是Oracle提供的两种JDBC驱动程序的一种，另一种是oci。一般来说远程访问数据库用thin，服务器端开发的数据库连接用oci，这里用thin就是了。mydb是数据库名，name和psw是登陆数据库的帐号和密码。

3、在建立的一个web project中，在Tomcat 6.0\webapps\ProjectName\WEB-INF\web.xml中添加

Oracle Datasource example

jdbc/myoracle

javax.sql.DataSource

Container

4、配置就完成了，下面用一个jsp文件进行测试：

<%@ page contentType="text/html; charset=gb2312" %>
<%@ page import="javax.naming.*" %>
<%@ page import="javax.sql.*" %>
<%@ page import="java.sql.*" %>
Oracle JDBC Test

<%
Connection conn=null;
Statement stmt=null;
ResultSet rs=null;
try{
Context initCtx = new InitialContext();
Context envCtx = (Context)initCtx.lookup("java:comp/env");
DataSource ds=(DataSource)envCtx.lookup("jdbc/myoracle");
if(ds!=null){
  out.println("Get DataSource！");
  out.println(ds.toString());
  conn=ds.getConnection();
  if(conn!=null){
   out.println("Create connection !");
   stmt=conn.createStatement();
   out.println("Create Statement !");
   rs=stmt.executeQuery("select * from person");
   while(rs.next()){
        out.println(rs.getString("name"));
   }
   out.println("");
   rs.close();
   stmt.close();
   conn.close();
  }
}
}catch(Exception e){
out.println(e.toString());
System.out.println(e.toString());
}
%>

person是一个表，name是一列名。

白露 2008-03-19 15:38 发表评论

新一代Java技术即将出现

白露 — Wed, 19 Mar 2008 07:36:00 GMT

　　近来Java技术的进化相当显著。Java技术正在迎来“又一次革命”的风暴

　　Java技术自问世时光已经过去了9个年头。作为一名一直关注其成长的记者，曾经一段时间有过这样的想法：“Java技术已经成熟，是不是发展速度该放慢一些了呢”。然而，这种想法错了。近来Java技术的进化相当显著。Java技术正在迎来“又一次革命”的风暴。这就是本文的结论。

　　“又一次”指的是什么？“革命”指的又是什么？光看结论的话肯定是一头雾水。其实，笔者要讲的并不是变化这样一个事实，而是“促进变化的原动力”。是什么让Java技术发生变化？让我们从这一角度出发，先看一下Java的变化历程。

　　Java正处于转变期

　　回顾Java技术的发展历程，人们一定会感慨：2004年到2005年发生的变化如此之大，可以说“现在”正是Java技术的转换期。 Java技术由编程语言（Java语言）、运行环境（JVM：Java虚拟机）、框架（Java API群）组成，目前在每一个层面上都发生着巨大的变化。

　　（1）编程语言的变化

　　Java语言标准出现明显变化。在2004年9月发布的正式版本J2SE5.0（J2SE:Java2 Standard, Standard Edition，Java技术的核心运行环境）中，对Java语言标准中的Generics与元数据进行了大幅扩展。出现了被认为是“自Java问世以来的最大一次语言标准变化”（美国Sun Microsystems）。这次语言标准的变化给许多Java API带来了影响。许多企业API的新版本都引入了基于元数据的注解（程序中记录的附加信息），以较短的编码记述更多的信息。

　　（2）Java运行环境的变化

　　在J2SE5.0中，大幅度强化了JVM的管理功能与实用性，换句话说就是具备了Java执行OS（操作系统）的特征。例如，原来在J2EE （Java2 Platform, Enterprise Edition，构筑企业系统的Java技术）领域，标准配备有作为管理功能的应用软件管理框架JMX。不仅如此，还配备有JVM自身监控功能（（JSR 174: Monitoring and Management Specification for the Java Virtual Machine）。在标准功能架构中可以实时监视JVM运行时的状态，也就是内存使用量、线程状态等。

　　J2SE5.0中新追加的功能中包括并行处理实用程序（JSR 166），其基础是纽约州立大学Doug Lea提供的程序库。也就是说，标准规格中采用了来自民间的程序库。

　　（3）框架的变化

　　服务器端的Java框架也发生了巨大变化。企业级Java技术--J2EE的“使用方法”说明文件“J2EE Blueprint”中，提出了将应用软件分为Web层、EJB层（Enterprise JavaBeans，将包括事务处理在内的业务进程模块化的框架）来构筑的思路。这两种层次都迎来了架构更替时期。Web层的新框架为JSF （JavaServer Faces，将模块组合起来构筑Web应用程序的框架），EJB层为标准方案中刚刚公布的下一代EJB规格“EJB3.0”。

　　值得注意的是，促成框架发生变化的正是来自民间的源码开放软件。

　　对JSF产生影响的是作为源码开放的Web层框架得到普及的Apache Struts。JSF是对Struts的思路进行改进的产物，JSF的Spec Lead（规格制定领袖）之一Craig R. McClanahan就是Struts的作者。

　　对EJB3.0造成影响的也是民间源码开放软件。EJB3.0引入了DI（Dependency Injection，依赖注入）容器类（Container）与POJO（Plain Old Java Object）持久类这些新功能，大大减轻了编程的复杂性。这些概念因PicoContainer、Spring等源码开放软件的导入而引人注目。

　　其背景在于用户对“目前的EJB过于复杂”的批评。原本由EJB反对派提出的设计思想与源码开放软件，却变成了EJB3.0的中心概念，显出了巨大的影响力。

　　（4）脚本语言

　　在Java技术标准中新增加了编程语言Groovy（JSR 241）。这是一种可与Java语言无缝连接的脚本语言，有望以极短的程序完成相关处理。“在Java技术中添加Java以外的语言”，这听起来也许有些别扭，其实以前就有这样的呼声，希望将可以充分利用Java技术资源的脚本作为语言使用。Groovy本来是源码开放软件，最终得到认可，被采纳为标准规格。

　　由上述可以看出，Java技术的构成要素正在发生巨大变化。就在不久以前，一提起服务器Java，“Servlet、JSP、EJB是重要的 API”这样的说明还占主流，但现在基于JSF和EJB3.0的应用程序已经变成了“面目全非”的程序。而在运行短程序或测试时，甚至还出现了不仅是 Java语言，连脚本语言都开始调用Java框架的情况。

　　这些变化从大的方面来看的话，可以说是进一步发挥了Java面向对象的优势。当然，也包括提高开发效率、提高运行稳定性、简化运行管理等业务上的优势。

　　开发者团体是真正的“变革推动者”

　　那么，这些变化的原动力来自哪里呢？为什么说“目前”正面临着“又一次变革”呢？理由如下：

　　在Java技术的发展过程中，1999年到2000年是一个大的转折点。J2EE概念于1999年出现。日本国内的J2EE也在随后2～3年内得到正式普及，但这一技术体系早在5年前就已经确立。在我们眼前，新一代Java技术的轮廓正逐渐显现出来。

　　JCP（Java Community Process）2.0于2000年问世。以会员制的组织形式推进Java技术的规格制订、总体发展方向则以委员会的方式决定。从而形成了不依赖特定企业的规格制订流程。这一组织形式历经近5年的时间，逐渐发展成“变革的推动者”。

　　J2EE此前一直饱受批评，认为“Web层与EJB层的差距太大”、“EJB过于复杂”，但这也是因为这是一项实际使用的技术。JCP同样也遇到很多批评，称其“没有完全公开”、“制定的技术标准却不可思议地让Sun拥有知识产权”，但JCP却作为一个团体不断发展壮大。

　　直接推动Java技术变化的当事者为5年前形成的基于团体的标准制订流程--JCP，但真正将讨论与技术纳入JCP的却是包括Java技术批评者在内的众多Java开发者团体。他们也是早期开展Java技术变革的先行者。由此诞生的下一代技术将会在2～3年后逐渐波及主流企业用户。

　　Java技术的“变革推动者”为开发者团体。不受制于特定企业，通过众多需要Java的开发者的建议，Java技术正在不断发展进步。

白露 2008-03-19 15:36 发表评论