原文：Thinking in Web 2.0: Sixteen Ways
作者：Dion Hinchcliffe

1、在你开始之前，先定一个简单的目标。无论你是一个Web 2.0应用的创建者还是用户，请清晰的构思你的目标。就像“我需要保存一个书签”或者“我准备帮助人们创建可编辑的、共享的页面”这样的目标，让你保持最基础的需求。很多Web 2.0应用的最初吸引之处就是它的简单，避免并隐藏了那些多余的复杂性。站在创建者的立场，可以想象Google的几乎没有内容的主页，还有del.icio.us的简单的线条。从最终用户的角度来看，与之齐名的就是Diggdot.us所提供的初始化页面。你能够并且希望加入更多功能，但是先做好最开始的。在一个时候只做一个特性，完成一个目标。这听起来很太过于单纯化了，但它将使你更加专注，而且你也会明白我的意思。

2、链接是最基础的思想。这就是我们称之为Web的一个理由。链接是把Web中各种实体连接起来的最基本的元素。你的信息、你的关系、你的导航，甚至是能够被写成URL的任何内容。这里有一个链接应该遵循的规则（其实你也不必严格的遵守）：

    1. Web上的任何东西都是可以被URI或者是URL所连接的。
    2. 把所有的链接都保存为他的原始出处，这样可以让你与任何人、在任何地方、任何时候都能分享它。
    3. 第二条中任何时候的前提是链接必须是持久的，它不会在没有任何缘由的情况下被改变或者是消失。
    4. 链接应该是人类可读的、稳定的、并且能够自我诠释的。

3、数据应该属于创建它的人。是的，你听我的。任何用户创建的、贡献的或分享的都是他们自己的，除非他们很明显的放弃这个权力来让你自由处置。他们贡献到Web上的任何信息都应该是可编辑的、能被删除的、并且能够取消共享，无论在任何时候，只要用户愿意。这也包含了那些间接的数据，像他们所关心的记录、日志、浏览历史、网站访问信息，或者是任何可以被跟踪的信息。所有的网站必须清晰简单的陈诉那些信息是用户创建的，并且提供他们停止创建的方法，甚至是清除的方法。

4、数据优先，体验与功能其次。无论它是文本、图片、音频还是视频，Web最终还是把这些解析为数据。换句话说，你无法脱离数据去呈现内容。所有这些数据都通过那些易于发现的URL来定位（参见第2条）。通过另一种形式来看待这些，Web最终是名词优先，动词其次，虽然最近正在向动词偏移。来看看名词的例子：日历的条目、家庭照片、股票价格。还有一些动词的例子：定一个约会、共享一张图片、买一份股票。

5、做好积极分享一切的准备。尽可能的分享一切，你所拥有的所有数据，你所提供的所有服务。鼓励不遵循原有意图的使用，提倡贡献，不要那些需要分享的内容坚持设置为私有的。在分享与发现之后，提供易于使用的浏览方式是显而易见的需求。为什么呢：话说回来，你会从别人的共享之中受益匪浅。注意：这里没有许可让你去侵犯版权保护的法律，你不能够去分享你刻录的DVD或者是拥有商业版权音乐，因为你已经同意不会去分享这些东西。但是你可以发现并分享那些完全开放的媒体内容。一个小小的建议，你可以学习一下Creative Commons license（共创协议）.

6、Web是一个平台；要让它成长。当然，我们还有很多其他的平台（Windows、Linux、Mac），但是那些已经不是重点了。换句话说，Web是无法脱离的平台，不会中断的平台，你可以通过各种方式去扩展的平台。你在Web上提供的数据与服务将会成为Web一部分，最终你会在Web平台的某一处扮演你的角色。扮演好你的角色并照顾好后来者。

7、理解与信奉“阶梯性”。现在的Web越来越大，几乎蔓延到了全世界的所有国家，并且已经拥有了10亿用户。我的观点是Web的各个组成部分存在着细微的区别和不同，就像不同地方的用户那样。例如Web的设计部分：易用性永远优先于速度、可靠性、重用性与可集成性。你也应该提供同样的体验给你的用户。它已经被一次又一次的被人们在文档中强调，忠诚的用户很快会成为专业的用户，他们期待更快的速度还有更多。退一步支持他们。同样，也有很多很多的用户会进入这个阶梯的底端，如你所期待的那样。他们可能不会说你的语言，不熟悉你的文化，甚至不知道是如何到这里的。所以你需要向他们表达清楚。

8、任何东西都是可编辑的。或者是它应该被编织的更好。要确定的是，只有很少的东西是不能被编辑的，剩下的都可以，这是一个可写的Web。这并不意味着原始内容的丢失，而通常被理解为用户能够很容易的对内容加以评论，或者评注内容是在那里发现的。如果你对此应用的好，他们能够比你所想象的做的更多（把内容串起来并且给予原始内容来创建自己的，等等）。

9、Web上的身份是神圣的。不幸的是，这并不意味着你能够得到更多的隐私（这完全是上个世纪的想法）。但对身份的验证是必要的，你应该感谢那些只需一个邮件地址就能确定你身份的服务。这意味只要你对你的用户承诺了，你就必须保证他们的隐私安全。必要的时候，在这个世界的某处你还得为你的用户挺身而出，向当地的权威挑战。如果你没有打算那样做，你就得把实际情况告诉你的用户。另一方面，如果身份是必须的，不要试图伪装它，不然在某一天我们将会在Web上放弃我们的最后一点点隐私的权利。

10、了解流行的标准并且使用他们。从一个消费者或者是创作者的立场来看，数据将会以不同的格式与任何一个人交换。同时这样的数据也会反过来促进标准的完善与采纳。这通常意味像RSS、 OPML、XHTML、Simple XML、JSON等简单标准的流行，而避免SOAP、XSD，还有RDF、ATOM也一样，使用它们会给我的内心带来痛苦。请你也为你所钟爱的标准投上一票来支持它们。

11、遵循无意使用的规律。如果你把非常有趣的数据和服务用广泛使用的格式开放和共享出去，你将会得到你所应得的，其他人也将会基于你的那一块Web平台来构建。或许还会从别人那里得到更多，所以为这个做一下准备比较好。我已记不清有多少次我看到一个播客（podcasting）服务因为流行过渡而导致服务垮掉，就是因为他们被 Slashdot和del.icio.us给收录了。这一点要知道：网络上的大量化意味着如果一个内容非常有趣，即使是一个很小的角落也会得到惊人的访问量。鼓励使用这种方式，它还是非常有价值的，前提是你要有所准备。

12、粒化你的数据与服务。我们应该在很早以前就明白这些，大规模集成的数据仅仅适用于无需管理的下载与批量操作。分解你的数据，让他们独立成可描述的URL地址，对你的服务也一样。反过来说，你不要创建一些巨大的、复杂的、像圣诞树那样的数据结构和服务。保持简单，要非常的简单。让这些分离的片断能够容易的被重组和发现。

13、提供用户能够单独受益的数据和服务。渐渐依赖于这种社会化参与是存在风险的，你需要让你的用户有一点点动机来贡献时间、热情和信息，除非他们能够直接受益。社会化分享比个体行为的利益大很多，除非你能够激发用户的个人动机，否这你将无法享受这份厚礼。

14、让用户组织并过滤信息。不一定是必须的，但却是非常重要的。让用户以他们自己的方式来标注和组织数据，因为你自己是永远无法及时的处理他们的。用户会按照他们自己理解的最佳方式来处理并构建。要保证你的Web服务能够按照用户所需所想的方式来工作。这也是标签（tagging）和通俗分类（folksonomies ）的方式如此成功的主要因素。

15、提供丰富的用户体验。Web一直都在和本地的应用程序进行着激烈的竞争。为什么？因为本地程序还是感觉上好一些，速度也快一些。但是这不会长久的（确信在5年或者15年后，这种竞争就不存在了）。是的，我在谈论Rich Internet Applications, Ajax, 还有那些不可思议的交互应用。他们让Web成为了一个真正的“无平台”的平台，如果你知道我是怎么想的。

16、信奉并支持快速改进和反馈。这个通常意味着加快步伐，但也意味着使用轻量级的工具、技术和不要做出那些适得其反的痛苦决定（例如使用一个被层层环绕的Ajax框架来代替可以通过混合来实现的，或者用C++来构建所有的东西，其实使用Ruby会更好一些）。这同时也意味着需要一个非常快速的方式来处理错误报告，修复Bug，释放新版本。从一个用户的角度来看，报告你所发现的任何问题，还有那些你经常抱怨的地方，甚至那些都不是一个Bug。

当然，Web 2.0是一个极其广泛和深奥的话题，没有一个人能够列举出它的所有重点和特征。如果你对此充满了兴趣，请花一点时间来补充我没有提到的地方。我想这就是Web 2.0的参与性吧！

原作者的这个标题借鉴了Bruce Eckel的两本畅销书的名字：《Thinking in C++》和《Thinking in Java》，《C++编程思想》与《Java编程思想》，在此说明一下为什么要这样翻译这个题目:)

indigo 翻译整理

原文出处：http://chn.blogbeta.com/119.html

通过XDoclet可以我们的精力放在编写java源文件上。

具体来说就是：
只有Java： java--->XDoclet(hibernatedoclet)--->Hbm---->SchemaExport(schemaexport,hbm2ddl)---->数据表

1:java源文件编写

/**/ /*
 * Created on 2006-4-7
  */

package  com.entity;

/** */ /**
 *  @author  jkallen
 * @hibernate.class lazy="true" table="syn_dept"
 * @hibernate.cache usage="read-write"
  */
public   class  SynDepartment  {
 
  /** */ /**  主键 id */
  private  Long id;
  /** */ /**  部门名称 */
  private  String code_name;
 
  /** */ /**
  *  @return  Returns the id.
  * @hibernate.id generator-class="native" column="id"
   */
     public  Long getId()  {
   return  id;
 }
  public   void  setId(Long id)  {
   this .id  =  id;
 }
  /** */ /**
    *  @return  Returns the code_name.
    * @hibernate.property column = "code_name"
     */
  public  String getCode_name()  {
   return  code_name;
 }
  public   void  setCode_name(String code_name)  {
   this .code_name  =  code_name;
 }
}

这里用到了几种@hibernate标记的用法
@hibernate.class标记指定类的映射代码，lazy="true" table="syn_dept"则如
hibernate的映射文件class元素的属性值具有相同的意义
@hibernate.id标记指定类的OID映射代码
@hibernate.property标记指定类的属性映射代码
另外还可能用到@hibernate.set(如一对多的情况下)

2:XDoclet--->Hbm(写在build.xml文件中，ANT运行)

< target  name ="toHbm"  
  depends ="compileEntity"  
  description ="Generate hibernate mapping documents" >
   < hibernatedoclet  destdir ="${generated.dir}" >
    < fileset  dir ="${src.dir}" >
     < include  name ="**/entity/*.java"   />
    </ fileset >
    < hibernate  version ="2.0"   />
   </ hibernatedoclet >

   < copy  todir ="${classes.dir}" >
    < fileset  dir ="${generated.dir}"   />
   </ copy >
  </ target >

通过hibernatedoclet就可以生成SynDepartment.hbm.xml映射文件
fileset顾名思义就是过滤文件了。
注：compileEntity--编译java源文件(自定义)

3:SchemaExport---->数据表

< target  name ="toddl"  depends ="init" >
   < schemaexport  properties ="${classes.dir}/hibernate.properties"  
   quiet ="no"  text ="no"  drop ="no"     
   delimiter ="&#xd;&#xa;go&#xd;&#xa;"  output ="${sql.dir}/${synup.sql.file}"
    >
    < fileset  refid ="hibernate.synup.mapping.files"   />
   </ schemaexport >
   < echo  message ="Output sql to file: ${sql.dir}/${sql.file}"   />
  </ target >
  < fileset  id ="hibernate.synup.mapping.files"  dir ="${classes.dir}" >
   < include  name ="**/entity/*.hbm.xml"   />
  </ fileset >

 通过schemaexport就向DB中生成table了。其中可能用到如下的一些属性：
 quiet：如果为yes,表示不把子DDL脚本输出到控制台
 drop：如果为yes，只执行删除数据库中的操作，但不创建新的表
 text：如果为yes，只会生成DDL脚本文件，但不会在数据库中执行DDL脚本
 output：指定存放DDL脚本文件的目录
 config：设定基于XML格式的配置文件， hbm2ddl(schemaexport)工具从这个文件中读取数据库的配置信息
 properties：设定基于java属性文件格式的配置文件，hbm2ddl(schemaexport)工具从这个文件中读取DB的配置信息
 format：设定DDL脚本中SQL语句的格式
 delimiter：为DDL脚本设置行结束符
 
 在ANT中执行：
 <target name="initOnlySynup" depends="toHbm,toddl">
 </target>
 
 OK,最后生成的映射文件如下：

<? xml version="1.0" ?>

<! DOCTYPE hibernate-mapping PUBLIC
    "-//Hibernate/Hibernate Mapping DTD 2.0//EN" 
    "http://hibernate.sourceforge.net/hibernate-mapping-2.0.dtd" >

