[此文是转载]

最近看到好多关于MySql支持utf-8编码的问题，刚好自己也要用，去找了一下，没有写的很全面的。
整理了一下，供大家参考。

在一下服务器设置测试通过
服务器配置：
    window2000
    Tomcat 4.1,5.19
    Mysql 4.1, 5.0
    Java语言，JDK1.4.2
    数据库驱动mysql-connector-java-3.0.10-stable-bin.jar
    Struts1.1
   
开始前先看提示
MySQL数据库的4.1是一个分水岭，4.1直接支持Unicode，以下版本支持的不好；

MySQL JDBC Driver的3.0.16也是一个分水岭，3.0.16版本会取数据库本身的编码，然后按照该编码转换，这种方式和Oracle的JDBC Driver是一样的。例如你的数据库是GBK编码的话，JDBC Driver就会把数据库里面的取出来的字符串按照GBK往unicode转换，送给JVM。因此正确的设置数据库本身的编码就尤为重要。

MySQL JDBC Driver3.0.16以下的版本则不然，它不会那么智能的根据数据库编码来确定如何转换，它总是默认使用ISO8859-1，因此你必须使用 characterEncoding=GBK来强制他把数据库中取出来的字符串按照GBK来往unicode转换。

因此，使用什么数据库版本，不管是3.x，还是4.0.x还是4.1.x，其实对我们来说不重要，重要的有二：

1) 正确的设定数据库编码，MySQL4.0以下版本的字符集总是默认ISO8859-1，MySQL4.1在安装的时候会让你选择。如果你准备使用UTF- 8，那么在创建数据库的时候就要指定好UTF-8(创建好以后也可以改，4.1以上版本还可以单独指定表的字符集)

2) 使用3.0.16以上版本的JDBC Driver，那么你就不需要再写什么characterEncoding=UTF-8

开始设置：
1.打开WinMysqlAdmin管理器，选择my.ini设置项，在[mysql]段加入一下代码
  default-character-set=utf8
  设置后重新启动MySQL服务。
  再打开 WinMysqlAdmin管理器，选择Variables项，查看一下变量的值是否如下
  character_set_server  = utf8
  character_set_system  = utf8
  character_set_database  = utf8
  character_set_client  = utf8
  character_set_connection  = utf8
  character_set_results = utf8
 
  collation_connection = utf8_general_ci
  collation_database = utf8_general_ci
  collation_server = utf8_general_ci
 
  如果不能重启Mysql服务，则可能拼写错误，检查一下
  以上变量的值都符合，恭喜你，设置成功

2.Java中调用数据库连接方法如下
  jdbc:mysql://192.168.1.87/mytest?useUnicode=true&characterEncoding=utf8
 
  如果驱动使用3.0.16以上版本的JDBC Driver，那么你就不需要再写什么characterEncoding=UTF-8
 
3.在页面提交数据处理请看 "中文问题"，"struts国际化问题"——终极解决方案 一文，非常清楚

4.完成以上三步，你的系统就可以运行与UTF-8编码环境了。

快速排序 Quick Sort

我们已经知道，在决策树计算模型下，任何一个基于比较来确定两个元素相对位置的排序算法需要Ω(nlogn)计算时间。如果我们能设计一个需要O(n1ogn)时间的排序算法，则在渐近的意义上，这个排序算法就是最优的。许多排序算法都是追求这个目标。

下面介绍快速排序算法，它在平均情况下需要O(nlogn)时间。这个算法是由C.A.R.Hoare发明的。

算法的基本思想

快速排序的基本思想是基于分治策略的。对于输入的子序列L[p..r]，如果规模足够小则直接进行排序（比如用前述的冒泡、选择、插入排序均可），否则分三步处理：

• 分解(Divide)：将待排序列L[p..r]划分为两个非空子序列L[p..q]和L[q+1..r]，使L [p..q]中任一元素的值不大于L[q+1..r]中任一元素的值。具体可通过这样的途径实现：在序列L[p..r]中选择数据元素L[q]，经比较和 移动后，L[q]将处于L[p..r]中间的适当位置，使得数据元素L[q]的值小于L[q+1..r]中任一元素的值。
• 递归求解(Conquer)：通过递归调用快速排序算法，分别对L[p..q]和L[q+1..r]进行排序。
• 合并(Merge)：由于对分解出的两个子序列的排序是就地进行的，所以在L[p..q]和L[q+1..r]都排好序后不需要执行任何计算L[p..r]就已排好序，即自然合并。

这个解决流程是符合分治法的基本步骤的。因此，快速排序法是分治法的经典应用实例之一。

算法的实现

算法Quick_Sort的实现：

注意：下面的记号L[p..r]代表线性表L从位置p到位置r的元素的集合，但是L并不一定要用数组来实现，可以是用任何一种实现方法（比如说链表），这里L[p..r]只是一种记号。

procedure Quick_Sort(p,r:position;var L:List);
const
e=12;
var
q:position;
begin
1  if r-p<=e then Insertion_Sort(L,p,r)
//若L[p..r]足够小则直接对L[p..r]进行插入排序
     else begin
2            q:=partition(p,r,L);
//将L[p..r]分解为L[p..q]和L[q+1..r]两部分
3            Quick_Sort(p,q,L);  //递归排序L[p..q]
4            Quick_Sort(q+1,r,L);//递归排序L[q+1..r]		
          end;
end;

对线性表L[1..n]进行排序，只要调用Quick_Sort(1,n,L)就可以了。算法首先判断L[p..r]是否足够小，若足够小则直接对L[p..r]进行排序，Sort可以是任何一种简单的排序法，一般用插入排序。 这是因为，对于较小的表，快速排序中划分和递归的开销使得该算法的效率还不如其它的直接排序法好。至于规模多小才算足够小，并没有一定的标准，因为这跟生 成的代码和执行代码的计算机有关，可以采取试验的方法确定这个规模阈值。经验表明，在大多数计算机上，取这个阈值为12较好，也就是说，当r-p< =e=12即L[p..r]的规模不大于12时，直接采用插入排序法对L[p..r]进行排序。当然，比较方便的方法是取该阈值为1，当待排序的表只有一 个元素时，根本不用排序(其实还剩两个元素时就已经在Partition函数中排好序了)，只要把第1行的if语句改为if p=r then exit else ...。这就是通常教科书上看到的快速排序的形式。

注意：算法Quick_Sort中变量q的值一定不能等于r，否则该过程会无限递归下去，永远不能结束。因此下面在partition函数里加了限制条件，避免q=r情况的出现。

算法Quick_Sort中调用了一个函数partition，该函数主要实现以下两个功能：

