XML解析技术研究一.docx
《XML解析技术研究一.docx》由会员分享，可在线阅读，更多相关《XML解析技术研究一.docx（136页珍藏版）》请在冰豆网上搜索。
XML解析技术研究一
在我们了解XML之前，我们必须要先找到HTML的原罪问题，只有知道了HTML其中的缺陷才能更好的认识XML的作用。
HTML的原罪：
不能解决所有解释数据的问题。
如影音文件或化学公式、音乐符号等其它型态的内容。
效能问题。
如需要下载整份文件，才能开始对文件做搜寻的动作。
扩充性、弹性、易读性均不佳。
为了解决以上问题，专家们使用SGML精简制作，并依照HTML的发展经验，产生出一套使用上规则严谨，但是简单的描述数据语言：
XML。
XML是在一个这样的背景下诞生的─是不是能有一个更中立的方式，让消费端自行决定要如何消化、呈现从服务端所提供的信息？
而XML目的即在于提供一个对信息能够做精准描述的机制，借以弥补HTML太过于表现导向的特质。
XML（eXtensibleMarkupLanguage）即可扩展标记语言，它与HTML一样，都是SGML（StandardGeneralizedMarkupLanguage，标准通用标记语言）。
Xml是Internet环境中跨平台的，依赖于内容的技术，是当前处理结构化文档信息的有力工具。
扩展标记语言XML是一种简单的数据存储语言，使用一系列简单的标记描述数据，而这些标记可以用方便的方式建立，虽然XML占用的空间比二进制数据要占用更多的空间，但XML极其简单易于掌握和使用。
XML与Access，Oracle和SQLServer等数据库不同，数据库提供了更强有力的数据存储和分析能力，例如：
数据索引、排序、查找、相关一致性等，XML仅仅是展示数据。
事实上XML与其他数据表现形式最大的不同是：
他极其简单。
这是一个看上去有点琐细的优点，但正是这点使XML与众不同。
XML的简单使其易于在任何应用程序中读写数据，这使XML很快成为数据交换的唯一公共语言，虽然不同的应用软件也支持其它的数据交换格式，但不久之后他们都将支持XML，那就意味着程序可以更容易的与Windows、MacOS，Linux以及其他平台下产生的信息结合，然后可以很容易加载XML数据到程序中并分析他，并以XML格式输出结果。
为了使得SGML显得用户友好，XML重新定义了SGML的一些内部值和参数，去掉了大量的很少用到的功能，这些繁杂的功能使得SGML在设计网站时显得复杂化。
XML保留了SGML的结构化功能，这样就使得网站设计者可以定义自己的文档类型，XML同时也推出一种新型文档类型，使得开发者也可以不必定义文档类型。
上面讲到了仅仅是XML的定义和定义之外的一点对比。
重新回来看XML，简单说，XML就是一种数据的描述语言，虽然它是语言，但是通常情况下，它并不具备常见语言的基本功能——被计算机识别并运行。
只有依靠另一种语言，来解释它，使它达到你想要的效果或被计算机所接受。
假如你是刚接触XML的新手，那么可能并无法从定义上是了解XML是什么。
也许，你可以换个角度来认识XML是什么；从应用面来认识XML，从XML可以做些什么来认识它，这应该能比那更空洞的定义对你更有帮助。
XML应用面主要分为两种类型，文档型和数据型。
下面介绍一下几种常见的XML应用：
1、自定义XML+XSLT=>HTML，最常见的文档型应用之一。
XML存放整个文档的XML数据，然后XSLT将XML转换、解析，结合XSLT中的HTML标签，最终成为HTML，显示在浏览器上。
典型的例子就是CSDN上的帖子。
2、XML作为微型数据库，这是最常见的数据型应用之一。
我们利用相关的XMLAPI（MSXMLDOM、JAVADOM等）对XML进行存取和查询。
留言板的实现中，就经常可以看到用XML作为数据库。
同时，这里要告诉一些新人，数据库和数据库系统，这两个概念是不同的。
这里顺便提一下XML对数据库系统的影响。
在新版本的传统数据库系统中，XML成为了一种数据类型。
和“传统”相对的就是一种新形态的数据库，完全以XML相关技术为基础的数据库系统。
目前比较知名的eXist。
3、作为信息传递的载体。
为什么说是载体呢？
因为这些应用虽然还是以XML为基本形态，但是都已经发展出具有特定意义的格式形态。
最典型的就是WEBSERVICE，将数据包装成XML来传递，但是这里的XML已经有了特定的规格，即SOAP。
不过这里还不得不说AJAX，AJAX的应用中，相信也有一部分的应用是以自定义XML为数据，不过没有成为工业标准，这里不做详述。
4、应用程序的配置信息数据。
最典型的就是J2EE配置WEB服务器时用的web.XML。
这个应用估计是很容易理解的了。
我们只要将需要的数据存入XML，然后在我们的应用程序运行载入，根据不同的数据，做相应的操作。
这里其实和应用2，有点类似，所不同的在于，数据库中的数据变化是个常态，而配置信息往往是较为静态，缺少变化的。
5、其他一些文档的XML格式。
如WORD、EXCEL等。
6、保存数据间的映射关系。
如Hibernate。
这几种常见应用中，我们还可以根据其应用广泛程度，分为：
自定义XML和特定意义XML。
在1和2就是属于自定义XML的范畴；3至6则属于特定意义XML，或者说是XML的延伸。
总之，XML是一种抽象的语言，它不如传统的程序语言那么具体。
解读server.xml文件
TomcatServer的结构图
该文件描述了如何启动TomcatServer
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
元素名
属性
解释
server
port
指定一个端口，这个端口负责监听关闭tomcat的请求
shutdown
指定向端口发送的命令字符串
service
name
指定service的名字
Connector（表示客户端和service之间的连接）
port
指定服务器端要创建的端口号，并在这个断口监听来自客户端的请求
minProcessors
服务器启动时创建的处理请求的线程数
maxProcessors
最大可以创建的处理请求的线程数
enableLookups
如果为true，则可以通过调用request.getRemoteHost（）进行DNS查询来得到远程客户端的实际主机名，若为false则不进行DNS查询，而是返回其ip地址
redirectPort
指定服务器正在处理http请求时收到了一个SSL传输请求后重定向的端口号
acceptCount
指定当所有可以使用的处理请求的线程数都被使用时，可以放到处理队列中的请求数，超过这个数的请求将不予处理
connectionTimeout
指定超时的时间数（以毫秒为单位）
Engine（表示指定service中的请求处理机，接收和处理来自Connector的请求）
defaultHost
指定缺省的处理请求的主机名，它至少与其中的一个host元素的name属性值是一样的
Context（表示一个web应用程序，通常为WAR文件，关于WAR的具体信息见servlet规范）
docBase
应用程序的路径或者是WAR文件存放的路径
path
表示此web应用程序的url的前缀，这样请求的url为http:
//localhost:
8080/path/****
reloadable
这个属性非常重要，如果为true，则tomcat会自动检测应用程序的/WEB-INF/lib和/WEB-INF/classes目录的变化，自动装载新的应用程序，我们可以在不重起tomcat的情况下改变应用程序
host（表示一个虚拟主机）
name
指定主机名
appBase
应用程序基本目录，即存放应用程序的目录
unpackWARs
如果为true，则tomcat会自动将WAR文件解压，否则不解压，直接从WAR文件中运行应用程序
Logger（表示日志，调试和错误信息）
className
指定logger使用的类名，此类必须实现org.apache.catalina.Logger接口
prefix
指定log文件的前缀
suffix
指定log文件的后缀
timestamp
如果为true，则log文件名中要加入时间，如下例:
localhost_log.001-10-04.txt
Realm（表示存放用户名，密码及role的数据库）
className
指定Realm使用的类名，此类必须实现org.apache.catalina.Realm接口
Valve（功能与Logger差不多，其prefix和suffix属性解释和Logger中的一样）
className
指定Valve使用的类名，如用org.apache.catalina.valves.AccessLogValve类可以记录应用程序的访问信息
directory
指定log文件存放的位置
pattern
有两个值，common方式记录远程主机名或ip地址，用户名，日期，第一行请求的字符串，HTTP响应代码，发送的字节数。
combined方式比common方式记录的值更多
元素
它代表整个容器,是Tomcat实例的顶层元素.由org.apache.catalina.Server接口来定义.它包含一个元素.并且它不能做为任何元素的子元素.
--一个“Server”是一个提供完整的JVM的独立组件，它可以包含一个或多个
“Service”实例。
服务器在指定的端口上监听shutdown命令。
注意：
一个“Server”自身不是一个“Container”（容器），因此在这里你
不可以定义诸如“Valves”或者“Loggers”子组件
-->
--启动Server
在端口8005处等待关闭命令
如果接受到"SHUTDOWN"字符串则关闭服务器
-->
测试：
telnetlocalhost8005
输入：
SHUTDOWN
结果：
关闭tomcat
1>className指定实现org.apache.catalina.Server接口的类.默认值为org.apache.catalina.core.StandardServer
2>port指定Tomcat监听shutdown命令端口.终止服务器运行时,必须在Tomcat服务器所在的机器上发出shutdown命令.该属性是必须的.
3>shutdown指定终止Tomcat服务器运行时,发给Tomcat服务器的shutdown监听端口的字符串.该属性必须设置
元素
该元素由org.apache.catalina.Service接口定义,它包含一个元素,以及一个或多个,这些Connector元素共享用同一个Engine元素
--一个“Service”是一个或多个共用一个单独“Container”（容器）的“Connectors”
组合（因此，应用程序在容器中可见）。
通常，这个容器是一个“Engine”
（引擎），但这不是必须的。
注意：
一个“Service”自身不是一个容器，因此，在这个级别上你不可定义
诸如“Valves”或“Loggers”子组件。
-->
--Tomcat的StandaloneService
Service是一组Connector的集合
它们共用一个Engine来处理所有Connector收到的请求
-->
第一个处理所有直接由Tomcat服务器接收的web客户请求.
第二个处理所有由Apahce服务器转发过来的Web客户请求.
1>className指定实现org.apahce.catalina.Service接口的类.默认为org.apahce.catalina.core.StandardService
2>name定义Service的名字
元素
由Connector接口定义.元素代表与客户程序实际交互的给件,它负责接收客户请求,以及向客户返回响应结果.
--一个“Connector”（连接器）代表一个请求被接收和应答所需要的端点。
每个连
接器通过相关的“Container”（容器）处理请求。
默认情况下，一个非SSL的HTTP/1.1的连接器被绑定在端口8080。
你也可以通过
根据后面的使用说明并取消第二个连接器入口的注释，在端口8443上建立一个
SSLHTTP/1.1的连接器。
开放SSL支持需要下面几步（参见Tomcat5文档中怎样
配置SSL的说明以取得更多的详细信息）：
*如果你的JDK是1.3或1.3以前的版本，下载安装JSSE1.0.2或以后版本，并放
置JAR文件到“$JAVA_HOME/jre/lib/ext”目录下。
*带一个“changeit”的口令值执行：
%JAVA_HOME%\bin\keytool-genkey-aliastomcat-keyalgRSA（Windows）
$JAVA_HOME/bin/keytool-genkey-aliastomcat-keyalgRSA（UNIX）
来生成它自己的证书私钥。
默认情况下，当一个web应用程序调用请求时，DNS查询是可行的。
这将对性能造
成一些不利的影响，因此，你可以将“enableLookups”设置为“false”来关闭DNS
查询。
当DNS查询被关闭时，request.getRemoteHost（）将返回包含远程客户IP地
址的字符串。
-->
--CoyoteHTTP/1.1Connector
className:
该Connector的实现类是org.apache.coyote.tomcat4.CoyoteConnector
port:
在端口号8080处侦听来自客户browser的HTTP1.1请求.如果把8080改成80,则只要输入http:
//localhost/即可
protocol:
设定Http协议,默认值为HTTP/1.1
minSpareThreads:
该Connector先创建5个线程等待客户请求，每个请求由一个线程负责
maxSpareThread:
设定在监听端口的线程的最大数目,这个值也决定了服务器可以同时响应客户请求的最大数目.默认值为200
acceptCount:
当现有线程已经达到最大数75时，为客户请求排队.当队列中请求数超过100时，后来的请求返回Connectionrefused错误
redirectport:
当客户请求是https时，把该请求转发到端口8443去
enableLookups:
如果设为true,表示支持域名解析,可以把IP地址解析为主机名.WEB应用中调用request.getRemoteHost方法返回客户机主机名.默认值为true
connectionTimeout:
定义建立客户连接超时的时间.如果为-1,表示不限制建立客户连接的时间
其它属性略
-->
第一个Connector元素定义了一个HTTPConnector,它通过8080端口接收HTTP请求;第二个Connector元素定义了一个JDConnector,它通过8009端口接收由其它服务器转发过来的请求.
元素
每个Service元素只能有一个Engine元素.处理在同一个中所有元素接收到的客户请求.由org.apahce.catalina.Engine接口定义.
--一个“Engine”（引擎）代表处理每个请求的入口点（在Catalina内）。
这个Tomcat
的标准独立引擎实现分析包含在请求中的HTTP头信息，并将请求传送到适当的主机
或虚拟主机上。
-->
--Engine用来处理Connector收到的Http请求
它将匹配请求和自己的虚拟主机，并把请求转交给对应的Host来处理
默认虚拟主机是localhost
-->
1>className指定实现Engine接口的类,默认值为StandardEngine
2>defaultHost指定处理客户的默认主机名,在中的子元素中必须定义这一主机
3>name定义Engine的名字
在可以包含如下元素,,,
元素
它由Host接口定义.一个Engine元素可以包含多个元素.每个的元素定义了一个虚拟主机.它包含了一个或多个Web应用.
--定义默认的虚拟主机
注意：
XML模式确认将不能与Xerces2.2同工作。
-->
--虚拟主机localhost
appBase:
指定虚拟主机的目录,可以指定绝对目录,也可以指定相对于的相对目录.如果没有此项,默认为/webapps.它将匹配请求和自己的Context的路径，并把请求转交给对应的Context来处理
autoDeploy:
如果此项设为true,表示Tomcat服务处于运行状态时,能够监测appBase下的文件,如果有新有web应用加入进来,会自运发布这个WEB应用
unpackWARs:
如果此项设置为true,表示把WEB应用的WAR文件先展开为开放目录结构后再运行.如果设为false将直接运行为WAR文件
alias:
指定主机别名,可以指定多个别名
deployOnStartup:
如果此项设为true,表示Tomcat服务器启动时会自动发布appBase目录下所有的Web应用.如果Web应用中的server.xml没有相应的元素,将采用Tomcat默认的Context
-->
在元素中可以包含如下子元素
,,,
元素
它由Context接口定义.是使用最频繁的元素.每个可以包含多个元素.每个web应用有唯一
的一个相对应的Context代表web应用自身.servlet容器为第一个web应用创建一个
--Context，对应于一个WebApp
path:
该Context的路径名是""，故该Context是该Host的默认Context
docBase:
该Context的根目录是webapps/mycontext/
reloadable:
如果这个属性设为true,Tomcat服务器在运行状态下会监视在WEB-INF/classes和Web-INF/lib目录CLASS文件的改运.如果监视到有class文件被更新,服务器自重新加载Web应用
useNaming:
指定是否支持JNDI,默认值为了true
cookies指定是否通过Cookies来支持Session,默认值为true
-->
TomcatServer处理一个http请求的过程
假设来自客户的请求为：
http:
//localhost:
8080/wsota/wsota_index.jsp
1）请求被发送到本机端口8080，被在那里侦听的CoyoteHTTP/1.1Connector获得
2）Connector把该请求交给它所在的Service的Engine来处理，并等待来自Engine的回应
3）Engine获得请求localhost/wsota/wsota_index.jsp，匹配它所拥有的所有虚拟主机Host
4）Engine匹配到名为localhost的Hos
升级会员 