< hibernate-mapping >
     < class
         name ="com.SynDepartment"
        table ="syn_dept"
        dynamic-update ="false"
        dynamic-insert ="false"
     >
         < cache  usage ="read-write"   />

         < id
             name ="id"
            column ="id"
            type ="java.lang.Long"
         >
             < generator  class ="native" >
             </ generator >
         </ id >

         < property
             name ="code_name"
            type ="java.lang.String"
            update ="true"
            insert ="true"
            access ="property"
            column ="code_name"
         />

         <!--
            To add non XDoclet property mappings, create a file named
                hibernate-properties-SynDepartment.xml
            containing the additional properties and place it in your merge dir.
         -->

     </ class >

</ hibernate-mapping >

 控制台中部分信息如下：

[schemaexport] drop table syn_dept cascade constraints
[schemaexport] go
[schemaexport] drop sequence hibernate_sequence
[schemaexport] go
[schemaexport] create table syn_dept (
[schemaexport] id number(19,0) not null,
[schemaexport] code_name varchar2(255),
[schemaexport] primary key (id)
[schemaexport] )

DB中已经生成syn_dept表了,快去看下吧!

参考资料：Hibernate持久化技术详解

<%@ taglib uri="/WEB-INF/self-html.tld" prefix="test" %>
<div class="formitem">
      <span class="parameter_name">所属栏目：</span>
      <span class="parameter_value">
      <test:category name="dto.id" type="17"/>
      </span>
     </div>

　　
　　web.xml配置文件中：

<!-- self Tag Library Descriptors -->
  <taglib>
    <taglib-uri>/WEB-INF/self-html.tld</taglib-uri>
    <taglib-location>/WEB-INF/self-html.tld</taglib-location>
  </taglib>
self-html.tld定义：
<taglib>
 <tlibversion>1.0</tlibversion>
 <jspversion>1.1</jspversion>
 <shortname>netedu</shortname>
  
 <tag>
  <name>category</name>
  <tagclass>com.CategoryTag</tagclass> 
  <bodycontent>empty</bodycontent>
  <info>tag here</info>  
  <attribute>
  <name>name</name>
  <required>false</required>
  <rtexprvalue>false</rtexprvalue>
  </attribute>
  <attribute>
  <name>id</name>
    
 </tag>
</taglib>

　　以后自己就有什么扩展的需要就是在这儿加参数了！


　　总算是到了标签库的定义的地方了：

/** *//**
 * @author test 
 */
public class CategoryTag extends TagSupport {
 /**//* (non-Javadoc)
     * @see javax.servlet.jsp.tagext.Tag#doStartTag()
     */
    public int doStartTag() throws JspException {
        // TODO Auto-generated method stub
        try {
            JspWriter out = pageContext.getOut();
            //jspwriter是一个隐含对象，用于向jsp网页输出内容。输出的目标由
            CategoryManager manager = getManager();
            List options=null;
            
            if(type==Constants.SORT_VALUE_ARCHIVE_YEAR)
                options=getArchiveYear();
            if(options==null||options.size()==0)
                options=UMParameterUtil.getParameters(type);
            
            if(options==null||options.size()==0)
               options= manager.getCategorys(type);
            
            BaseCategoryDTO dto;
            ParametersDTO param;
            Object o = null;

            if (bean != null)
                    o = RequestUtils.lookup(pageContext, bean, property, scope);
           
            if (o != null && (( !(o instanceof Integer))&&( !(o instanceof Long))&& (!(o instanceof List))&& (!(o 

instanceof Long[])) ))
                    throw new JspException(
                            "bean or property must be instanceof Long or List");
            
            out.print("<select " + TaglibUtil.attrFormat("name", name));
            out.print(TaglibUtil.attrFormat("id", id));
            out.print(TaglibUtil.attrFormat("multiple", multiple));
            out.print(TaglibUtil.attrFormat("class", styleClass));
            out.print(TaglibUtil.attrFormat("size", String.valueOf(size)));
            out.print(TaglibUtil.attrFormat("onchange", onchange));
            out.print(TaglibUtil.attrFormat("style", style));
            out.print(TaglibUtil.attrFormat("disable", disable));
            out.print(">");
            if (showAll) out.print("<option value=-1>不限</option>");
            if (showNull) out.print("<option value=''></option>");
                printOption(out, options, o);
  out.print("</select>");
 } catch (IOException ioException) {
            throw new JspException(ioException.getMessage());
        }//catch
        return (SKIP_BODY);
        //return super.doStartTag();
    }

　　注：
　　有options= manager.getCategorys(type);其中manager是CategoryManager类。此方法返回的一个List就是下拉框的值。具体实现可由我们自己来定义好了！记得在JSP中也有<test:category name="dto..id" type="17"/>，其中的type="17"（比如说可以是传一个DB中的一个表的一个外键）就是此方法中的初始化参数值了（关于此标签库的定义的一些setter and getter方法中也舍了）.既然是库当然要通用。这个type就是通用的一个关键入口，不过显然这样一样可读性打了几分折扣。

　　TaglibUtil.attrFormat("name", name)的方法如下：

public class TaglibUtil {

 public static String attrFormat(String attrName, Object attrValue) {
     if (attrValue!=null)
         return " " + attrName + "=" + "\"" + attrValue + "\"";
     else
         return " ";
 }
}

　　还有一个就是printOption，这个方法应该比较重要了。它负责生成了列表框的选择的值与名称。如：

 if (!excludeFlag) {
            out.print("<option "
                    + TaglibUtil.attrFormat("value", id
                            .toString()));
            out.println(TaglibUtil.attrFormat("sysValue", sysValue));
            if(o!=null){
                if(o instanceof Long){
                    if (id.equals(o)) out.print("selected ");
                }
                else
                    if(o instanceof List){
                        if (((List)o).contains(id)) 
                            out.print("selected ");  
                    }else 
                        if(o instanceof Long[]){
                            if(isSelected(id,(Long[])o))
                                out.print("selected "); 
                        }
            }
           // if (dto.getId().equals(o)) out.print("selected ");
            out.print(">");
            out.print(name);
            out.print("</option>");
        }

　　不要郁闷id是如何来的。当然是从options= manager.getCategorys(type)中来的了。

　　也许说得不是太详细，代码也有些残缺。不过实现过程基本全在这里了。我觉得它非常棒，直到我用到它的onchange,style时！简直在直接跟使用html中的list一样！

　　　out.print(TaglibUtil.attrFormat("size", String.valueOf(size)));
            out.print(TaglibUtil.attrFormat("onchange", onchange));
            out.print(TaglibUtil.attrFormat("style", style));
            out.print(TaglibUtil.attrFormat("disable", disable));

　　至少给我们指明了一些自定义标签库的经验！

丐帮 - Apache Software Foundation

在我开始学习Java的时候，Apache的Jakarta子项目还很弱小，Apache的头牌是Apache HTTPD Server(至今也还是头牌)，如今已经成了江湖第一大帮。Apache势力庞大，背后有众多大厂商的支持，例如IBM资助了apache的好几个 project，Sun则和tomcat合作密切，而BEA砸下重资在Beehive上面。有了官府的支持，Apache理所当然了成了第一大帮。不过 Apache的问题就是组织成员太复杂了，旗下各个project来自三山五岳，良莠不齐，甚至各个门下子弟还经常发生冲突，漫无纪律。例如ant是构建工具头牌，Maven又要抢山头；OJB是持久层头牌，但是Torque还不肯让位，他两位还没有把座次安排好，iBATIS也要加入丐帮......

对于这样一个没有组织纪律，自己内部互相冲突的丐帮来说，我已经不存什么好感了，除了丐帮还时不时有几个优秀的弟子，例如log4j，ant，common，他注定永远不能成为武林盟主。

少林 - Eclipse Foundation

Eclipse来头不小，直接来自IBM，并且已经得到业界众多厂商的支持，由于有官府的大力支持，Eclipse成为武林盟主的可能性很大。 Eclipse下属的各个子项目也都身怀绝技，SWT，EMF，GEF，RCP，SDO，每个都是独当一面的好手。最关键的是Eclipse是WSAD的基础，IBM很多开发人员直接为Eclipse开发，这意味着帮派和官府的直接勾结，待到IBM把Rose XDE的功能放入Eclipse，号令天下也是指日可待。

武当 - JBoss Inc

JBoss来自草莽，没有丐帮的人多势众，没有少林的官府支持，然而经过自身的努力，已经跻身江湖顶级帮派行列，并且具备了很大的发言权。 JBoss的特点是武功自成一派，旗下每个子项目都具备非常强悍的实力，但是各个子项目又可以组成一个有机的整体，组成一个阵势，发挥意想不到的威力。其中JBoss的独门武功－Hibernate则是威力最大的杀手锏，凭借这一功夫，JBoss虽然不算很大，但是已经成为了Java企业界的巨头之一，能够以自己的声音影响整个武林。

峨嵋 - Opensymphony

opensymphony不能跟上述三大帮派相比，但是她独具特色，门下弟子不多，但是各个都有绝活，因此在武林当中也站稳了脚跟。例如Webwork成为了下一代MVC框架Struts Ti的核心，OSCache是颇受欢迎的Cache产品，Quartz则是很有名的Java Job软件，Sitemesh也是一款灵巧易用的软件。所有这些虽然都不算重量级武功，但是都独当一面，在整个武林都独树一帜，令人侧目。

逍遥派 - codehaus

codehaus下面的Groovy, DamageControl, XStream, Nano, Pico, AspectWerkz武功都是犹如凌波微步般, 既实用又优雅，并且该组织背后有有ThoughWorks这样一个技术至上的咨询公司撑腰，所以它的武功都是讲究敏捷，优雅，易用，于繁重的开发工作中体味出一丝丝悠闲的乐趣，真正符合了逍遥的意境。

昆仑 - objectweb

objectweb僻处法国，远离IT全球中心，就好像昆仑远处西域一样。因而objectweb也和中原武学有很大的不同，剑走偏锋。例如objectweb的项目偏重于cluster和分布式方面的支持，例如c-jdbc，rmi-jdbc，Perseus，XAPool等等。正是因为他的剑走偏锋，才使得他不那么知名于中原武林，也正是因为剑走偏锋，才使得他独树一帜，保持了自己独有的特色。

使用迭代器（Iterators）

强大的XPath导航

快速遍历（Fast Looping）

生成一个新的XML文档对象

将一个文档对象写入文件中

转化为字符串，或者从字符串转化

通过XSLT样式化文档（Document）

        IWorkbenchPartReference partRef = window.getActivePage().getActivePartReference();

        if (partRef != null) {
            ((WorkbenchPage) window.getActivePage()).toggleZoom(partRef);
        }else{
         System.out.println("partRef is null!");
        }
    }
}

原文地址 ：http://www.blogjava.net/hopeshared/archive/2006/03/27/37641.html

原著：笑容

创作于：2004年05月03日
最后更新：2004年05月04日 21:12
版权声明：使用 创作公用版权协议

引用地址：<a href="http://oo8h.51.net/docs/regular_expression.htm">正则表达式(regular expression)</a>

前言

正则表达式是烦琐的，但是强大的，学会之后的应用会让你除了提高效率外，会给你带来绝对的成就感。只要认真去阅读这些资料，加上应用的时候进行一定的参考，掌握正则表达式不是问题。

1. 引子

　　目前，正则表达式已经在很多软件中得到广泛的应用，包括*nix（Linux, Unix等），HP等操作系统，PHP，C#，Java等开发环境，以及很多的应用软件中，都可以看到正则表达式的影子。

　　正则表达式的使用，可以通过简单的办法来实现强大的功能。为了简单有效而又不失强大，造成了正则表达式代码的难度较大，学习起来也不是很容易，所以需要付出一些努力才行，入门之后参照一定的参考，使用起来还是比较简单有效的。

例子： ^.+@.+\\..+$

　　这样的代码曾经多次把我自己给吓退过。可能很多人也是被这样的代码给吓跑的吧。继续阅读本文将让你也可以自由应用这样的代码。

　　注意：这里的第7部分跟前面的内容看起来似乎有些重复，目的是把前面表格里的部分重新描述了一次，目的是让这些内容更容易理解。

2. 正则表达式的历史

3. 正则表达式定义

　　正则表达式(regular expression)描述了一种字符串匹配的模式，可以用来检查一个串是否含有某种子串、将匹配的子串做替换或者从某个串中取出符合某个条件的子串等。

• 列目录时，　dir *.txt或ls *.txt中的*.txt就 不 是一个正则表达式,因为这里*与正则式的*的含义是不同的。

　　正则表达式是由普通字符（例如字符 a 到 z）以及特殊字符（称为元字符）组成的文字模式。正则表达式作为一个模板，将某个字符模式与所搜索的字符串进行匹配。

3.1 普通字符

　　由所有那些未显式指定为元字符的打印和非打印字符组成。这包括所有的大写和小写字母字符，所有数字，所有标点符号以及一些符号。