1. 在L[p..r]中选择一个支点元素pivot;
2. 对L[p..r]中的元素进行整理，使得L[p..q]分为两部分L[p..q]和L[q+1..r]，并且L[p..q]中的每一个元素的值不大于pivot，L[q+1..r]中的每一个元素的值不小于pivot，但是L[p..q]和L[q+1..r]中的元素并不要求排好序。

快速排序法改进性能的关键就在于上述的第二个功能，因为该功能并不要求L[p..q]和L[q+1..r]中的元素排好序。

函数partition可以实现如下。以下的实现方法是原地置换的，当然也有不是原地置换的方法，实现起来较为简单，这里就不介绍了。

function partition(p,r:position;var L:List):position;
var
pivot:ElementType;
i,j:position;
begin
1  pivot:=Select_Pivot(p,r,L); //在L[p..r]中选择一个支点元素pivot
2  i:=p-1;
3  j:=r+1;
4  while true do
     begin
5      repeat j:=j-1 until L[j]<=pivot;  
//移动左指针，注意这里不能用while循环
6      repeat i:=i+1 until L[i]>=pivot;  
//移动右指针，注意这里不能用while循环
7      if i< j then swap(L[i],L[j])  //交换L[i]和L[j]
8        else if j<>r then return j  //返回j的值作为分割点
9          else return j-1;          //返回j前一位置作为分割点
     end;
end;

该算法的实现很精巧。其中，有一些细节需要注意。例如，算法中的位置i和j不会超出A[p..r]的位置界，并且该算法的循环不会出现死循环，如果将两个repeat语句换为while则要注意当L[i]=L[j]=pivot且i<j时i和j的值都不再变化，会出现死循环。

另外，最后一个if..then..语句很重要，因为如果pivot取的不好，使得Partition结束时j正好等于r，则如前所述，算法Quick_Sort会无限递归下去；因此必须判断j是否等于r，若j=r则返回j的前驱。

以上算法的一个执行实例如图1所示，其中pivot=L[p]=5：

图1 Partition过程的一个执行实例

Partition对L[p..r]进行划分时，以pivot作为划分的基准，然后分别从左、右两端开始，扩展两个区域L[p..i]和L[j.. r]，使得L[p..i]中元素的值小于或等于pivot，而L[j..r]中元素的值大于或等于pivot。初始时i=p-1，且j=i+1，从而这两 个区域是空的。在while循环体中，位置j逐渐减小，i逐渐增大，直到L[i]≥pivot≥L[j]。如果这两个不等式是严格的，则L[i]不会是左 边区域的元素，而L[j]不会是右边区域的元素。此时若i在j之前，就应该交换L[i]与L[j]的位置，扩展左右两个区域。 while循环重复至i不再j之前时结束。这时L[p..r]己被划分成L[p..q]和L[q+1..r]，且满足L[p..q]中元素的值不大于L [q+1..r]中元素的值。在过程Partition结束时返回划分点q。

寻找支点元素select_pivot有多种实现方法，不同的实现方法会导致快速排序的不同性能。根据分治法平衡子问题的思想，我们希望支点元素可以使L[p..r]尽量平均地分为两部分，但实际上这是很难做到的。下面我们给出几种寻找pivot的方法。

1. 选择L[p..r]的第一个元素L[p]的值作为pivot；
2. 选择L[p..r]的最后一个元素L[r]的值作为pivot；
3. 选择L[p..r]中间位置的元素L[m]的值作为pivot；
4. 选择L[p..r]的某一个随机位置上的值L[random(r-p)+p]的值作为pivot；

按照第4种方法随机选择pivot的快速排序法又称为随机化版本的快速排序法，在下面的复杂性分析中我们将看到该方法具有平均情况下最好的性能，在实际应用中该方法的性能也是最好的。

下面是一个快速排序的Java Applet演示程序，该程序使用第一种pivot选择法，即选L[p]为pivot，因此Partition过程作了一些简化，与我们这里的 Partition过程实现方法不同，但功能相同。该程序是针对用数组实现的线性表，用C语言实现的。

[参考算法]：Pascal语言表述的快速排序算法
   procedure sort(l,r:integer);
   var i,j,mid:integer;
   begin
     i:=l;j:=r; mid:=a[(l+r) div 2];
     {将当前序列在中间位置的数定义为中间数}
     repeat
       while a[i]< mid do inc(i); 
     {在左半部分寻找比中间数大的数}
       while mid< a[j] do dec(j);
     {在右半部分寻找比中间数小的数}
       if i< =j then begin 
     {若找到一组与排序目标不一致的数对则交换它们}
         swap(a[i],a[j]);
         inc(i);dec(j); {继续找}
       end;
     until i >j;
     if l< j then sort(l,j); 
     {若未到两个数的边界，则递归搜索左右区间}
     if i< r then sort(i,r);
   end;{sort}

思考与练习： 完成并提交作业
　　1、仔细阅读下面的Pascal程序，并回答有关问题。
procedure PX(var A:array[1..500] of integer,n:integer);
var i,j,x:integer;b:boolean;
begin
  b:=true;i:=1;
  while (i < n) and b do
    begin
b:=false;
for j:=1 to ______ do
  if _____ then
begin
x:=A[j];A[j]:=A[j+1];A[j+1]:=x; 
______ end;
  i:=i+1;
    end;  
end;
(1)在_____中填上正确的语句或表达式；
(2)该过程使用的是什么排序方式?
(3)当数组A的元素初始时已为递增排列时，该过程运行时会进行几次比较？几次交换？
(4)若A是递减排列，比较和交换次数又是多少？

　2、给出n个学生的考试成绩表，每个数据记录由学生的姓名和成绩组成，试设计一个算法：
(1)按成绩高低次序,输出每个学生在考试中获得的名次,成绩相同的名次相同;
(2)按名次输出每个学生的姓名和成绩。

下面的内容供参考——

性能分析

下面我们就最好情况，最坏情况和平均情况对快速排序算法的性能作一点分析。

注意：这里为方便起见，我们假设算法Quick_Sort的范围阈值为1（即一直将线性表分解到只剩一个元素），这对该算法复杂性的分析没有本质的影响。

我们先分析函数partition的性能，该函数对于确定的输入复杂性是确定的。观察该函数，我们发现，对于有n个元素的确定输入L[p..r]，该函数运行时间显然为θ(n)。

最坏情况

无论适用哪一种方法来选择pivot，由于我们不知道各个元素间的相对大小关系（若知道就已经排好序了），所以我们无法确定pivot的选择对划分造成的影响。因此对各种pivot选择法而言，最坏情况和最好情况都是相同的。

我们从直觉上可以判断出最坏情况发生在每次划分过程产生的两个区间分别包含n-1个元素和1个元素的时候(设输入的表有n个元素)。下面我们暂时认为该猜测正确，在后文我们再详细证明该猜测。

对于有n个元素的表L[p..r]，由于函数Partition的计算时间为θ(n)，所以快速排序在序坏情况下的复杂性有递归式如下：

T(1)=θ(1), T(n)=T(n-1)+T(1)+θ(n)             (1)

用迭代法可以解出上式的解为T(n)=θ(n²)。

这个最坏情况运行时间与插入排序是一样的。

下面我们来证明这种每次划分过程产生的两个区间分别包含n-1个元素和1个元素的情况就是最坏情况。

设T(n)是过程Quick_Sort作用于规模为n的输入上的最坏情况的时间，则

T(n)=max(T(q)+T(n-q))+θ(n) ,其中1≤q≤n-1    (2)

我们假设对于任何k<n，总有T(k)≤ck² ，其中c为常数；显然当k=1时是成立的。

将归纳假设代入(2)，得到：

T(n)≤max(cq²+c(n-q)²)+θ(n)=c*max(q²+(n-q)²)+θ(n)

因为在[1,n-1]上q²+(n-q)²关于q递减，所以当q=1时q²+(n-q)²有最大值n²-2(n-1)。于是有：

T(n)≤cn²-2c(n-1)+θ(n)≤cn²

只要c足够大，上面的第二个小于等于号就可以成立。于是对于所有的n都有T(n)≤cn² 。

这样，排序算法的最坏情况运行时间为θ(n²)，且最坏情况发生在每次划分过程产生的两个区间分别包含n-1个元素和1个元素的时候。

最好情况

如果每次划分过程产生的区间大小都为n/2，则快速排序法运行就快得多了。这时有：

T(n)=2T(n/2)+θ(n), T(1)=θ(1)     (3)

解得： T(n)=θ(nlogn)

快速排序法最佳情况下执行过程的递归树如下图所示，图中lgn表示以2位底的对数，而本文中用logn表示以2位底的对数.

图2  快速排序法最佳情况下执行过程的递归树

　

由于快速排序法也是基于比较的排序法，其运行时间为Ω(nlogn)，所以如果每次划分过程产生的区间大小都为n/2，则运行时间θ(nlogn)就是最好情况运行时间。

但是，是否一定要每次平均划分才能达到最好情况呢？要理解这一点就必须理解对称性是如何在描述运行时间的递归式中反映的。我们假设每次划分过程都产生9:1的划分，乍一看该划分很不对称。我们可以得到递归式：

T(n)=T(n/10)+T(9n/10)+θ(n) , T(1)=θ(1)         (4)

这个递归式对应的递归树如下图所示：

图3  (4)式对应的递归树

　

请注意该树的每一层都有代价n，直到在深度log₁₀n=θ(logn)处达到边界条件， 以后各层代价至多为n。递归于深度log_10/9n= θ(logn)处结束。这样，快速排序的总时间代价为T(n)=θ(nlogn)，从渐进意义上看就和划分是在中间进行的一样。事实上，即使是99:1的 划分时间代价也为θ(nlogn)。其原因在于，任何一种按常数比例进行划分所产生的递归树的深度都为θ(nlogn)，其中每一层的代价为O(n)，因而不管常数比例是什么，总的运行时间都为θ(nlogn)，只不过其中隐含的常数因子有所不同。

平均情况

我们首先对平均情况下的性能作直觉上的分析。

要想对快速排序的平均情况有个较为清楚的概念，我们就要对遇到的各种输入作个假设。通常都假设输入数据的所有排列都是等可能的。后文中我们要讨论这个假设。

当我们对一个随机的输入数组应用快速排序时，要想在每一层上都有同样的划分是不太可能的。我们所能期望的是某些划分较对称，另一些则很不对称。事实 上，我们可以证明，如果选择L[p..r]的第一个元素作为支点元素，Partition所产生的划分80%以上都比9:1更对称，而另20%则比9:1 差，这里证明从略。

平均情况下，Partition产生的划分中既有“好的”，又有“差的”。这时，与 Partition执行过程对应的递归树中，好、差划分是随机地分布在树的各层上的。为与我们的直觉相一致，假设好、差划分交替出现在树的各层上，且好的 划分是最佳情况划分，而差的划分是最坏情况下的划分，图4(a)表示了递归树的连续两层上的划分情况。在根节点处，划分的代价为n，划分出来的两个子表的 大小为n-1和1，即最坏情况。在根的下一层，大小为n-1的子表按最佳情况划分成大小各为(n-1)/2的两个子表。这儿我们假设含1个元素的子表的边 界条件代价为1。

(a)

(b)

图4 快速排序的递归树划分中的两种情况

在一个差的划分后接一个好的划分后，产生出三个子表，大小各为1，(n-1)/2和(n-1)/2，代价共为2n-1=θ(n)。这与图4(b)中 的情况差不多。该图中一层划分就产生出大小为(n-1)/2+1和(n-1)/2的两个子表，代价为n=θ(n)。这种划分差不多是完全对称的，比9:1 的划分要好。从直觉上看，差的划分的代价θ(n)可被吸收到好的划分的代价θ(n)中去，结果是一个好的划分。这样，当好、差划分交替分布划分都是好的一 样：仍是θ(nlogn)，但θ记号中隐含的常数因子要略大一些。关于平均情况的严格分析将在后文给出。

在前文从直觉上探讨快速排序的平均性态过程中，我们已假定输入数据的所有排列都是等可能的。如果输入的分布满足这个假设时，快速排序是对足够大的输入的理想选择。但在实际应用中，这个假设就不会总是成立。

解决的方法是，利用随机化策略，能够克服分布的等可能性假设所带来的问题。

一种随机化策略是：与对输入的分布作“假设”不同的是对输入的分布作“规定”。具体地说，在排序输入的线性表前，对其元素加以随机排列，以强制的方 法使每种排列满足等可能性。事实上，我们可以找到一个能在O(n)时间内对含n个元素的数组加以随机排列的算法。这种修改不改变算法的最坏情况运行时间， 但它却使得运行时间能够独立于输入数据已排序的情况。

另一种随机化策略是：利用前文介绍的选择支点元素pivot的第四种方法，即随机地在L[p..r]中选择一个元素作为支点元素pivot。实际应用中通常采用这种方法。

快速排序的随机化版本有一个和其他随机化算法一样的有趣性质：没有一个特别的输入会导致最坏情况性态。这种算法的最坏情况性态是由随机数产生器决定 的。你即使有意给出一个坏的输入也没用，因为随机化排列会使得输入数据的次序对算法不产生影响。只有在随机数产生器给出了一个很不巧的排列时，随机化算法 的最坏情况性态才会出现。事实上可以证明几乎所有的排列都可使快速排序接近平均情况性态,只有非常少的几个排列才会导致算法的近最坏情况性态。