3.2 非打印字符

• 　　构造正则表达式的方法和创建数学表达式的方法一样。也就是用多种元字符与操作符将小的表达式结合在一起来创建更大的表达式。正则表达式的组件可以是单个的字符、字符集合、字符范围、字符间的选择或者所有这些组件的任意组合。

3.4 限定符

　　限定符用来指定正则表达式的一个给定组件必须要出现多少次才能满足匹配。有*或+或?或{n}或{n,}或{n,m}共6种。
*、+和?限定符都是贪婪的，因为它们会尽可能多的匹配文字，只有在它们的后面加上一个?就可以实现非贪婪或最小匹配。
　　正则表达式的限定符有：
　

3.5 定位符

　　用来描述字符串或单词的边界，^和$分别指字符串的开始与结束，\b描述单词的前或后边界，\B表示非单词边界。不能对定位符使用限定符。

3.6 选择

　　用圆括号将所有选择项括起来，相邻的选择项之间用|分隔。但用圆括号会有一个副作用，是相关的匹配会被缓存，此时可用?:放在第一个选项前来消除这种副作用。
　　其中?:是非捕获元之一，还有两个非捕获元是?=和?!，这两个还有更多的含义，前者为正向预查，在任何开始匹配圆括号内的正则表达式模式的位置来匹配搜索字符串，后者为负向预查，在任何开始不匹配该正则表达式模式的位置来匹配搜索字符串。

3.7 后向引用

　　对一个正则表达式模式或部分模式两边添加圆括号将导致相关匹配存储到一个临时缓冲区中，所捕获的每个子匹配都按照在正则表达式模式中从左至右所遇到的内容存储。存储子匹配的缓冲区编号从 1 开始，连续编号直至最大 99 个子表达式。每个缓冲区都可以使用 '\n' 访问，其中 n 为一个标识特定缓冲区的一位或两位十进制数。
　　可以使用非捕获元字符 '?:', '?=', or '?!' 来忽略对相关匹配的保存。

4. 各种操作符的运算优先级

　　相同优先级的从左到右进行运算，不同优先级的运算先高后低。各种操作符的优先级从高到低如下：
　

5. 全部符号解释

6. 部分例子

7. 正则表达式匹配规则

7.1 基本模式匹配

　　一切从最基本的开始。模式，是正规表达式最基本的元素，它们是一组描述字符串特征的字符。模式可以很简单，由普通的字符串组成，也可以非常复杂，往往用特殊的字符表示一个范围内的字符、重复出现，或表示上下文。例如：

^once

　　这个模式包含一个特殊的字符^，表示该模式只匹配那些以once开头的字符串。例如该模式与字符串"once upon a time"匹配，与"There once was a man from NewYork"不匹配。正如如^符号表示开头一样，$符号用来匹配那些以给定模式结尾的字符串。

bucket$

　　这个模式与"Who kept all of this cash in a bucket"匹配，与"buckets"不匹配。字符^和$同时使用时，表示精确匹配（字符串与模式一样）。例如：

^bucket$

　　只匹配字符串"bucket"。如果一个模式不包括^和$，那么它与任何包含该模式的字符串匹配。例如：模式

once

与字符串

There once was a man from NewYork
Who kept all of his cash in a bucket.

是匹配的。

　　在该模式中的字母(o-n-c-e)是字面的字符，也就是说，他们表示该字母本身，数字也是一样的。其他一些稍微复杂的字符，如标点符号和白字符（空格、制表符等），要用到转义序列。所有的转义序列都用反斜杠(\)打头。制表符的转义序列是：\t。所以如果我们要检测一个字符串是否以制表符开头，可以用这个模式：

^\t

类似的，用\n表示“新行”，\r表示回车。其他的特殊符号，可以用在前面加上反斜杠，如反斜杠本身用\\表示，句号.用\.表示，以此类推。

7.2 字符簇

在INTERNET的程序中，正规表达式通常用来验证用户的输入。当用户提交一个FORM以后，要判断输入的电话号码、地址、EMAIL地址、信用卡号码等是否有效，用普通的基于字面的字符是不够的。

所以要用一种更自由的描述我们要的模式的办法，它就是字符簇。要建立一个表示所有元音字符的字符簇，就把所有的元音字符放在一个方括号里：

[AaEeIiOoUu]

这个模式与任何元音字符匹配，但只能表示一个字符。用连字号可以表示一个字符的范围，如：

[a-z] //匹配所有的小写字母
[A-Z] //匹配所有的大写字母
[a-zA-Z] //匹配所有的字母
[0-9] //匹配所有的数字
[0-9\.\-] //匹配所有的数字，句号和减号
[ \f\r\t\n] //匹配所有的白字符

同样的，这些也只表示一个字符，这是一个非常重要的。如果要匹配一个由一个小写字母和一位数字组成的字符串，比如"z2"、"t6"或"g7"，但不是"ab2"、"r2d3" 或"b52"的话，用这个模式：

^[a-z][0-9]$

尽管[a-z]代表26个字母的范围，但在这里它只能与第一个字符是小写字母的字符串匹配。

前面曾经提到^表示字符串的开头，但它还有另外一个含义。当在一组方括号里使用^是，它表示“非”或“排除”的意思，常常用来剔除某个字符。还用前面的例子，我们要求第一个字符不能是数字：

^[^0-9][0-9]$

这个模式与"&5"、"g7"及"-2"是匹配的，但与"12"、"66"是不匹配的。下面是几个排除特定字符的例子：