一般来说，当一个算法可按多条路子做下去，但又很难决定哪一条保证是好的选择时，随机化策略是很有用的。如果大部分选择都是好的，则随机地选一个就 行了。通常，一个算法在其执行过程中要做很多选择。如果一个好的选择的获益大于坏的选择的代价，那么随机地做一个选择就能得到一个很有效的算法。我们在前 文已经了解到，对快速排序来说，一组好坏相杂的划分仍能产生很好的运行时间。因此我们可以认为该算法的随机化版本也能具有较好的性态。

在前文我们从直觉上分析了快速排序在平均情况下的性能为θ(nlogn)，我们将在下面定量地分析快速排序法在平均情况下的性能。为了满足输入的数 据的所有排列都是等可能的这个假设，我们采用上面提到的随机选择pivot的方法，并且在Select_pivot函数中将选出的pivot与L[p]交 换位置（这不是必需的，纯粹是为了下文分析的方便，这样L[p]就是支点元素pivot）。那种基于对输入数据加以随机排列的随机化算法的平均性态也很 好，只是比这儿介绍的这个版本更难以分析。

我们先来看看Partition的执行过程。为简化分析，假设所有输入数据都是不同的。即使这个假设不满足，快速排序的平均情况运行时间仍为θ(nlogn)，但这时的分析就要复杂一些。

由Partition返回的值q仅依赖于pivot在L[p..r]中的秩(rank)，某个数在一个集合中的秩是指该集合中小于或等于该数的元素的个数。如果设n为L[p..r]的元素个数，将L[p]与L[p..r]中的一个随机元素pivot交换就得rank(pivot)=i(i=1,2,..,n)的概率为l/n。

下一步来计算划分过程不同结果的可能性。如果rank(pivot)=1，即pivot是L[p..r]中最小的元素，则Partition的循环结束时指针i停在i=p处，指针j停在k=p处。当返回q时，划分结果的"低区"中就含有唯一的元素L[p]=pivot。这个事件发生的概率为1/n，因为rank(pivot)=i的概率为1/n。

如果rank(pivot)≥2，则至少有一个元素小于L[p]，故在外循环while循环的第一次执行中，指针i停于i=p处，指针j则在达到p 之前就停住了。这时通过交换就可将L[p]置于划分结果的高区中。当Partition结束时，低区的rank(pivot)-1个元素中的每一个都严格 小于pivot（因为假设输入的元素不重复）。这样，对每个i=1,2,..,n-1，当rank(pivot)≥2时，划分的低区中含i个元素的概率为 l/n。

把这两种情况综合起来，我们的结论为：划分的低区的大小为1的概率为2/n，低区大小为i的概率为1/n，i=2,3,..n-1。

现在让我们来对Quick_Sort的期望运行时间建立一个递归式。设T(n)表示排序含n个元素的表所需的平均时间，则：

   （5）

其中T(1)=θ(1)。

q的分布基本上是均匀的，但是q=1的可能性是其他值的两倍。根据前面作的最坏情况的分析有：

T(1)=θ(1),T(n-1)=θ(n²)，所以

这可被(5)式中的θ(n)所吸收，所以(5)式可简化为：

           (6)

注意对k=1,2,..,n-1，和式中每一项T(k)为T(q)和T(n-q)的机会各有一次，把这两项迭起来有：

                        (7)

　

我们用代入法来解上述递归方程。归纳假设T(n)≤a*nlogn+b，其中a>0,b>0为待定常数。可以选择足够大的a,b使anlogn+b>T(1)，对于n>1有：

          （8）

下面我们来确定和式

                    （9）

的界。

因为和式中每一项至多是nlogn，则有界：

这是个比较紧的界，但是对于解递归式（8）来说还不够强。为解该递归式，我们希望有界：

为了得到这个界，可以将和式(9)分解为两部分，这时有：

等号右边的第一个和式中的logk可由log(n/2)=logn-1从上方限界。第二个和式中的logk可由logn从上方限界，这样，

对于n≥2成立。即:

     (10)

将(10)代入(8）式得：

      （11）

　

因为我们可以选择足够大的a使a*n/4能够决定θ(n)+b，所以快速排序的平均运行时间为θ(nlogn)。

• 远程服务的接口定义
• 远程服务接口的具体实现
• 桩（Stub）和框架（Skeleton）文件
• 一个运行远程服务的服务器
• 一个RMI命名服务，它允许客户端去发现这个远程服务
• 类文件的提供者（一个HTTP或者FTP服务器）
• 一个需要这个远程服务的客户端程序

　　下面我们一步一步建立一个简单的RMI系统。首先在你的机器里建立一个新的文件夹，以便放置我们创建的文件，为了简单起见，我们只使用一个文件夹存放客户端和服务端代码，并且在同一个目录下运行服务端和客户端。

　　如果所有的RMI文件都已经设计好了，那么你需要下面的几个步骤去生成你的系统：

　　1、  编写并且编译接口的Java代码
　　2、  编写并且编译接口实现的Java代码
　　3、  从接口实现类中生成桩（Stub）和框架（Skeleton）类文件
　　4、  编写远程服务的主运行程序
　　5、  编写RMI的客户端程序
　　6、  安装并且运行RMI系统

　　> java -Djava.security.policy=policy.txt CalculatorServer

　　这个服务器就开始工作了，把接口的实现加载到内存等待客户端的联接。好现在切换到第三个控制台，启动我们的客户端。
　　为了在其他的机器运行客户端程序你需要一个远程接口(Calculator.class) 和一个stub(CalculatorImpl_Stub.class)。 使用如下命令运行客户端

　　 prompt> java -Djava.security.policy=policy.txt CalculatorClient

如果所有的这些都成功运行，你应该看到下面的输出：
　　1
　　9
　　18
　　3
　　如果你看到了上面的输出，恭喜你，你成功了，你已经成功的创建了一个RMI系统，并且使他正确工作了。即使你运行在同一个计算机上，RMI还是使用了 你的网络堆栈和TCP/IP去进行通讯，并且是运行在三个不同的Java虚拟机上。这已经是一个完整的RMI系统。

作者：郎云鹏（dev2dev ID: hippiewolf）

摘要：虽然session机制在web应用程序中被采用已经很长时间了，但是仍然有很多人不清楚session机制的本质，以至不能正确的应用这一 技术。本文将详细讨论session的工作机制并且对在Java web application中应用session机制时常见的问题作出解答。

目录：
一、术语session
二、HTTP协议与状态保持
三、理解cookie机制
四、理解session机制
五、理解javax.servlet.http.HttpSession
六、HttpSession常见问题
七、跨应用程序的session共享
八、总结
参考文档

一、术语session
在我的经验里，session这个词被滥用的程度大概仅次于transaction，更加有趣的是transaction与session在某些语境下的含义是相同的。

session，中文经常翻译为会话，其本来的含义是指有始有终的一系列动作/消息，比如打电话时从拿起电话拨号到挂断电话这中间的一系列过程可以 称之为一个session。有时候我们可以看到这样的话“在一个浏览器会话期间，...”，这里的会话一词用的就是其本义，是指从一个浏览器窗口打开到关 闭这个期间①。最混乱的是“用户（客户端）在一次会话期间”这样一句话，它可能指用户的一系列动作（一般情况下是同某个具体目的相关的一系列动作，比如从 登录到选购商品到结账登出这样一个网上购物的过程，有时候也被称为一个transaction），然而有时候也可能仅仅是指一次连接，也有可能是指含义 ①，其中的差别只能靠上下文来推断②。

然而当session一词与网络协议相关联时，它又往往隐含了“面向连接”和/或“保持状态”这样两个含义，“面向连接”指的是在通信双方在通信之 前要先建立一个通信的渠道，比如打电话，直到对方接了电话通信才能开始，与此相对的是写信，在你把信发出去的时候你并不能确认对方的地址是否正确，通信渠 道不一定能建立，但对发信人来说，通信已经开始了。“保持状态”则是指通信的一方能够把一系列的消息关联起来，使得消息之间可以互相依赖，比如一个服务员 能够认出再次光临的老顾客并且记得上次这个顾客还欠店里一块钱。这一类的例子有“一个TCP session”或者“一个POP3 session”③。

而到了web服务器蓬勃发展的时代，session在web开发语境下的语义又有了新的扩展，它的含义是指一类用来在客户端与服务器之间保持状态的 解决方案④。有时候session也用来指这种解决方案的存储结构，如“把xxx保存在session里”⑤。由于各种用于web开发的语言在一定程度上 都提供了对这种解决方案的支持，所以在某种特定语言的语境下，session也被用来指代该语言的解决方案，比如经常把Java里提供的 javax.servlet.http.HttpSession简称为session⑥。

鉴于这种混乱已不可改变，本文中session一词的运用也会根据上下文有不同的含义，请大家注意分辨。
在本文中，使用中文“浏览器会话期间”来表达含义①，使用“session机制”来表达含义④，使用“session”表达含义⑤，使用具体的“HttpSession”来表达含义⑥

二、HTTP协议与状态保持
HTTP协议本身是无状态的，这与HTTP协议本来的目的 是相符的，客户端只需要简单的向服务器请求下载某些文件，无论是客户端还是服务器都没有必要纪录彼此过去的行为，每一次请求之间都是独立的，好比一个顾客 和一个自动售货机或者一个普通的（非会员制）大卖场之间的关系一样。

然而聪明（或者贪心？）的人们很快发现如果能够提供一些按需生成的动态信息会使web变得更加有用，就像给有线电视加上点播功能一样。这种需求一方 面迫使HTML逐步添加了表单、脚本、DOM等客户端行为，另一方面在服务器端则出现了CGI规范以响应客户端的动态请求，作为传输载体的HTTP协议也 添加了文件上载、cookie这些特性。其中cookie的作用就是为了解决HTTP协议无状态的缺陷所作出的努力。至于后来出现的session机制则 是又一种在客户端与服务器之间保持状态的解决方案。

让我们用几个例子来描述一下cookie和session机制之间的区别与联系。笔者曾经常去的一家咖啡店有喝5杯咖啡免费赠一杯咖啡的优惠，然而一次性消费5杯咖啡的机会微乎其微，这时就需要某种方式来纪录某位顾客的消费数量。想象一下其实也无外乎下面的几种方案：
1、该店的店员很厉害，能记住每位顾客的消费数量，只要顾客一走进咖啡店，店员就知道该怎么对待了。这种做法就是协议本身支持状态。
2、发给顾客一张卡片，上面记录着消费的数量，一般还有个有效期限。每次消费时，如果顾客出示这张卡片，则此次消费就会与以前或以后的消费相联系起来。这种做法就是在客户端保持状态。
3、发给顾客一张会员卡，除了卡号之外什么信息也不纪录，每次消费时，如果顾客出示该卡片，则店员在店里的纪录本上找到这个卡号对应的纪录添加一些消费信息。这种做法就是在服务器端保持状态。

由于HTTP协议是无状态的，而出于种种考虑也不希望使之成为有状态的，因此，后面两种方案就成为现实的选择。具体来说cookie机制采用的是在 客户端保持状态的方案，而session机制采用的是在服务器端保持状态的方案。同时我们也看到，由于采用服务器端保持状态的方案在客户端也需要保存一个 标识，所以session机制可能需要借助于cookie机制来达到保存标识的目的，但实际上它还有其他选择。

三、理解cookie机制
cookie机制的基本原理就如上面的例子一样简单，但是还有几个问题需要解决：“会员卡”如何分发；“会员卡”的内容；以及客户如何使用“会员卡”。

正统的cookie分发是通过扩展HTTP协议来实现的，服务器通过在HTTP的响应头中加上一行特殊的指示以提示浏览器按照指示生成相应的cookie。然而纯粹的客户端脚本如JavaScript或者VBScript也可以生成cookie。

而cookie的使用是由浏览器按照一定的原则在后台自动发送给服务器的。浏览器检查所有存储的cookie，如果某个cookie所声明的作用范 围大于等于将要请求的资源所在的位置，则把该cookie附在请求资源的HTTP请求头上发送给服务器。意思是麦当劳的会员卡只能在麦当劳的店里出示，如 果某家分店还发行了自己的会员卡，那么进这家店的时候除了要出示麦当劳的会员卡，还要出示这家店的会员卡。

cookie的内容主要包括：名字，值，过期时间，路径和域。
其中域可以指定某一个域比如.google.com，相当于总店招牌，比如宝洁公司，也可以指定一个域下的具体某台机器比如www.google.com或者froogle.google.com，可以用飘柔来做比。
路径就是跟在域名后面的URL路径，比如/或者/foo等等，可以用某飘柔专柜做比。
路径与域合在一起就构成了cookie的作用范围。
如 果不设置过期时间，则表示这个cookie的生命期为浏览器会话期间，只要关闭浏览器窗口，cookie就消失了。这种生命期为浏览器会话期的 cookie被称为会话cookie。会话cookie一般不存储在硬盘上而是保存在内存里，当然这种行为并不是规范规定的。如果设置了过期时间，浏览器 就会把cookie保存到硬盘上，关闭后再次打开浏览器，这些cookie仍然有效直到超过设定的过期时间。

存储在硬盘上的cookie可以在不同的浏览器进程间共享，比如两个IE窗口。而对于保存在内存里的cookie，不同的浏览器有不同的处理方式。 对于IE，在一个打开的窗口上按Ctrl-N（或者从文件菜单）打开的窗口可以与原窗口共享，而使用其他方式新开的IE进程则不能共享已经打开的窗口的内 存cookie；对于Mozilla Firefox0.8，所有的进程和标签页都可以共享同样的cookie。一般来说是用javascript的window.open打开的窗口会与原窗 口共享内存cookie。浏览器对于会话cookie的这种只认cookie不认人的处理方式经常给采用session机制的web应用程序开发者造成很 大的困扰。

下面就是一个goolge设置cookie的响应头的例子
HTTP/1.1 302 Found
Location: http://www.google.com/intl/zh-CN/
Set-Cookie: PREF=ID=0565f77e132de138:NW=1:TM=1098082649:LM=1098082649:S=KaeaCFPo49RiA_d8; expires=Sun, 17-Jan-2038 19:14:07 GMT; path=/; domain=.google.com
Content-Type: text/html

这是使用HTTPLook这个HTTP Sniffer软件来俘获的HTTP通讯纪录的一部分

浏览器在再次访问goolge的资源时自动向外发送cookie

使用Firefox可以很容易的观察现有的cookie的值
使用HTTPLook配合Firefox可以很容易的理解cookie的工作原理。

IE也可以设置在接受cookie前询问

这是一个询问接受cookie的对话框。

四、理解session机制
session机制是一种服务器端的机制，服务器使用一种类似于散列表的结构（也可能就是使用散列表）来保存信息。

当程序需要为某个客户端的请求创建一个session的时候，服务器首先检查这个客户端的请求里是否已包含了一个session标识 - 称为session id，如果已包含一个session id则说明以前已经为此客户端创建过session，服务器就按照session id把这个session检索出来使用（如果检索不到，可能会新建一个），如果客户端请求不包含session id，则为此客户端创建一个session并且生成一个与此session相关联的session id，session id的值应该是一个既不会重复，又不容易被找到规律以仿造的字符串，这个session id将被在本次响应中返回给客户端保存。

保存这个session id的方式可以采用cookie，这样在交互过程中浏览器可以自动的按照规则把这个标识发挥给服务器。一般这个cookie的名字都是类似于 SEEESIONID，而。比如weblogic对于web应用程序生成的cookie，JSESSIONID= ByOK3vjFD75aPnrF7C2HmdnV6QZcEbzWoWiBYEnLerjQ99zWpBng!-145788764，它的名字就是 JSESSIONID。

由于cookie可以被人为的禁止，必须有其他机制以便在cookie被禁止时仍然能够把session id传递回服务器。经常被使用的一种技术叫做URL重写，就是把session id直接附加在URL路径的后面，附加方式也有两种，一种是作为URL路径的附加信息，表现形式为http://...../xxx; jsessionid=ByOK3vjFD75aPnrF7C2HmdnV6QZcEbzWoWiBYEnLerjQ99zWpBng!-145788764
另一种是作为查询字符串附加在URL后面，表现形式为http://...../xxx?jsessionid=ByOK3vjFD75aPnrF7C2HmdnV6QZcEbzWoWiBYEnLerjQ99zWpBng!-145788764
这两种方式对于用户来说是没有区别的，只是服务器在解析的时候处理的方式不同，采用第一种方式也有利于把session id的信息和正常程序参数区分开来。
为了在整个交互过程中始终保持状态，就必须在每个客户端可能请求的路径后面都包含这个session id。

另一种技术叫做表单隐藏字段。就是服务器会自动修改表单，添加一个隐藏字段，以便在表单提交时能够把session id传递回服务器。比如下面的表单
<form name="testform" action="/xxx">
<input type="text">
</form>
在被传递给客户端之前将被改写成
<form name="testform" action="/xxx">
<input type="hidden" name="jsessionid" value="ByOK3vjFD75aPnrF7C2HmdnV6QZcEbzWoWiBYEnLerjQ99zWpBng!-145788764">
<input type="text">
</form>
这种技术现在已较少应用，笔者接触过的很古老的iPlanet6(SunONE应用服务器的前身)就使用了这种技术。
实际上这种技术可以简单的用对action应用URL重写来代替。

在谈论session机制的时候，常常听到这样一种误解“只要关闭浏览器，session就消失了”。其实可以想象一下会员卡的例子，除非顾客主动 对店家提出销卡，否则店家绝对不会轻易删除顾客的资料。对session来说也是一样的，除非程序通知服务器删除一个session，否则服务器会一直保 留，程序一般都是在用户做log off的时候发个指令去删除session。然而浏览器从来不会主动在关闭之前通知服务器它将要关闭，因此服务器根本不会有机会知道浏览器已经关闭，之所 以会有这种错觉，是大部分session机制都使用会话cookie来保存session id，而关闭浏览器后这个session id就消失了，再次连接服务器时也就无法找到原来的session。如果服务器设置的cookie被保存到硬盘上，或者使用某种手段改写浏览器发出的 HTTP请求头，把原来的session id发送给服务器，则再次打开浏览器仍然能够找到原来的session。

恰恰是由于关闭浏览器不会导致session被删除，迫使服务器为seesion设置了一个失效时间，当距离客户端上一次使用session的时间超过这个失效时间时，服务器就可以认为客户端已经停止了活动，才会把session删除以节省存储空间。

五、理解javax.servlet.http.HttpSession
HttpSession是Java平台对session机制的实现规范，因为它仅仅是个接口，具体到每个web应用服务器的提供商，除了对规范支持之外，仍然会有一些规范里没有规定的细微差异。这里我们以BEA的Weblogic Server8.1作为例子来演示。

首先，Weblogic Server提供了一系列的参数来控制它的HttpSession的实现，包括使用cookie的开关选项，使用URL重写的开关选项，session持 久化的设置，session失效时间的设置，以及针对cookie的各种设置，比如设置cookie的名字、路径、域，cookie的生存时间等。

一般情况下，session都是存储在内存里，当服务器进程被停止或者重启的时候，内存里的session也会被清空，如果设置了session的 持久化特性，服务器就会把session保存到硬盘上，当服务器进程重新启动或这些信息将能够被再次使用，Weblogic Server支持的持久性方式包括文件、数据库、客户端cookie保存和复制。

复制严格说来不算持久化保存，因为session实际上还是保存在内存里，不过同样的信息被复制到各个cluster内的服务器进程中，这样即使某个服务器进程停止工作也仍然可以从其他进程中取得session。

cookie生存时间的设置则会影响浏览器生成的cookie是否是一个会话cookie。默认是使用会话cookie。有兴趣的可以用它来试验我们在第四节里提到的那个误解。

cookie的路径对于web应用程序来说是一个非常重要的选项，Weblogic Server对这个选项的默认处理方式使得它与其他服务器有明显的区别。后面我们会专题讨论。

关于session的设置参考[5] http://e-docs.bea.com/wls/docs70/webapp/weblogic_xml.html#1036869

六、HttpSession常见问题
（在本小节中session的含义为⑤和⑥的混合）

1、session在何时被创建
一个常见的误解是以为session在有客户端访问时就被创建，然而事实是直到某server端程 序调用HttpServletRequest.getSession(true)这样的语句时才被创建，注意如果JSP没有显示的使用 <%@page session="false"%> 关闭session，则JSP文件在编译成Servlet时将会自动加上这样一条语句HttpSession session = HttpServletRequest.getSession(true);这也是JSP中隐含的session对象的来历。

由于session会消耗内存资源，因此，如果不打算使用session，应该在所有的JSP中关闭它。

2、session何时被删除
综合前面的讨论，session在下列情况下被删除a.程序调用HttpSession.invalidate();或b.距离上一次收到客户端发送的session id时间间隔超过了session的超时设置;或c.服务器进程被停止（非持久session）

3、如何做到在浏览器关闭时删除session
严格的讲，做不到这一点。可以做一点努力的办法是在所有的客户端页面里使用javascript代码window.oncolose来监视浏览器的关闭动作，然后向服务器发送一个请求来删除session。但是对于浏览器崩溃或者强行杀死进程这些非常规手段仍然无能为力。

4、有个HttpSessionListener是怎么回事
你可以创建这样的listener去监控session的创建和销毁事件，使得 在发生这样的事件时你可以做一些相应的工作。注意是session的创建和销毁动作触发listener，而不是相反。类似的与HttpSession有 关的listener还有HttpSessionBindingListener，HttpSessionActivationListener和 HttpSessionAttributeListener。

5、存放在session中的对象必须是可序列化的吗
不是必需的。要求对象可序列化只是为了session能够在集群中被复制或者能够持久 保存或者在必要时server能够暂时把session交换出内存。在Weblogic Server的session中放置一个不可序列化的对象在控制台上会收到一个警告。我所用过的某个iPlanet版本如果session中有不可序列化 的对象，在session销毁时会有一个Exception，很奇怪。

6、如何才能正确的应付客户端禁止cookie的可能性
对所有的URL使用URL重写，包括超链接，form的action，和重定向的URL，具体做法参见[6]
http://e-docs.bea.com/wls/docs70/webapp/sessions.html#100770

7、开两个浏览器窗口访问应用程序会使用同一个session还是不同的session
参见第三小节对cookie的讨论，对session来说是只认id不认人，因此不同的浏览器，不同的窗口打开方式以及不同的cookie存储方式都会对这个问题的答案有影响。

8、如何防止用户打开两个浏览器窗口操作导致的session混乱
这个问题与防止表单多次提交是类似的，可以通过设置客户端的令牌来解决。 就是在服务器每次生成一个不同的id返回给客户端，同时保存在session里，客户端提交表单时必须把这个id也返回服务器，程序首先比较返回的id与 保存在session里的值是否一致，如果不一致则说明本次操作已经被提交过了。可以参看《J2EE核心模式》关于表示层模式的部分。需要注意的是对于使 用javascript window.open打开的窗口，一般不设置这个id，或者使用单独的id，以防主窗口无法操作，建议不要再window.open打开的窗口里做修改 操作，这样就可以不用设置。

9、为什么在Weblogic Server中改变session的值后要重新调用一次session.setValue
做这个动作主要是为了在集群环境中提示Weblogic Server session中的值发生了改变，需要向其他服务器进程复制新的session值。

10、为什么session不见了
排除session正常失效的因素之外，服务器本身的可能性应该是微乎其微的，虽然笔者在 iPlanet6SP1加若干补丁的Solaris版本上倒也遇到过；浏览器插件的可能性次之，笔者也遇到过3721插件造成的问题；理论上防火墙或者代 理服务器在cookie处理上也有可能会出现问题。
出现这一问题的大部分原因都是程序的错误，最常见的就是在一个应用程序中去访问另外一个应用程序。我们在下一节讨论这个问题。

七、跨应用程序的session共享

常常有这样的情况，一个大项目被分割成若干小项目开发，为了能够互不干扰，要 求每个小项目作为一个单独的web应用程序开发，可是到了最后突然发现某几个小项目之间需要共享一些信息，或者想使用session来实现SSO (single sign on)，在session中保存login的用户信息，最自然的要求是应用程序间能够访问彼此的session。

然而按照Servlet规范，session的作用范围应该仅仅限于当前应用程序下，不同的应用程序之间是不能够互相访问对方的session的。 各个应用服务器从实际效果上都遵守了这一规范，但是实现的细节却可能各有不同，因此解决跨应用程序session共享的方法也各不相同。

首先来看一下Tomcat是如何实现web应用程序之间session的隔离的，从Tomcat设置的cookie路径来看，它对不同的应用程序设 置的cookie路径是不同的，这样不同的应用程序所用的session id是不同的，因此即使在同一个浏览器窗口里访问不同的应用程序，发送给服务器的session id也可以是不同的。

根据这个特性，我们可以推测Tomcat中session的内存结构大致如下。

笔者以前用过的iPlanet也采用的是同样的方式，估计SunONE与iPlanet之间不会有太大的差别。对于这种方式的服务器，解决的思路很 简单，实际实行起来也不难。要么让所有的应用程序共享一个session id，要么让应用程序能够获得其他应用程序的session id。

iPlanet中有一种很简单的方法来实现共享一个session id，那就是把各个应用程序的cookie路径都设为/（实际上应该是/NASApp，对于应用程序来讲它的作用相当于根）。
<session-info>
<path>/NASApp</path>
</session-info>

需要注意的是，操作共享的session应该遵循一些编程约定，比如在session attribute名字的前面加上应用程序的前缀，使得setAttribute("name", "neo")变成setAttribute("app1.name", "neo")，以防止命名空间冲突，导致互相覆盖。

在Tomcat中则没有这么方便的选择。在Tomcat版本3上，我们还可以有一些手段来共享session。对于版本4以上的 Tomcat，目前笔者尚未发现简单的办法。只能借助于第三方的力量，比如使用文件、数据库、JMS或者客户端cookie，URL参数或者隐藏字段等手 段。

我们再看一下Weblogic Server是如何处理session的。

从截屏画面上可以看到Weblogic Server对所有的应用程序设置的cookie的路径都是/，这是不是意味着在Weblogic Server中默认的就可以共享session了呢？然而一个小实验即可证明即使不同的应用程序使用的是同一个session，各个应用程序仍然只能访问 自己所设置的那些属性。这说明Weblogic Server中的session的内存结构可能如下

对于这样一种结构，在session机制本身上来解决session共享的问题应该是不可能的了。除了借助于第三方的力量，比如使用文件、数据库、 JMS或者客户端cookie，URL参数或者隐藏字段等手段，还有一种较为方便的做法，就是把一个应用程序的session放到 ServletContext中，这样另外一个应用程序就可以从ServletContext中取得前一个应用程序的引用。示例代码如下，

应用程序A
context.setAttribute("appA", session);

应用程序B
contextA = context.getContext("/appA");
HttpSession sessionA = (HttpSession)contextA.getAttribute("appA");

值得注意的是这种用法不可移植，因为根据ServletContext的JavaDoc，应用服务器可以处于安全的原因对于context.getContext("/appA");返回空值，以上做法在Weblogic Server 8.1中通过。

那么Weblogic Server为什么要把所有的应用程序的cookie路径都设为/呢？原来是为了SSO，凡是共享这个session的应用程序都可以共享认证的信息。一 个简单的实验就可以证明这一点，修改首先登录的那个应用程序的描述符weblogic.xml，把cookie路径修改为/appA访问另外一个应用程序 会重新要求登录，即使是反过来，先访问cookie路径为/的应用程序，再访问修改过路径的这个，虽然不再提示登录，但是登录的用户信息也会丢失。注意做 这个实验时认证方式应该使用FORM，因为浏览器和web服务器对basic认证方式有其他的处理方式，第二次请求的认证不是通过session来实现 的。具体请参看[7] secion 14.8 Authorization，你可以修改所附的示例程序来做这些试验。

八、总结
session机制本身并不复杂，然而其实现和配置上的灵活性却使得具体情况复杂多变。这也要求我们不能把仅仅某一次的经验或者某一个浏览器，服务器的经验当作普遍适用的经验，而是始终需要具体情况具体分析。

关于作者：
郎云鹏（dev2dev ID: hippiewolf），软件工程师，从事J2EE开发
电子邮件：langyunpeng@yahoo.com.cn
地址：大连软件园路31号科技大厦A座大连博涵咨询服务有限公司

参考文档：
[1] Preliminary Specification http://wp.netscape.com/newsref/std/cookie_spec.html
[2] RFC2109 http://www.rfc-editor.org/rfc/rfc2109.txt
[3] RFC2965 http://www.rfc-editor.org/rfc/rfc2965.txt
[4] The Unofficial Cookie FAQ http://www.cookiecentral.com/faq/
[5] http://e-docs.bea.com/wls/docs70/webapp/weblogic_xml.html#1036869
[6] http://e-docs.bea.com/wls/docs70/webapp/sessions.html#100770
[7] RFC2616 http://www.rfc-editor.org/rfc/rfc2616.txt

下载及编译

1. 一个遵循Jaxp(1.1版本及以后)的XML解析器


2. Jakarta commons beanutils包(1.5版本及以后)


3. Jakarta commons collections包(2.1版本及以后)


4. Jakarta commons logging包(1.0.2版本及以后)

一个简单的例子

基本情况

1. 创建一个org.apache.commons.digester.Digester实例。一个解析请求完成后，这个Digester可以被后面复用。但也不要试图在不同的线程中从共享一个Digester实例。


2. 根据需要设置一些配置属性(configuration properties)，以控制下一步的解析操作。


3. 将一个或几个初始对象(initial object)压入Digester对象栈,本步骤不是必须的。


4. 注册所有的元素匹配模板(elemet matching pattern)。当一个模板被从输入文档中识别出来以后，与其相联系的处理规则(processing rules)被激活。对一个特定的模板，可以定义任意多的规则，当识别出该模板后，这些规则依序依次执行。


5. 调用digester.parse()方法，一个XML文档的引用(用多种方式供选择)要传给这个方法。注意，需要捕捉并处理IOException或SAXEception或处理过程中抛出的异常。

元素匹配模板

处理规则(processing rule)

1. begin(),在一个匹配元素被识别出后的“开始”时刻被调用，这个元素的所有属性放在一个数据结构中被传递给begin()


2. body(),当元素的嵌套内容（如子元素）被识别出时被调用。在解析的过程中，前后的空白被去掉了


3. end(),匹配元素的“结束”时刻被调用。如果子元素也匹配相关的规则，则这些规则的方法需都执行毕，才能达到该元素的“结束”时刻。


4. finish(),解析结束时被调用，以提供给各个规则以清理临时数据的机会。

1. ObjectCreateRule,当begin()方法被调用时，这个规则类实例化一个指定的java类，并将其压入栈顶。这个被实例 化的类的名字，默认是这个规则类构造函数得到的参数，也可以通过指定正在处理的xml元素的属性来传递一个新的类的名字。当end()方法被调用　时，栈 顶的对象被弹出，Digester中对它的任何引用将被忽略。


2. FactoryCreateRule,一个非常有用的ObjectCreateRule的变体。


3. SetPropertiesRule,当begin()方法被调用时，digester使用标准的Java Relection API来识别JavaBean的属性设置方法(setter method)，这些方法名称中包含属性（property）的名字，这些属性与XML元素的属性(attribute)匹配，于是这些方法被调用并将相 应的属性值(attribute value)传给它们。这些自然的映射可以被重写。建议不要过度使用这项功能，在大多数情况下，使用标准的BeanInfo机制会更好。


4. SetPropertyRule,当begin()方法被调用时，digester调用栈顶对象的一个特定的属性设置方法(property setter)并传给它特定的值(property和值分别由两个attribute命名)。这对XML需要遵循一个指定的DTD时比较有用，你可以设置 一个特别的属性(property)，虽然在指定DTD没有attribute与其相对应。


5. SetNextRule,当end()方法被调用时，digester分析第二栈顶元素，寻找一个特定属性(property)的设置方法 (setter method)，并接着调用这个方法，以栈顶的元素作参数。这个规则通常用来在两个对象间建立1对多的关系，所用的方法也常被叫做addChild什么 的。


6. SetTopRule,当end()方法被调用时，digester分析栈顶元素，寻找一个特定属性(property)的设置方法 (setter method)，并接着调用这个方法，以第二栈顶的元素作参数。这个规则通常用来在两个对象间建立1对多的关系，所用的方法也常被叫做setParent 什么的。


7. CallMethodRule,这个规则设置当end()被调用时执行的栈顶对象的自定义方法，通过对这个规则的设置，来指定方法的名字、参数的数量以及定义的参数类型的Java类的名字。实际的参数值，来自激活这个方法的元素的子元素。


8. CallParamRule,这个规则用来指定CallMethodRule的参数的值的来源，它可以来自一个特定的属性，或子元素的body的内容.


9. NodeCreateRule,一个特殊的规则，将对象树的一部分转换成一个DOM结点(Node)，并压入栈顶。

在保留http://www.javajia.com原出处的情况下，欢迎转载!