[^a-z] //除了小写字母以外的所有字符
[^\\\/\^] //除了(\)(/)(^)之外的所有字符
[^\"\'] //除了双引号(")和单引号(')之外的所有字符

特殊字符"." (点，句号)在正规表达式中用来表示除了“新行”之外的所有字符。所以模式"^.5$"与任何两个字符的、以数字5结尾和以其他非“新行”字符开头的字符串匹配。模式"."可以匹配任何字符串，除了空串和只包括一个“新行”的字符串。

PHP的正规表达式有一些内置的通用字符簇，列表如下：

字符簇 含义
[[:alpha:]] 任何字母
[[:digit:]] 任何数字
[[:alnum:]] 任何字母和数字
[[:space:]] 任何白字符
[[:upper:]] 任何大写字母
[[:lower:]] 任何小写字母
[[:punct:]] 任何标点符号
[[:xdigit:]] 任何16进制的数字，相当于[0-9a-fA-F]

7.3 确定重复出现

到现在为止，你已经知道如何去匹配一个字母或数字，但更多的情况下，可能要匹配一个单词或一组数字。一个单词有若干个字母组成，一组数字有若干个单数组成。跟在字符或字符簇后面的花括号({})用来确定前面的内容的重复出现的次数。

字符簇 含义
^[a-zA-Z_]$ 所有的字母和下划线
^[[:alpha:]]{3}$ 所有的3个字母的单词
^a$ 字母a
^a{4}$ aaaa
^a{2,4}$ aa,aaa或aaaa
^a{1,3}$ a,aa或aaa
^a{2,}$ 包含多于两个a的字符串
^a{2,} 如：aardvark和aaab，但apple不行
a{2,} 如：baad和aaa，但Nantucket不行
\t{2} 两个制表符
.{2} 所有的两个字符

这些例子描述了花括号的三种不同的用法。一个数字，{x}的意思是“前面的字符或字符簇只出现x次”；一个数字加逗号，{x,}的意思是“前面的内容出现x或更多的次数”；两个用逗号分隔的数字，{x,y}表示“前面的内容至少出现x次，但不超过y次”。我们可以把模式扩展到更多的单词或数字：

^[a-zA-Z0-9_]{1,}$ //所有包含一个以上的字母、数字或下划线的字符串
^[0-9]{1,}$ //所有的正数
^\-{0,1}[0-9]{1,}$ //所有的整数
^\-{0,1}[0-9]{0,}\.{0,1}[0-9]{0,}$ //所有的小数

最后一个例子不太好理解，是吗？这么看吧：与所有以一个可选的负号(\-{0,1})开头(^)、跟着0个或更多的数字([0-9]{0,})、和一个可选的小数点(\.{0,1})再跟上0个或多个数字([0-9]{0,})，并且没有其他任何东西($)。下面你将知道能够使用的更为简单的方法。

特殊字符"?"与{0,1}是相等的，它们都代表着：“0个或1个前面的内容”或“前面的内容是可选的”。所以刚才的例子可以简化为：

^\-?[0-9]{0,}\.?[0-9]{0,}$

特殊字符"*"与{0,}是相等的，它们都代表着“0个或多个前面的内容”。最后，字符"+"与 {1,}是相等的，表示“1个或多个前面的内容”，所以上面的4个例子可以写成：

^[a-zA-Z0-9_]+$ //所有包含一个以上的字母、数字或下划线的字符串
^[0-9]+$ //所有的正数
^\-?[0-9]+$ //所有的整数
^\-?[0-9]*\.?[0-9]*$ //所有的小数

当然这并不能从技术上降低正规表达式的复杂性，但可以使它们更容易阅读。

参考文献：
JScript 和 VBScript 正则表达式

微软MSDN上的例子(英文)：

最后更新：2005年01月17日 19:54
版权声明：使用创作公用版权协议

引用地址：<a href="http://oo8h.com/docs/regular_expression.htm">正则表达式(regular expression)</a>

Trackback: http://tb.blog.csdn.net/TrackBack.aspx?PostId=630917

2005 年 11 月 10 日

读者定位为具有Java和Web开发经验的开发和设计人员。

读者可以学习到关于Cookie的工作原理和Cookie协议的细节，以及在一个HTTP应用代理的场景下Cookie的管理和处理思想，并可以直接使用文中的代码和思路，提高工作效率。

随着越来越多的系统移植到了Web上，HTTP协议具有了比以前更广泛的应用。不同的系统对WEB实现提出了不同的要求，基于HTTP协议的网络应用正趋于复杂化和多元化。很多应用需要把用户请求的页面进行处理后再返回给用户，比如页面关键字过滤，页面内容缓存、内容搜索、页面翻译等等。这些应用在实际效果上类似于一个HTTP应用代理：它们首先接受用户的请求，根据用户请求的URL去真正的目标服务器取回目标页面，再根据不同应用的要求做出相应处理后返回给用户。这样用户直接面对的就是这个HTTP应用代理，而通过它与其他页面进行交互。Cookie或Session技术的应用，解决了HTTP协议的一个问题 -- 无法保持客户状态，因此它现在被广泛应用于各种Web站点中。上面提到的那些应用如果不能处理好Cookie和Session的传递、更新和废除等问题，就会极大的限制它们所能处理站点的范围，因此如何在HTTP应用代理中正确处理Cookie，成为一个必须解决的问题。本文结合在页面翻译（Machine Translation System）项目中对于Cookie的处理方法，探讨一下这方面的解决方案。

MTS项目简介及讨论前提

Machine Translation System（以下简称MTS）是一个在线实时页面翻译系统，为用户在线提供把英文页面翻译成其他9种语言的服务。用户通过向MTS系统提交一个类似下面的URL使用此服务，其中参数url指明了用户所需要翻译的目标地址，参数language指明了所需翻译成的目标语言，www.mts.com是假想中提供MTS服务的站点。

HTTP://www.mts.com/translate?url=http://www.ibm.com/&language=French

一个完整的MTS系统处理过程可以分解成以下几个步骤：

• 用户向MTS提交合适的URL。
• MTS在接到用户的请求后，解析出用户需要翻译的目标地址和目标语言，根据用户请求的目标地址，把请求转发到目标服务器。
• MTS接受来自目标服务器的应答，包括页面信息和HTTP头信息。
• MTS在确定得到正确的目标页面后，把页面内容送入WebSphere Translation Server进行翻译。
• 把翻译后的页面连同修改后的HTTP头信息提交给用户。

当然，这其中涉及到很多的应用处理。比如与各种HTTP/HTTPS站点建立联结、根据HTTP头信息进行页面跳转和错误处理、为始终保持用户在翻译模式下而对目标的HTML页面进行分析和修改，根据系统设置对某些DNT（Do Not Translate）的页面进行过滤和跳转，当然还有对Cookie的处理等等。其他问题跟这篇文章关联不大，我们重点讨论在这种情况下的Cookie处理。Cookie跟随目标服务器的HTTP头信息被MTS接收到，经过MTS整理之后发给客户端浏览器。MTS在接到下一次用户对同一个站点的翻译请求时，再把从客户端得到的Cookie发送给目标服务器。

在以上的场景中，MTS充当的作用类似于一种HTTP应用代理服务器，它代替用户取得目标页面，并在作出相应处理后再提交给用户。当然，这种代理服务器不需要用户修改浏览器的代理服务器参数或者网络配置，而只是简单的在浏览器的地址栏中输入一个MTS能够识别的URL即可。此篇文章也是在这样一个应用场景的基础上，展开对HTTP应用代理服务器如何处理Cookie的讨论。

问题的产生

在MTS系统中，目标服务器的Cookie在两个地方会产生问题。当MTS接收目标服务器应答的时候，Cookie随着HTTP头信息被MTS接收到的。这时候目标服务器认为MTS就是最终客户，因此它赋予了Cookie与目标服务器相符的属性。而如果MTS把这些Cookie原封不动的保存在HTTP头信息中，传给真正的最终用户的话，用户的浏览器会因为这些Cookie不合法而忽略它们。同理，当Cookie从浏览器端传回目标服务器的时候，也会遇到相同的问题。因此有必要对Cookie进行一些处理，以保证用户的浏览器能真正识别和利用这些Cookie。

但是为何用户浏览器无法识别从目标服务器传过来的原始Cookie呢？这是因为出于安全性的考虑，Cookie规范制定的时候对Cookie的产生和接受设置了一些严格的规范，不符合这些规范的Cookie，浏览器和服务器都将予以忽略。下面我们从Cookie规范入手进行介绍。

Cookie的规范介绍

目前有以下几种Cookie规范：

• Netscape cookie草案：是最早的cookie规范，基于rfc2109。尽管这个规范与rc2109有较大的差别，但是很多服务器都与之兼容。
• rfc2109， 是w3c发布的第一个官方cookie规范。理论上讲，所有的服务器在处理cookie(版本1)时，都要遵循此规范。遗憾的是，这个规范太严格了，以致很多服务器不正确的实施了该规范或仍在使用Netscape规范。
• rfc2965规范定义了cookie版本2，并说明了cookie版本1的不足。

rfc2965规范的使用，目前并不多。rfc2109规范相应要严格得多，在实际应用上，并不是所有的浏览器和Web服务器都严格遵守。因此相比较而言，Netscape cookie草案倒是一个比较简洁和被广泛支持的Cookie规范，因此我们在这里以Netscape cookie草案为基础进行讨论，对于其他两种规范，我们的讨论和代码具有相同的意义。关于Netscape cookie草案的细节，大家可以参照Netscape官方站点，这里我们列举一些和我们讨论有关的内容。

根据Netscape cookie草案的描述，Cookie 是Web 服务器向用户的浏览器发送的一段ASCII码文本。一旦收到Cookie，浏览器会把Cookie的信息片断以"名/值"对(name-value pairs)的形式储存保存在本地。这以后，每当向同一个Web 服务器请求一个新的文档时，Web 浏览器都会发送之站点以前存储在本地的Cookie。创建Cookie的最初目的是想让Web服务器能够通过多个HTTP请求追踪客户。有些复杂的网络应用需要在不同的网页之间保持一致，它们需要这种会话状态的保持能力。

浏览器与Web服务器通过HTTP协议进行通讯，而Cookie就是保存在HTTP协议的请求或者应答头部（在HTTP协议中，数据包括两部分，一部分是头部，由一些名值对构成，用来描述要被传输数据的一些信息。一部分是主体(body)，是真正的数据（如HTML页面等））进行传送的。

在HTML文档被发送之前，Web服务器通过传送HTTP 包头中的Set-Cookie 消息把一个cookie 发送到用户的浏览器中。下面是一个遵循Netscape cookie草案的完整的Set-Cookie 头：

												
														Set-Cookie：customer=huangxp; path=/foo; domain=.ibm.com; 
expires= Wednesday, 19-OCT-05 23:12:40 GMT; [secure]

												
										

Set-Cookie的每个属性解释如下：

• Customer=huangxp 一个"名称＝值"对，把名称customer设置为值"huangxp"，这个属性在Cookie中必须有。
• path=/foo 控制哪些访问能够触发cookie 的发送。如果没有指定path，cookie 会在所有对此站点的HTTP 传送时发送。如果path=/directory，只有访问/directory 下面的网页时，cookie才被发送。在这个例子中，用户在访问目录/foo下的内容时，浏览器将发送此cookie。如果指定了path，但是path与当前访问的url不符，则此cookie将被忽略。
• domain=.ibm.com 指定cookie被发送到哪台计算机上。正常情况下，cookie只被送回最初向用户发送cookie 的计算机。在这个例子中，cookie 会被发送到任何在.ibm.com域中的主机。如果domain 被设为空，domain 就被设置为和提供cookie 的Web 服务器相同。如果domain不为空，并且它的值又和提供cookie的Web服务器域名不符，这个Cookie将被忽略。
• expires= Wednesday, 19-OCT-05 23:12:40 GMT 指定cookie 失效的时间。如果没有指定失效时间，这个cookie 就不会被写入计算机的硬盘上，并且只持续到这次会话结束。
• secure 如果secure 这个词被作为Set-Cookie 头的一部分，那么cookie 只能通过安全通道传输（目前即SSL通道）。否则，浏览器将忽略此Cookie。

一旦浏览器接收了cookie，这个cookie和对远端Web服务器的连续请求将一起被浏览器发送。例如 前一个cookie 被存入浏览器并且浏览器试图请求URL http://www.ibm.com/foo/index.html 时，下面的HTTP 包头就被发送到远端的Web服务器。

GET /foo/index.html HTTP/1.0
Cookie：customer=huangxp

一次典型的网络浏览过程

在了解了Cookie协议的一些基本内容之后，让我们看看一次典型的网络浏览过程中浏览器如何识别和处理Cookie：

• 浏览器对于Web服务器应答包头中Cookie的操作步骤：
  1. 从Web服务器的应答包头中提取所有的cookie。
  2. 解析这些cookie的组成部分（名称，值，路径等等）。
  3. 判定主机是否允许设置这些cookie。允许的话，则把这些Cookie存储在本地。
• 浏览器对Web服务器请求包头中所有的Cookie进行筛选的步骤：
  1. 根据请求的URL和本地存储cookie的属性，判断那些Cookie能被发送给Web服务器。
  2. 对于多个cookie，判定发送的顺序。
  3. 把需要发送的Cookie加入到请求HTTP包头中一起发送。

由MTS代理的网络浏览过程

以上我们了解了在一个典型的浏览器与Web服务器交互的时候，Cookie的传递过程。下面我们将看到，如果在MTS代理网络浏览的过程中，不对Cookie进行修改，上面的Cookie传递过程将无法实现。

1. 假设用户希望把http://www.ibm.com/foo/index.html页面翻译成法文，应该使用如下的url对MTS发出请求

：

HTTP://www.mts.com/translate?url=http://www.ibm.com/foo/index.html&language=French

2. MTS接收用户的请求，连接远程目标服务器http://www.ibm.com/foo/index.html。目标服务器做出应答，返回HTTP头和HTML页面内容。其中，典型的HTTP头内容如下：

												
														HTTP/1.1 200 OK
Date: Mon, 24 Oct 2005 06:54:41 GMT
Server: IBM_HTTP_Server
Cache-Control: no-cache
Content-Length: 19885
Connection: close
Set-Cookie：customer=huangxp; path=/foo; domain=.ibm.com; 
expires= Wednesday, 19-OCT-05 23:12:40 GMT
Content-Type: text/html

												
										

3. MTS不对Set-Cookie后的内容作任何处理，直接把它加到用户浏览器的应答头上发送给浏览器。

4. 浏览器将从Set-Cookie中解析出domain和path的值，分别是.ibm.com和/foo，并与请求的url：HTTP://www.mts.com/translate?url=http://www.ibm.com/foo/index.html&language=French进行比较。请求url的domain是www.mts.com，path是/，与Set-Cookie中的属性不符，所以浏览器将忽略此Cookie。

另外，在浏览器发送Cookie的时候也会遇到同样的问题，同样如上例，如果浏览器里本来已经存储了http://www.ibm.com/foo/的Cookie，但由于用户要通过MTS访问此站点，浏览器经不会把已经存储的Cookie上转到MTS中，MTS也就无法把之传递到http://ibm.com/foo/上。

基于上面Cookie规范的介绍和例证，我们能看出，浏览器在接受某一个站点的Cookie的时候，需要检查Cookie的参数domain、path、secure，看是否与当前的站点和URL相符，如果不符的话，就会忽略。另一方面。浏览器在上传Cookie的时候，也会根据当前所访问站点的属性，上传相关的Cookie，而其他的Cookie则不予上传。

至此，我们讨论了需要修改Cookie的根本原因在于Cookie规范的限制。下面我们讨论两种解决问题的思路。

解决问题的两种思路

Cookie的存在是要解决HTTP协议本身先天的缺陷-无状态性，它为用户保存了一些需要的状态信息。因此我们解决此问题的最本质的出发点，也就是找到一种途径能为用户保存Cookie所提供用户状态信息，实际上就是Name/Value对。

思路一

第一种思路就是修改目标服务器取得的Cookie，使之符合MTS站点的属性，然后作为MTS站点的Cookie存储到用户的浏览器中去。当然，这种修改必须保留原始Cookie的所有属性值，当以后访问同一个目标服务器的时候，MTS能根据保存的属性值还原出原始Cookie，然后进行提交。

具体到属性值的保存位置，没有太多选择的余地，实际上，domain，path，secure，expires这几个属性都无法利用，只有利用name=value这一属性对。我们的做法是创造一个新的Cookie，把原始Cookie的domain，path的值与name值进行编码，用分隔符附加在Name值的后面，符值给新的Cookie。这样做也同时避免了不同目标服务器如果出现同名的Cookie，将会互相覆盖的情况（Cookie规范里面也规定了，客户端以domain，path，name作为Cookie的唯一标示）。而原始Cookie的secure和expires值，直接符给新的Cookie，新Cookie的domain和path设成缺省值，这样，新Cookie就可以被浏览器正常接受。由于浏览器接受的所有Cookie的domain和path值都一样，因此每次用户对MTS提出请求时，浏览器都会把所有与MTS站点相关的Cookie上传，因此，MTS还需要还原原始的Cookie，过滤掉与目标服务器不相干的Cookie，然后上传有用的Cookie。

这种思路的优点在于Cookie存储在客户端，可以做到长期存储，浏览器自己根据Cookie的expires值做出判断，省掉很多开发的麻烦。缺点是转换的过程相对较复杂。另外还有一个缺点，也是由于Cookie规范的限制所造成的。Cookie规范对于一个浏览器同时能够存储的Cookie数量作出了规定。

• 总共300 个cookie
• 每个Cookie 4 K 的存储容量
• 每一个domain 或者 server 20 个cookie。

以上是浏览器所应达到的最小存储数量，超出这个限制，浏览器应该自动按照最少最近被使用的原则删除超出得Cookie。由于用户有可能通过MTS这一个网站翻译大量的目标服务器，因此浏览器存储在MTS的domain下的cookie数量就很有可能超过20个，这时候就会导致某些Cookie被删除。一般这也不会造成太大问题，因为规范是要求浏览器删除最少最近被使用的Cookie，但我们在实际测试当中发现有些浏览器并不遵守这样的规范，而是删除最新的Cookie，这就将导致用户很大的不便。

思路二

第二种思路在于把原始的Cookie组织成dataBean，存储到用户的Session当中去。这样，在用户端只需要存储一个SessionID的Cookie，而不需要存储所有目标服务器的每一个Cookie。另外，当接收到用户的又一次翻译请求时，再从Session当中取出所有的dataBean，逐一进行分析，找出与用户所请求的目标服务器相符的原始Cookie，进行提交。

这种思路可以克服上一种思路中Cookie超过标准数量时的缺陷，而且不需编码保存原始的Cookie属性值，减少了程序的复杂度。缺点是需要程序员自己处理expires。而且由于是把Cookie存储在Session中，一旦Session失效，所有Cookie都将被删除，所以，无法保存那些长期的Cookie。

总之，两种思路各有利弊，在实际应用当中要权衡考虑。下面我们针对两种思路进行技术实现，分别对应方案一和方案二。

由于MTS需要与目标服务器连接，遵循HTTP协议读取和返回Cookie，但是如果用JDK中的java.net.URLConnection处理Cookie将非常不方便，因此我们使用HTTPClient来处理与目标服务器的连接。

方案一：Cookie存储在浏览器端

用户每发起一次新的请求，浏览器在检查完本地存储Cookie的有效性后，会把所有由MTS产生的有效Cookie附加在请求头里送到MTS。MTS接受到客户端的翻译请求后，从Request中提取出所有的Cookie，还原后根据目标服务器的domain和path进行过滤。产生所有与目标服务器相关的Cookie。

												
														//从request中获取所有的Cookie
javax.servlet.http.Cookie[] theCookies = request.getCookies();
ArrayList cookiesList = new ArrayList();
String url = request.getParameter("url");
String domain = URLUtil.getURLHost(url);
String path = URLUtil.getPath(url);

if (theCookies != null)
{
	for (int i = 0; i < theCookies.length; i++)
	{
		RE r = new RE();
         //用正则表达式把name项还原成domain，path，name
		REDebugCompiler compiler = new REDebugCompiler();
		r.setProgram(compiler.compile("\\|\\|"));
		String[] values = r.split(theCookies[i].getName());
		//"9.181.116.183||/MTModule||testCookie:value1" or " ||              
		||testCookie:value1"
		if (values.length == 3)
		{
			if (values[0].trim().startsWith("."))
			{
				if (!domain.endsWith(values[0].trim()))
					continue;
			} else if (!domain.endsWith("://" + values[0].trim()))
					continue;
			if (!path.startsWith(values[1].trim()))
				continue;

			Cookie tempCookie = new Cookie();
			tempCookie.setDomain(
				("".equals(values[0].trim())) ? null : values[0]);
			tempCookie.setPath(
				("".equals(values[1].trim())) ? null : values[1]);
			tempCookie.setName(
				("".equals(values[2].trim())) ? null : values[2]);
			tempCookie.setSecure(theCookies[i].getSecure());
			tempCookie.setValue(theCookies[i].getValue());
			tempCookie.setVersion(theCookies[i].getVersion());
			tempCookie.setComment(theCookies[i].getComment());
			cookiesList.add(tempCookie);
		}
	}
}
//transferedCookie用来存储将被传到目标服务器的Cookie
Cookie[] transferedCookie = new Cookie[cookiesList.size()];
cookiesList.toArray(transferedCookie);

												
										

接下来，需要把Cookie送到目标服务器中。我们使用HTTPClient与目标服务器连接。HTTPClient在与目标服务器连接以后，允许服务器设置Cookie并在需要的时候自动将Cookie返回服务器，也支持手工设置 Cookie后发送到服务器端。但是，由于如何处理cookie有几个规范互相冲突：Netscape Cookie 草案、RFC2109、RFC2965，而且还有很大数量的软件商的Cookie实现不遵循任何规范。 为了处理这种状况，需要把HttpClient设置成Cookie兼容模式，这样可以最大限度的处理好各种Cookie。下面的代码把Cookie送到目标服务器。

												
														HttpClient client = new HttpClient();
//从request得到所有需要传输的cookie 
Cookie[] questCookie = getCookieFromRequest(request);
//设置HTTPClient为Cookie兼容模式
client.getState().setCookiePolicy(CookiePolicy.COMPATIBILITY);
if (questCookie.length > 0)
//把Cookie加到httpclient中
	client.getState().addCookies(questCookie);
HttpMethod method = new GetMethod(TagerURL);
 //向目标服务器发送请求
int statusCode = client.executeMethod(method);
method.releaseConnection();

												
										

MTS把请求和Cookie送出后，继续接收目标服务器的应答，读取返回的原始Cookie，并转换成可以存储在用户浏览器端的Cookie。下面的代码将对原始Cookie的内容进行变换，保留expires和secure等项，把domain和path项编码到name中去。

												
														//从HTTPClient中取得所有的Cookie
Cookie[] temp = client.getState().getCookies();
if (temp != null)
{
	javax.servlet.httpCookie theCookie = new javax.servlet.http.Cookie[temp.length];
     //逐一对Cookie进行处理
	for (int i = 0; i < temp.length; i++)
	{    StringBuffer sb = new StringBuffer();
        //编码成domain||path||name
        sb.append(
        	temp[i].getDomain() == null ? " " : temp[i].getDomain());
        sb.append("||");
        sb.append(temp[i].getPath() == null ? " " : temp[i].getPath());
        sb.append("||");
        sb.append(temp[i].getName() == null ? " " : temp[i].getName());
        theCookie[i] =
        	new Cookie(sb.toString(),temp[i].getValue());
        //复制其他项
        theCookie[i].setMaxAge(theCookie[i].getMaxAge();
        theCookie[i].setSecure(temp[i].getSecure());
        theCookie[i].setVersion(temp[i].getVersion());
        theCookie[i].setComment(temp[i].getComment());
	}
}

												
										

最后一步，把这些Cookie保存到response里，随HTTP应答头返回用户浏览器。并保存在浏览器中。

												
														//把所有转换后的Cookie加入response
for (int i = 0; i < theCookie.length; i++) {
	response.addCookie(theCookie[i]);
}

												
										

至此，我们已经完成了接收用户请求，转换Cookie，发送到目标服务器，接收目标服务器的原始Cookie，并保存在客户浏览器的整个处理过程。

方案二：Cookie存储在服务器端

在此种方案中，目标服务器返回给MTS的Cookie将被组织成dataBean，存储在用户的Session中。因此，我们首先生成一个用来存储Cookie的类CookiesBean，根据它的特性，它可以继承ArraryList类。此对象将存储用户访问目标服务器时接收到的所有Cookie，并提供与新接收到的Cookie融合的功能，同时能够删除过期的Cookie，更新同名的Cookie。

												
														public class CookiesBean extends ArrayList
{
	/**
	 * 处理Cookies.
	 * @参数 Cookies array
	 */
	public CookiesBean(Cookie[] cook)
	{
		if (cook == null)
			return;
//add all cookie which isn't expired.
		for (int i = 0; i < cook.length; i++)
		{
			if (!cook[i].isExpired())
			{
				add(cook[i]);
			}
		}
	}

	/**
	 * 融合参数中的bean
	 * @参数 bean
	 * 参考: rfc2109 4.3.3  Cookie Management
	 */
	public void RefreshBean(CookiesBean bean)
	{
		if (bean == null)
			return;

		Iterator it = bean.iterator();
         //针对bean中的每一个Cookie进行处理
		while (it.hasNext())
		{
			Cookie beanCookie = (Cookie) it.next();
			if (beanCookie == null) continue;

			ArrayList drop = new ArrayList();
			Iterator thisIt = iterator();
              //取出存储的Cookie进行比较和处理
			while (thisIt.hasNext())
			{
				Cookie thisCookie = (Cookie) thisIt.next();
				if (thisCookie == null) continue;
                   //比较name，domain和path,如果一样的话，则把此Cookie移到drop中
				if (CommonMethods
					.CompString(beanCookie.getName(), thisCookie.getName())
					&& CommonMethods.CompString(
						beanCookie.getDomain(),
						thisCookie.getDomain())
					&& CommonMethods.CompString(
						beanCookie.getPath(),
						thisCookie.getPath()))
				{
					drop.add(thisCookie);
					continue;
				}
                  //删除过期的Cookie
				if (thisCookie.isExpired())
					drop.add(thisCookie);
			}
             //删除所有drop中的Cookie
			this.removeAll(drop);
             //如果beanCookie有效，则加入到存储区中。
			if (!beanCookie.isExpired())
				add(beanCookie);
		}

		return;
	}
}	

												
										

当MTS接受到客户端的翻译请求后，会从Session中提取出所有的dataBean，并得到存储的所有Cookie。如以下代码：

												
																		CookiesBean dataBean = null;
		Cookie[] theCookies = new Cookie[0];
		ArrayList cookiesList = new ArrayList();
         //获得Session，并获得dataBean
		HttpSession session = request.getSession(false);
		if (session != null)
		{
			dataBean = (CookiesBean) session.getAttribute(SESSION_NAME);
		}
		else
		{
			return theCookies;
		}
		
												
										

MTS在所有的存储的Cookie中，检查Cookie的Domain、path和secure的值，筛选出符合目标服务器的Cookie。

												
																		//提取目标服务器的domain和path
		String url = context.getURL();
		String domain = URLUtil.getURLHost(url);
		String path = url.substring(domain.length());
		
		String cookiedomain = null;
		String cookiepath = null;
		//逐个比较Cookie的domain和path
		//把符合要求的Cookie纪录到cookiesList中
		for (int i = 0; i < dataBean.size(); i++)
		{
			Cookie cookie = (Cookie) dataBean.get(i);
			if (cookie == null) continue;
			cookiedomain =
				(cookie.getDomain() == null) ? "" : cookie.getDomain();
			cookiepath = (cookie.getPath() == null) ? "  " : cookie.getPath();

			if (!path.startsWith(cookiepath))
				continue;

			if (cookiedomain.startsWith("."))
			{
				if (!domain.endsWith(cookiedomain))
					continue;
			}
			else if (!domain.endsWith("://" + cookiedomain))
				continue;
			if (cookie.isExpired())
				continue;
			if (cookie.getSecure() && url.toLowerCase().startsWith("http:"))
				continue;

			cookiesList.add(cookie);
		}
		theCookies = new Cookie[cookiesList.size()];
		cookiesList.toArray(theCookies);
		return theCookies;
		
												
										

把Cookie送到目标服务器的代码与方案一基本一样，在此忽略。

最后一步，需要把Cookie存储到Session中。下面的代码将从目标服务器接受Cookie，融入到dataBean中，并保存到客户的Session中。

												
																//从目标服务器得到Cookie集
     Cookie[] cookies = client.getState().getCookies();
	CookiesBean bean = new CookiesBean(cookies);
     CookiesBean dataBean = bean;

     //取得用户Session
	HttpSession session =  request.getSession(false);
	if (session != null)
	{
		if (session.getAttribute(SESSION_NAME) != null)
		{
              //读取Session中存取的dataBean
			dataBean = (CookiesBean) session.getAttribute(SESSION_NAME);
              //目标服务器端的Cookie融合到Session中的dataBean中
			dataBean.RefreshBean(bean);
		}
         //把最终的dataBean存入Session中
		session.setAttribute(SESSION_NAME, dataBean);
	}
	
												
										

至此，我们已经完成了在Session中保存个目标服务器所产生Cookie的整个处理过程。

关于Session的考虑

在研究完如何管理和传递Cookie之后，我们也需要研究一下Session的传递。因为目前大部分站点都在采用Session机制保存用户状态数据，如果不能解决Session的传递问题，HTTP应用代理服务器的适用范围同样会大打折扣。

首先我们了解一下Session的实现机制。Session是一种服务器端的机制，服务器使用一种类似于散列表的结构来保存信息。当程序需要为某个客户端的请求创建一个session的时候，服务器首先检查这个客户端的请求里是否已包含了一个session标识 - 称为session id，如果已包含一个session id则说明以前已经为此客户端创建过session，服务器就按照session id把这个session检索出来使用（如果检索不到，可能会新建一个），session id的值应该是一个既不会重复，又不容易被找到规律以仿造的字符串。

保存这个session id的方式之一就是采用Cookie。一般这个Cookie的名字都类似于 SESSIONID。比如WebSphere对于Web应用程序生成的Cookie：JSESSIONID= 0001HWF4iVD94pY8Cpbx6U4CXkf:10lro0398，它的名字就是 JSESSIONID。

保存session id的其他方式还包括URL重写和表单隐藏字段。这两种方式都不需要代理服务器作特殊处理。因此实际上，我们解决了Cookie的管理和传递的问题之后，也就解决了Session的管理和传递。

结束语

从上面的讨论中可以看出，由于Cookie本身的规范限制，HTTP应用代理所必需面对的一个问题就是如何对Cookie进行正确的处理。本文对此提出了两种解决思路并列出了实现代码。对于MTS项目本身，我们使用的是第二种方案。开发人员在认识好Cookie本身的特性之后，参照本文的思路，根据自己系统的特点，也会找出更适宜的解决方案。

参考资料

• Netscape Cookie Specification 对Netscape Cookie 使用的特性进行了简要的介绍。
  
  
• RFC2965：HTTP State Management Mechanism 介绍了HTTP 状态管理机制
  
  
• RFC2109 w3c发布的第一个官方cookie规范
  
  
• RFC2616：Hypertext Transfer Protocol 超文本传输协议
  
  
• Ronald Tschalr开发了 HTTPClient，将其作为 URLConnection 的替代品。
  
  
• Jakarta Regexp Apache 的开源项目，处理正则表达式的java包。

测试环境：

　　AMD毒龙1.4G OC 1.5G、256M DDR333、Windows2000 Server SP4、Sun JDK 1.4.1+Eclipse 2.1+Resin 2.1.8，在Debug模式下测试。

　　XML文件格式如下：

　　<?xml version="1.0" encoding="GB2312"?><RESULT><VALUE>

　　<NO>A1234</NO>

　　<ADDR>四川省XX县XX镇XX路X段XX号</ADDR></VALUE><VALUE>

　　<NO>B1234</NO>

　　<ADDR>四川省XX市XX乡XX村XX组</ADDR></VALUE></RESULT>

测试方法：

　　让每一种方案分别解析10K、100K、1000K、10000K的XML文件，计算其消耗时间(单位:毫秒)。

　　JSP文件：

　　<%@ page contentType="text/html; charset=gb2312" %><%@ page import="com.test.*"%>

　　<html><body><%String args[]={""};MyXMLReader.main(args);%></body></html>

　　测试

　　首先出场的是DOM(JAXP Crimson解析器)

　　DOM是用与平台和语言无关的方式表示XML文档的官方W3C标准。DOM是以层次结构组织的节点或信息片断的集合。这个层次结构允许开发人员在树中寻找特定信息。分析该结构通常需要加载整个文档和构造层次结构，然后才能做任何工作。由于它是基于信息层次的，因而DOM被认为是基于树或基于对象的。DOM以及广义的基于树的处理具有几个优点。首先，由于树在内存中是持久的，因此可以修改它以便应用程序能对数据和结构作出更改。它还可以在任何时候在树中上下导航，而不是像SAX那样是一次性的处理。DOM使用起来也要简单得多。

　　另一方面，对于特别大的文档，解析和加载整个文档可能很慢且很耗资源，因此使用其他手段来处理这样的数据会更好。这些基于事件的模型，比如SAX。

　　Bean文件：

　　package com.test;

　　import java.io.*;import java.util.*;import org.w3c.dom.*;import javax.xml.parsers.*;

　　public class MyXMLReader{

　　public static void main(String arge[]){

　　long lasting =System.currentTimeMillis();

　　try{

　　　File f=new File("data_10k.xml");

　　　DocumentBuilderFactory factory=DocumentBuilderFactory.newInstance();

　　　DocumentBuilder builder=factory.newDocumentBuilder();

　　　Document doc = builder.parse(f);

　　　NodeList nl = doc.getElementsByTagName("VALUE");

　　　for (int i=0;i<nl.getLength();i++){

　　　　System.out.print("车牌号码:" + doc.getElementsByTagName("NO").item(i).getFirstChild().getNodeValue());

　　　　System.out.println("车主地址:" + doc.getElementsByTagName("ADDR").item(i).getFirstChild().getNodeValue());

　　}

　　}catch(Exception e){

　　　e.printStackTrace();

　　}

　　System.out.println("运行时间："+(System.currentTimeMillis() - lasting)+"毫秒");}}

　　10k消耗时间：265 203 219 172

　　100k消耗时间：9172 9016 8891 9000

　　1000k消耗时间：691719 675407 708375 739656

　　10000k消耗时间：OutOfMemoryError

　　接着是SAX

　　这种处理的优点非常类似于流媒体的优点。分析能够立即开始，而不是等待所有的数据被处理。而且，由于应用程序只是在读取数据时检查数据，因此不需要将数据存储在内存中。这对于大型文档来说是个巨大的优点。事实上，应用程序甚至不必解析整个文档；它可以在某个条件得到满足时停止解析。一般来说，SAX还比它的替代者DOM快许多。
　　选择DOM还是选择SAX？

　　对于需要自己编写代码来处理XML文档的开发人员来说，

　　选择DOM还是SAX解析模型是一个非常重要的设计决策。

　　DOM采用建立树形结构的方式访问XML文档，而SAX采用的事件模型。

　　DOM解析器把XML文档转化为一个包含其内容的树，并可以对树进行遍历。用DOM解析模型的优点是编程容易，开发人员只需要调用建树的指令，然后利用navigation APIs访问所需的树节点来完成任务。可以很容易的添加和修改树中的元素。然而由于使用DOM解析器的时候需要处理整个XML文档，所以对性能和内存的要求比较高，尤其是遇到很大的XML文件的时候。由于它的遍历能力，DOM解析器常用于XML文档需要频繁的改变的服务中。

　　SAX解析器采用了基于事件的模型，它在解析XML文档的时候可以触发一系列的事件，当发现给定的tag的时候，它可以激活一个回调方法，告诉该方法制定的标签已经找到。SAX对内存的要求通常会比较低，因为它让开发人员自己来决定所要处理的tag。特别是当开发人员只需要处理文档中所包含的部分数据时，SAX这种扩展能力得到了更好的体现。但用SAX解析器的时候编码工作会比较困难，而且很难同时访问同一个文档中的多处不同数据。

　　Bean文件：

　　package com.test;import org.xml.sax.*;import org.xml.sax.helpers.*;import javax.xml.parsers.*;

　　public class MyXMLReader extends DefaultHandler {

　　java.util.Stack tags = new java.util.Stack();

　　public MyXMLReader() {

　　super();}

　　public static void main(String args[]) {

　　long lasting = System.currentTimeMillis();

　　try {

　　　SAXParserFactory sf = SAXParserFactory.newInstance();

　　　SAXParser sp = sf.newSAXParser();

　　　MyXMLReader reader = new MyXMLReader();

　　　sp.parse(new InputSource("data_10k.xml"), reader);

　　} catch (Exception e) {

　　　e.printStackTrace();

　　}

　　System.out.println("运行时间：" + (System.currentTimeMillis() - lasting) + "毫秒");}

　　public void characters(char ch[], int start, int length) throws SAXException {

　　String tag = (String) tags.peek();

　　if (tag.equals("NO")) {

　　　System.out.print("车牌号码：" + new String(ch, start, length));}if (tag.equals("ADDR")) {

　　System.out.println("地址:" + new String(ch, start, length));}}

　　public void startElement(String uri,String localName,String qName,Attributes attrs) {

　　tags.push(qName);}}

　　10k消耗时间：110 47 109 78

　　100k消耗时间：344 406 375 422

　　1000k消耗时间：3234 3281 3688 3312

　　10000k消耗时间：32578 34313 31797 31890 30328

　　然后是JDOM http://www.jdom.org/

　　JDOM的目的是成为Java特定文档模型，它简化与XML的交互并且比使用DOM实现更快。由于是第一个Java特定模型，JDOM一直得到大力推广和促进。正在考虑通过“Java规范请求JSR-102”将它最终用作“Java标准扩展”。从2000年初就已经开始了JDOM开发。

　　JDOM与DOM主要有两方面不同。首先，JDOM仅使用具体类而不使用接口。这在某些方面简化了API，但是也限制了灵活性。第二，API大量使用了Collections类，简化了那些已经熟悉这些类的Java开发者的使用。

　　JDOM文档声明其目的是“使用20%(或更少)的精力解决80%(或更多)Java/XML问题”(根据学习曲线假定为20%)。JDOM对于大多数Java/XML应用程序来说当然是有用的，并且大多数开发者发现API比DOM容易理解得多。JDOM还包括对程序行为的相当广泛检查以防止用户做任何在XML中无意义的事。然而，它仍需要您充分理解XML以便做一些超出基本的工作(或者甚至理解某些情况下的错误)。这也许是比学习DOM或JDOM接口都更有意义的工作。

　　JDOM自身不包含解析器。它通常使用SAX2解析器来解析和验证输入XML文档(尽管它还可以将以前构造的DOM表示作为输入)。它包含一些转换器以将JDOM表示输出成SAX2事件流、DOM模型或XML文本文档。JDOM是在Apache许可证变体下发布的开放源码。

　　Bean文件：

　　package com.test;

　　import java.io.*;import java.util.*;import org.jdom.*;import org.jdom.input.*;

　　public class MyXMLReader {

　　public static void main(String arge[]) {

　　long lasting = System.currentTimeMillis();

　　try {

　　　SAXBuilder builder = new SAXBuilder();

　　　Document doc = builder.build(new File("data_10k.xml"));

　　　Element foo = doc.getRootElement();

　　　List allChildren = foo.getChildren();

　　　for(int i=0;i<allChildren.size();i++) {

　　　　System.out.print("车牌号码:" + ((Element)allChildren.get(i)).getChild("NO").getText());

　　　　System.out.println("车主地址:" + ((Element)allChildren.get(i)).getChild("ADDR").getText());

　　　}

　　} catch (Exception e) {

　　　e.printStackTrace();

　　}

　　System.out.println("运行时间：" + (System.currentTimeMillis() - lasting) + "毫秒");}}

　　10k消耗时间：125 62 187 94

　　100k消耗时间：704 625 640 766

　　1000k消耗时间：27984 30750 27859 30656

　　10000k消耗时间：OutOfMemoryError

　　最后是DOM4J http://dom4j.sourceforge.net/

　　虽然DOM4J代表了完全独立的开发结果，但最初，它是JDOM的一种智能分支。它合并了许多超出基本XML文档表示的功能，包括集成的XPath支持、XML Schema支持以及用于大文档或流化文档的基于事件的处理。它还提供了构建文档表示的选项，它通过DOM4J API和标准DOM接口具有并行访问功能。从2000下半年开始，它就一直处于开发之中。

　　为支持所有这些功能，DOM4J使用接口和抽象基本类方法。DOM4J大量使用了API中的Collections类，但是在许多情况下，它还提供一些替代方法以允许更好的性能或更直接的编码方法。直接好处是，虽然DOM4J付出了更复杂的API的代价，但是它提供了比JDOM大得多的灵活性。

　　在添加灵活性、XPath集成和对大文档处理的目标时，DOM4J的目标与JDOM是一样的：针对Java开发者的易用性和直观操作。它还致力于成为比JDOM更完整的解决方案，实现在本质上处理所有Java/XML问题的目标。在完成该目标时，它比JDOM更少强调防止不正确的应用程序行为。

　　DOM4J是一个非常非常优秀的Java XML API，具有性能优异、功能强大和极端易用使用的特点，同时它也是一个开放源代码的软件。如今你可以看到越来越多的Java软件都在使用DOM4J来读写XML，特别值得一提的是连Sun的JAXM也在用DOM4J。

　　Bean文件：

　　package com.test;

　　import java.io.*;import java.util.*;import org.dom4j.*;import org.dom4j.io.*;

　　public class MyXMLReader {

　　public static void main(String arge[]) {

　　long lasting = System.currentTimeMillis();

　　try {

　　　File f = new File("data_10k.xml");

　　　SAXReader reader = new SAXReader();

　　　Document doc = reader.read(f);

　　　Element root = doc.getRootElement();

　　　Element foo;

　　　for (Iterator i = root.elementIterator("VALUE"); i.hasNext();) {

　　　　foo = (Element) i.next();

　　　　System.out.print("车牌号码:" + foo.elementText("NO"));

　　　　System.out.println("车主地址:" + foo.elementText("ADDR"));

　　　}

　　} catch (Exception e) {

　　　e.printStackTrace();

　　}

　　System.out.println("运行时间：" + (System.currentTimeMillis() - lasting) + "毫秒");}}

　　10k消耗时间：109 78 109 31

　　100k消耗时间：297 359 172 312

　　1000k消耗时间：2281 2359 2344 2469

　　10000k消耗时间：20938 19922 20031 21078

　　JDOM和DOM在性能测试时表现不佳，在测试10M文档时内存溢出。在小文档情况下还值得考虑使用DOM和JDOM。虽然JDOM的开发者已经说明他们期望在正式发行版前专注性能问题，但是从性能观点来看，它确实没有值得推荐之处。另外，DOM仍是一个非常好的选择。DOM实现广泛应用于多种编程语言。它还是许多其它与XML相关的标准的基础，因为它正式获得W3C推荐(与基于非标准的Java模型相对)，所以在某些类型的项目中可能也需要它(如在JavaScript中使用DOM)。

　　SAX表现较好，这要依赖于它特定的解析方式。一个SAX检测即将到来的XML流，但并没有载入到内存(当然当XML流被读入时，会有部分文档暂时隐藏在内存中)。

　　无疑，DOM4J是这场测试的获胜者，目前许多开源项目中大量采用DOM4J，例如大名鼎鼎的Hibernate也用DOM4J来读取XML配置文件。如果不考虑可移植性，那就采用DOM4J吧

Trackback: http://tb.blog.csdn.net/TrackBack.aspx?PostId=589524

1： DOM

DOM 是用与平台和语言无关的方式表示 XML 文档的官方 W3C 标准。DOM 是以层次结构组织的节点或信息片断的集合。这个层次结构允许开发人员在树中寻找特定信息。分析该结构通常需要加载整个文档和构造层次结构，然后才能做任何工作。由于它是基于信息层次的，因而 DOM 被认为是基于树或基于对象的。DOM 以及广义的基于树的处理具有几个优点。

首先，由于树在内存中是持久的，因此可以修改它以便应用程序能对数据和结构作出更改。它还可以在任何时候在树中上下导航，而不是像 SAX 那样是一次性的处理。DOM 使用起来也要简单得多。

另一方面，对于特别大的文档，解析和加载整个文档可能很慢且很耗资源，因此使用其他手段来处理这样的数据会更好。这些基于事件的模型，比如 SAX.

2：SAX

这种处理的优点非常类似于流媒体的优点。分析能够立即开始，而不是等待所有的数据被处理。而且，由于应用程序只是在读取数据时检查数据，因此不需要将数据存储在内存中。这对于大型文档来说是个巨大的优点。事实上，应用程序甚至不必解析整个文档；它可以在某个条件得到满足时停止解析。一般来说，SAX 还比它的替代者 DOM 快许多。

3：选择 DOM 还是选择 SAX ？

对于需要自己编写代码来处理 XML 文档的开发人员来说，选择 DOM 还是 SAX 解析模型是一个非常重要的设计决策。

DOM 采用建立树形结构的方式访问 XML 文档，而 SAX 采用的事件模型。

DOM 解析器把 XML 文档转化为一个包含其内容的树，并可以对树进行遍历。用 DOM 解析模型的优点是编程容易，开发人员只需要调用建树的指令，然后利用navigation APIs访问所需的树节点来完成任务。可以很容易的添加和修改树中的元素。然而由于使用 DOM 解析器的时候需要处理整个 XML 文档，所以对性能和内存的要求比较高，尤其是遇到很大的 XML 文件的时候。由于它的遍历能力，DOM 解析器常用于 XML 文档需要频繁的改变的服务中。

SAX 解析器采用了基于事件的模型，它在解析 XML 文档的时候可以触发一系列的事件，当发现给定的tag的时候，它可以激活一个回调方法，告诉该方法制定的标签已经找到。SAX 对内存的要求通常会比较低，因为它让开发人员自己来决定所要处理的tag.特别是当开发人员只需要处理文档中所包含的部分数据时，SAX 这种扩展能力得到了更好的体现。但用 SAX 解析器的时候编码工作会比较困难，而且很难同时访问同一个文档中的多处不同数据。

4：JDOM

JDOM的目的是成为 Java 特定文档模型，它简化与 XML 的交互并且比使用 DOM 实现更快。由于是第一个 Java 特定模型，JDOM 一直得到大力推广和促进。正在考虑通过“Java 规范请求 JSR-102”将它最终用作“Java 标准扩展”。从 2000 年初就已经开始了 JDOM 开发。

JDOM 与 DOM 主要有两方面不同。首先，JDOM 仅使用具体类而不使用接口。这在某些方面简化了 API，但是也限制了灵活性。第二，API 大量使用了 Collections 类，简化了那些已经熟悉这些类的 Java 开发者的使用。

JDOM 文档声明其目的是“使用 20%（或更少）的精力解决 80%（或更多）Java/XML 问题”（根据学习曲线假定为 20%）。JDOM 对于大多数 Java/XML 应用程序来说当然是有用的，并且大多数开发者发现 API 比 DOM 容易理解得多。JDOM 还包括对程序行为的相当广泛检查以防止用户做任何在 XML 中无意义的事。然而，它仍需要您充分理解 XML 以便做一些超出基本的工作（或者甚至理解某些情况下的错误）。这也许是比学习 DOM 或 JDOM 接口都更有意义的工作。

JDOM 自身不包含解析器。它通常使用 SAX2 解析器来解析和验证输入 XML 文档（尽管它还可以将以前构造的 DOM 表示作为输入）。它包含一些转换器以将 JDOM 表示输出成 SAX2 事件流、DOM 模型或 XML 文本文档。JDOM 是在 Apache 许可证变体下发布的开放源码。

5： DOM4J

虽然 DOM4J 代表了完全独立的开发结果，但最初，它是 JDOM 的一种智能分支。它合并了许多超出基本 XML 文档表示的功能，包括集成的 XPath 支持、XML Schema 支持以及用于大文档或流化文档的基于事件的处理。它还提供了构建文档表示的选项，它通过 DOM4J API 和标准 DOM 接口具有并行访问功能。从 2000 下半年开始，它就一直处于开发之中。

为支持所有这些功能，DOM4J 使用接口和抽象基本类方法。DOM4J 大量使用了 API 中的 Collections 类，但是在许多情况下，它还提供一些替代方法以允许更好的性能或更直接的编码方法。直接好处是，虽然 DOM4J 付出了更复杂的 API 的代价，但是它提供了比 JDOM 大得多的灵活性。

在添加灵活性、XPath 集成和对大文档处理的目标时，DOM4J 的目标与 JDOM 是一样的：针对 Java 开发者的易用性和直观操作。它还致力于成为比 JDOM 更完整的解决方案，实现在本质上处理所有 Java/XML 问题的目标。在完成该目标时，它比 JDOM 更少强调防止不正确的应用程序行为。

DOM4J 是一个非常非常优秀的Java XML API，具有性能优异、功能强大和极端易用使用的特点，同时它也是一个开放源代码的软件。如今你可以看到越来越多的 Java 软件都在使用 DOM4J 来读写 XML，特别值得一提的是连 Sun 的 JAXM 也在用 DOM4J.

6：总述

JDOM 和 DOM 在性能测试时表现不佳，在测试 10M 文档时内存溢出。在小文档情况下还值得考虑使用 DOM 和 JDOM.虽然 JDOM 的开发者已经说明他们期望在正式发行版前专注性能问题，但是从性能观点来看，它确实没有值得推荐之处。另外，DOM 仍是一个非常好的选择。DOM 实现广泛应用于多种编程语言。它还是许多其它与 XML 相关的标准的基础，因为它正式获得 W3C 推荐（与基于非标准的 Java 模型相对），所以在某些类型的项目中可能也需要它（如在 javascript 中使用 DOM）。

SAX表现较好，这要依赖于它特定的解析方式。一个 SAX 检测即将到来的XML流，但并没有载入到内存（当然当XML流被读入时，会有部分文档暂时隐藏在内存中）。

无疑，DOM4J是最好的，目前许多开源项目中大量采用 DOM4J，例如大名鼎鼎的 Hibernate 也用 DOM4J 来读取 XML 配置文件。如果不考虑可移植性，那就采用DOM4J吧！

Trackback: http://tb.blog.csdn.net/TrackBack.aspx?PostId=589518

1. 把软件产品根据功能进行分解，分别开发：对于大的复杂系统，如果没有很好的分解开发的话，其结果是不可想象的。现实中企业需要分开各个职能部门，它们的职责和业务是不同的，这样开发中需要根据业务进行任务分解，把大的系统分解成为小的业务系统。这样才能够实现系统开发过程中的并行开发，并且会培养业务专精人员，提高开发的效率。
2. 业务系统根据技术架构进行分层开发：分层的开发方式实现了人类对复杂事物的普遍处理方式——分而治之。通过把复杂的系统分解成为相对简单的独立系统，低耦合的分解既可以实现开发人员的并行工作，又可以实现开发人员的任务分工。而且通过分层，对组件拼装和流水化作业提供了理论和事实的基础。
3. 组件拼装实现社会化分工：不必自己去创造轮子，直接付钱去买想要的轮子即可。这是从传统的制造行业借鉴来的经验。J2EE得到的广泛认同从实质上体现了业界对这种方式的肯定。
4. 过去经验的积累和积累资源的重复利用：重用一直是一个争议比较大的东西，争论的双方各执一词，各有道理也各有大师助阵，但是那更多的是在理论上和技术层面上。理论和技术上的争论对商业软件开发是无用的。因为商业化的软件开发，最重要的是提供优质的产品和服务并且能够最大可能的获取利润。所以，抛开具体实现方式不谈，我个人觉得公司过去经验的积累和积累资源的重复利用是有商业价值的。因为软件公司必须得面对开发人员流动的问题，不管是升迁还是调动还是跳槽，软件公司总会面对业务专精人员的流失问题。业务专精人员的流失造成的成本是要计算在开发成本中的，所以怎样以固化的形式积累业务人员的经验，和过去解决问题的方案的可重复利用以及新员工职业培训成本的降低在降低开发成本的方面是值得考虑的。

采用Struts能开发出基于MVC(Model-View-Controller)设计模式的应用构架。

Struts有如下的主要功能：

1. 包含一个controller servlet，能将用户的请求发送到相应的Action对象。

2. JSP自由tag库，并且在controller servlet中提供关联支持，帮助开发员创建交互式表单应用。

3. 提供了一系列实用对象：XML处理、通过Java reflection APIs自动处理JavaBeans属性、国际化的提示和消息。

Struts是Jakarta项目的一部分，主页在http://jakarta.apache.org/struts.

Version 0.5的下载地址：http://jakarta.apache.org/builds/jakarta-struts/release/v0.5

1.1 1、什么是MVC模式。
MVC(Model/View/Controller)模式是国外用得比较多的一种设计模式，好象最早是在Smaltalk中出现。MVC包括三类对象。Model是应用对象，View是它在屏幕上的表示，Controller定义用户界面对用户输入的响应方式。

1.2 2、是否所有JSP应用都该采用MVC模式？
不一定所有的JSP应用都该采用MVC模式。但对于大型应用来说，我认为还是该采用MVC模式。不使用MVC模式，用户界面界面设计往往将这些对象混在一起，而MVC则将它们分离以提高灵活性和复用性。

1.3 3、Struts中能做XML吗，与Cocoon相比有何优点？
Struts把主要精力放在JSP上了。Cocoon才是专业级的XML Framework。

2. Struts的安装
2.1 安装Struts需要的软件

Java Development Kit - 你需要download和install 1.2(或之后)版本的JDK。下载地址：http://java.sun.com/j2se
Servlet Container - 通常的选择是下载Tomcat(至少是3.1版，推荐使用3.2版)。下载地址：http://jakarta.apache.org/tomcat
Ant Build System - 如果你通过Struts源码发布包安装，你必须下载1.1或之后版本的ant build system。在你通过Struts来开发你自己的Web应用程序是，我也推荐使用ant来build你的应用。下载地址：http://jakarta.apache.org/ant
Servlet API Classes - 为了编译Structs自己，或应用程序使用Struts，你需要一个包含Servlet和JSP API对象的servlet.jar包。大多数Servlet container（例如Tomcat)已经自带了这个文件。否则，你必需下载：http://jakarta.apache.org/builds/jakarta-servletapi
XML Parser - Structs需要一个与Java API for XML Parsing(JAXP)规格兼容的XML处理器。我推荐使用Xerces。下载地址：http://xml.apache.org/xerces-j
Xalan XSLT Processor - 如果你通过Structs源码发布版来构造你的Structs系统，你必须下载和安装1_2_D01或之后版本的Xalan XSLT处理器(Xerces中已自带Xalan)。这个处理器用于将基于XML的Structs文档转换为Html文档。

2.2 通过源码构造Structs

1.下载Structs的源码发布包。
2.设置ANT_HOME环境变量，指向你的Ant目录。
3.设置JAVA_HOME环境变量，指向你的JDK目录。
4.设置SERVLETAPI_HOME环境变量，指向你的Servlet API目录（如果你的CLASSPATH已经包含了servlet.jar，就不需要指定该目录）
5.将Structs的源码发布包进行解包。
6.进入Structs目录，运行以下命令：
./build.sh dist
该命令将创建Struts的二进制发布包，目录在../dist/structs(相对于你的编译目录）。

2.3 通过Struts的二进制发布包安装Structs

1.下载Struts的二进制发布版。
2.将Struts的二进制发布版进行解包。(如果你是通过Struts源码构造Struts，build的结果就已经是已解包的Struts)。解包后的Struts包含以下内容：
lib/struts.jar - 这个文件包含了Struts的所有Java对象。你需要把它拷贝到你的Web应用的WEB-INF/lib目录。
lib/structs.tld - 这是一个"tag library descriptor"文件，它描述了Struts库的自由tag。需要将它拷贝到你的Web应用的WEB-INF目录。
webapps/struts-documentation.war - 这是一个"web application archive"文件，包含了所有的Struts文档。你可以将它安装到支持Servlet API 2.2或之后版本的servlet container(推荐使用tomcat)中。
webapps/struts-example.war - 这是一个web应用实例，它广泛地演示了Struts的许多功能。你可以将它安装到兼容Servlet2.2或之后版本以及JSP1.1或之后版本规范的servlet容器中(推荐使用tomcat)。
webapps/struts-test.war - 这个web应用包含了Struts支持的许多tag的测试网页，可以作为使用Struts tag的例子。

可通过以下的步骤在你自己的应用程序中使用Struts：
1.将Struts目录的lib/struts.jar拷贝到web应用的WEB-INF/lib目录。
2.将Struts目录的lib/struts*.tld拷贝到web应用的WEB-INF目录。
3.修改Web应用目录的WEB-INF/web.xml文件，增加一个<servlet>元素来定义controller servlet，增加一个<servlet-mapping>元素来建立URI请求与servlet的对应关系。可以参照Struts例子中的WEB-INF/web.xml文件来了解详细的语法要求。
4.修改Web应用目录的WEB-INF/web.xml文件，使之包含以下的tag库定义：
<taglib>
<taglib-uri>/WEB-INF/struts.tld</taglib-uri>
<taglib-location>/WEB-INF/struts.tld</taglib-location>
</taglib>
<taglib>
<taglib-uri>/WEB-INF/struts-bean.tld</taglib-uri>
<taglib-location>/WEB-INF/struts-bean.tld</taglib-location>
</taglib>
<taglib>
<taglib-uri>/WEB-INF/struts-logic.tld</taglib-uri>
<taglib-location>/WEB-INF/struts-logic.tld</taglib-location>
</taglib>
5.创建一个WEB-INF/action.xml文件来定义你的web应用的action映射关系。可以参照Struts例子中的action.xml文件来了解详细的语法要求。
6.在使用Struts tag库的JSP网页中加入以下tag库定义：
<@ taglib uri="/WEB-INF/struts.tld" prefix="struts" %>
<@ taglib uri="/WEB-INF/struts-bean.tld" prefix="bean" %>
<@ taglib uri="/WEB-INF/struts-logic.tld" prefix="logic" %>
7.最后，在编译你的web应用的java程序时，不要忘了在CLASSPATH中包含struts.jar文件哟。

Trackback: http://tb.blog.csdn.net/TrackBack.aspx?PostId=591298

一、HTTP协议是什么

我们在浏览器的地址栏里输入的网站地址叫做URL(UniformResourceLocator，统一资源定位符)。就像每家每户都有一个门牌地址一样，每个网页也都有一个Internet地址。当你在浏览器的地址框中输入一个URL或是单击一个超级链接时，URL就确定了要浏览的地址。浏览器通过超文本传输协议(HTTP)，将Web服务器上站点的网页代码提取出来，并翻译成漂亮的网页。因此，在我们认识HTTP之前，有必要先弄清楚URL的组成,例如：http://www.microsoft.com/china/index.htm。它的含义如下：

1.http://：代表超文本传输协议，通知microsoft.com服务器显示Web页，通常不用输入；

2.www：代表一个Web(万维网)服务器；

3.Microsoft.com/：这是装有网页的服务器的域名，或站点服务器的名称；

4.China/：为该服务器上的子目录，就好像我们的文件夹；

5.Index.htm：index.htm是文件夹中的一个HTML文件(网页)。

我们知道，Internet的基本协议是TCP/IP协议，然而在TCP/IP模型最上层的是应用层(Applicationlayer)，它包含所有高层的协议。高层协议有：文件传输协议FTP、电子邮件传输协议SMTP、域名系统服务DNS、网络新闻传输协议NNTP和HTTP协议等。

HTTP协议(HypertextTransferProtocol，超文本传输协议)是用于从WWW服务器传输超文本到本地浏览器的传送协议。它可以使浏览器更加高效，使网络传输减少。它不仅保证计算机正确快速地传输超文本文档，还确定传输文档中的哪一部分，以及哪部分内容首先显示(如文本先于图形)等。这就是你为什么在浏览器中看到的网页地址都是以“http://”开头的原因。

自WWW诞生以来，一个多姿多彩的资讯和虚拟的世界便出现在我们眼前，可是我们怎么能够更加容易地找到我们需要的资讯呢？当决定使用超文本作为WWW文档的标准格式后，于是在1990年，科学家们立即制定了能够快速查找这些超文本文档的协议，即HTTP协议。经过几年的使用与发展，得到不断的完善和扩展，目前在WWW中使用的是HTTP/1.0的第六版。

二、HTTP是怎样工作的

既然我们明白了URL的构成，那么HTTP是怎么工作呢？我们接下来就要讨论这个问题。

由于HTTP协议是基于请求/响应范式的(相当于客户机/服务器)。一个客户机与服务器建立连接后，发送一个请求给服务器，请求方式的格式为：统一资源标识符(URL)、协议版本号，后边是MIME信息包括请求修饰符、客户机信息和可能的内容。服务器接到请求后，给予相应的响应信息，其格式为一个状态行，包括信息的协议版本号、一个成功或错误的代码，后边是MIME信息包括服务器信息、实体信息和可能的内容。

许多HTTP通讯是由一个用户代理初始化的并且包括一个申请在源服务器上资源的请求。最简单的情况可能是在用户代理和服务器之间通过一个单独的连接来完成。在Internet上，HTTP通讯通常发生在TCP/IP连接之上。缺省端口是TCP80，但其它的端口也是可用的。但这并不预示着HTTP协议在Internet或其它网络的其它协议之上才能完成。HTTP只预示着一个可靠的传输。

这个过程就好像我们打电话订货一样，我们可以打电话给商家，告诉他我们需要什么规格的商品，然后商家再告诉我们什么商品有货，什么商品缺货。这些，我们是通过电话线用电话联系(HTTP是通过TCP/IP)，当然我们也可以通过传真，只要商家那边也有传真。

以上简要介绍了HTTP协议的宏观运作方式，下面介绍一下HTTP协议的内部操作过程。

在WWW中，“客户”与“服务器”是一个相对的概念，只存在于一个特定的连接期间，即在某个连接中的客户在另一个连接中可能作为服务器。基于HTTP协议的客户/服务器模式的信息交换过程，它分四个过程：建立连接、发送请求信息、发送响应信息、关闭连接。这就好像上面的例子，我们电话订货的全过程。

其实简单说就是任何服务器除了包括HTML文件以外，还有一个HTTP驻留程序，用于响应用户请求。你的浏览器是HTTP客户，向服务器发送请求，当浏览器中输入了一个开始文件或点击了一个超级链接时，浏览器就向服务器发送了HTTP请求，此请求被送往由IP地址指定的URL。驻留程序接收到请求，在进行必要的操作后回送所要求的文件。在这一过程中，在网络上发送和接收的数据已经被分成一个或多个数据包(packet)，每个数据包包括：要传送的数据；控制信息，即告诉网络怎样处理数据包。TCP/IP决定了每个数据包的格式。如果事先不告诉你，你可能不会知道信息被分成用于传输和再重新组合起来的许多小块。

也就是说商家除了拥有商品之外，它也有一个职员在接听你的电话，当你打电话的时候，你的声音转换成各种复杂的数据，通过电话线传输到对方的电话机，对方的电话机又把各种复杂的数据转换成声音，使得对方商家的职员能够明白你的请求。这个过程你不需要明白声音是怎么转换成复杂的数据的。

　　WebLogic 是一套基于JAVA功能强大的电子商务套件，提供了许多功能强大的中间件以方便编程人员编写的JSP、SERVLET 等电子商务应用，可以为企业提供一个完整的商务应用解决方案。对于开发人员 WebLogic 可以在 www.bea.com 免费下载一套完整的 WebLogic，并得到一个限制了 IP 的license，用于学习和开发基于这个套件的代码。而要是需要正式的投入使用的话，那么就必须支付一定的费用获取没限制的license。由于这个套件基于这种发布方式，对于一般网站开发人员可以很轻易地得到 WebLogic 用于学习开发，当然投入使用是另一回事。

　　我获得的 WebLogic5.10是两个大大的zip文件，一个是WebLogic程序包，一个是资料文档。因为是基于JAVA，虽然在下载时有区分操作系统，但是我得到的那套经过实践发现在WINNT和LINUX都可以运行，下面主要是以LINUX的为例，WINNT的安装方法也差不多。

　　安装篇

　　安装前准备：

　　在安装前，用户必须获得一套对应于用户的操作系统的JDK（在 www.sun.com 免费下载），安装好后把WebLogic5.10的压缩包解开，建议放在根目录上，这样会省去很多修改设置的麻烦，在linux下可以解在其他目录，然后在根目录再做一个硬连接也可以。

　　我的安装的文件目录是

　　配置weblogic：

　　启动weblogic需要执行两个脚本文件：

linux：setEnv.sh和startWebLogic.sh

WINNT对应的是：setEnv.cmd和startWebLogic.cmd

　　1、weblogic.properties

　　打开/usr/local/weblogic/的 weblogic.properties 文件，找到这一行 weblogic.password.system=
这是设置管理员密码用的，这个设置项不能为空，所以必须设置一个可靠的管理员密码。

　　例如：weblogic.password.system=sdfjkdshfds

　　设置运行JSP：

　　把那些注释删去，即改为

　　 要注意的是还要配置好这一行：

　　这是JDK的JAVA编译器的路径。

　　2、setEnv.sh

　　打开/weblogic/setEnv.sh，找到这一行

　　　JAVA_HOME=/usr/java

　　改为

　　　JAVA_HOME=/usr/local/jdk1.2/

　　3、 startWebLogic.sh

　　找到一个全是大写的 "LINUX" 字符串，改为 "Linux"，很奇怪是为何要这样是吗？这是因为启动时，脚本文件调用了uname 指令来得到系统的名字，再与"LINUX" 字符串比较确认是否是linux系统，但是uname 指令来返回的系统的名字是Linux，所以我们要改一下，这应该是这个启动脚本的一个小小的BUG，WINT就不用那么麻烦了。

　　运行weblogic：

　　经过简单的配置就试运行了。

　　在目录/weblogic/下执行

　　　. ./setEnv.sh （大家请留意，我这里有两个 ".",因为我们需要在当前的shell下执行这个脚本 ）

　　　./startWebLogic.sh

　　当看到成功启动 WebLogic 的信息时，说明启动成功了。

　　服务器简单的测试：

　　WebLogic 默认的WEB端口为7001，我们可以在打开一个浏览器输入地址

　　　http://localhost:7001/

　　测试是否能连接得上。

　　Servlet的测试

　　如果能连得上得话，那么就可以进行下一步的Servlet的测试，在浏览器输入地址

　　　http://localhost:7001/helloWorld

　　这个就是WebLogic Servlet的演示（至于怎样安装 Servlet请看下文）

　　JSP的测试

　　在目录 /weblogic/myserver/public_html/下建立一个名为test.jsp的文件

　　test.jsp

　　在浏览器输入地址

　　http://localhost:7001/test.jsp

　　测试能否看到正确的输出"test JSP"的信息。

　　结构篇

　　要学习好一套系统首先要了解它的结构，本文详细的介绍 WebLogic 的一些结构和特点：

　　WebLogic的大部分配置是在 weblogic.properties 里完成的，只要仔细的研究这个文件就可以清楚得知关于 WebLogic 的一些结构和特点，下面就对 weblogic.properties 文件里的一些配置项作一些说明：

　　weblogic.httpd.documentRoot=public_html/

　　这就是WebLogic 的WEB 服务器的根目录，即是目录/weblogic/myserver/public_html/　

　　　weblogic.password.system=sdfjkdshfds

　　这个前文已经提到，是设置管理员密码。

　　　weblogic.system.listenPort=7001

　　这是设置 WebLogic 的 WEB 服务器端口。

　　　weblogic.httpd.servlet.classpath=/weblogic/myserver/servletclasses

　　设置Servlet存放的路径

　　关于Servlet

　　出于安全的目的，在 WebLogic 下运行的 WebLogic 必须在 weblogic.properties 里登记后才能运行，例如上文的提到Servlet http://localhost:7001/helloWorld，它在weblogic.properties 里的登记项是

　　实际上，这个 Servlet 的实际路径是

　　对照一下weblogic.properties里的登记项和HelloWorldServlet.class文件的路径，应该不难找出其登记Servlet的规律吧。

　　在weblogic.properties里有一下几个Servlet的登记项：

　　这就是管理员管理 WebLogic 用的Servlet，通过URL访问http://localhost:7001/AdminMain，在弹出的身份验证对话框了输入 system 和在 weblogic.password.system= 设置的密码，就可以进入 WebLogic 的Web管理界面进行管理。

Trackback: http://tb.blog.csdn.net/TrackBack.aspx?PostId=317407

Trackback: http://tb.blog.csdn.net/TrackBack.aspx?PostId=615990

    配置这个的目的是让你的java应用程序找到连接mysql的驱动． 
      配置完环境变量后还有很重要一步就是为JSP连接数据库配置驱动，这个其实很简单，就是把mysql-connector-java-3.1.8-bin.jar拷到某些文件夹里就行了，我在网上看了很多资料问了很多人，各种说法都有，我综合了一下，为了保险，我都全做了，呵呵，反正就是拷一个400K的文件而已，现列出要把mysql-connector-java-3.1.8-bin.jar拷进去的文件夹，如下：
E:\Java\Tomcat5.0\common\lib
E:\Java\Tomcat5.0\shared\lib 
     一般情况下只要考到Tomcat5.0上面的两个问题夹里面就可以解决问题了，如果需要，也可以将mysql-connector-java-3.1.8-bin.jar这个驱动文件拷贝到你的WEB站点的  …\WEB-INF\lib 目录下面。

3，  Eclipse中数据库插件中操作数据库时的中文编码问题：
当在Eclipse中装上来你所喜欢的数据库插件的时候，都会出现在你查询某一个数据库之后出现记录中的汉字乱码。解决方法很简单，只要在你建立数据库连接的时候把URL设置成下面这个样子就可以了：
           URL= jdbc:mysql://localhost:3306/?useUnicode=true&characterEncoding=GBK

4，   在JSP网页编辑中个人经验：在经过很多的次调试之后，发现在装了myeclipse之后，有这么条小巧：
①在用myeclipse编写HTML文件时charset=GBK设置成这个样子，那么在浏览器中浏览时就不会出现乱码；
②而在用myeclipse编辑JSP文件时，<%@ page contentType="text/html;charset=GB2312" %>设置成这样子，且这条语句必须是整个JSP文件的第一条语句,就可以避免JSP文件在浏览器中显示时出现乱码；    ③对于如果在JSP网页中要从HTML页面中接收数据，那么在JSP中的接收语句的汉字编码应与数据来源的HTML的汉字编码相同；例如②中的HTML的汉字编码为charset=GBK，那么在JSP中的接收语句就应该这样设置：request.setCharacterEncoding("GBK");如果还要将接受的数据插入到数据库中(以插入MySQL5.0数据库为例)，那么在插入数据库时的汉字编码也应与HTML文件中的汉字编码相同，我的设置如下：con= DriverManager.getConnection("jdbc:mysql://localhost:3306/sample_db?user=dazern&password=5201314&useUnicode=true&characterEncoding=GBK");这样设置后数据库中的数据才不会乱码.

    以上经验都是在myeclipse3.8.3+Tomcat5.0.28中测试过，没有错误！在此仅供大家借鉴，具体情况还得具体分析！