1
前言
本文阐述了
Apusic
对
XML
文件处理的详细分析,及其现有情况下
Apusic
对
XML
文件解析存在的问题。
2
Apusic
如何处理
XML
文件
Apusic
服务器对于
XML
文件解析应该分为两种情况:一种
Apusic
需要加载的
XML
文件。如
:Apusic
的配置文件,
J2EE
应用的
web.xml,application.xml
文件等。另外一种是用户代码中使用
DocumentBuilderFactory
,
SAXParserFactory
来解析自己的
XML
文件。对于上面两种情况的
XML
文件,
Apusic
是予以不同处理的。以下对此做具体说明。
2.1
解析
Apusic
的配置文件及其
J2EE
应用的
web.xml,application.xml…etc
对于这一块的解析,我们现在是采用自己的
XML
解析器来实现的,我们自己的
XML
解析器就是
com.apusic.xml.parsers
,
com.apusic.xml.reader
下的相关类来处理的,和朱华明讨论过,我们对于上述文件采用自己的解析器处理是存在优势的。因为我们对这些文件的结构很了解。效率应该会高于任何第三方的
XML
解析器。但是我们的解析器可能也会存在一些不足的地方,对于一些复杂的
XML
结构的处理可能会存在问题。由于考虑到效率问题,所以这一块应该不需要使用第三方的
XML
解析器,还是使用我们自己的解析器为好。
2.2
用户代码中解析自己的
XML
文件
用户应用程序使用
DocumentBuilderFactory, SAXParserFactory
对自己的
XML
解析时,由于我们在
Apusic.jar
中,对
META-INF/service/
文件夹下设置了
javax.xml.parsers.DocumentBuilderFactory , javax.xml.parsers.SAXParserFactory
两个属性的值,并指向了
Xerces,
所以用户在解析
XML
时,缺省情况下使用的就是
Xerces API
进行操作的。因此这一块应该是不会存在问题。
至于设置此属性后是如何利用
Xerces API
进行解析
XML
的原理,当你阅读了
Java
相关源代码后就可以明白。具体可以阅读
javax.xml.parsers
包下的
DocumentBuilderFactory.class,SAXParserFactory.class
类的
newInstance
方法。
3
现存问题分析
现在我们会遇到修改
Apusic
配置文件后,
Apusic
无法启动的情况。这种情况主要是因为我们使用了自己的
XML
解析器。而我们的解析器在处理
UTF-8
编码文件时存在问题,因为文本文件在文件的头部存在
BOM (Byte Order Mark)
标识
,
而这个
BOM
标识是用来表示文件的字节顺序。对于不同编码格式的文件存在不同的
BOM
标识
,
文件的
BOM
标识规范可以参考下表(表
1
),由于
UTF-8
文件不存在字节顺序的问题,所以这个文件
BOM
标识在
UTF-8
编码方式下是可有可无的。而当我们修改配置文件并保存后,如果存在
BOM
标识,我们的解析器就会出错,不存在
BOM
标识时,我们的解析器就能够正确工作。所以我们需要在解析
UTF-8
的时候,判断头部是否包含
UTF-8
的
BOM
标识,如果有就需要跳过去。代码修改主要是在
XmlReader.java
文件中做如下处理:
//skip UTF-8 BOM (byte order mark)
if (count >= 3 && pos == 0){
if (buffer[0] == (byte)0xEF &&
buffer[1] == (byte)0xBB &&
buffer[2] == (byte)0xBF){
pos += 3;
}
}
|
UTF-8
|
EF BB BF
|
UTF-16 Big Endian
|
FE FF
|
UTF-16 Little Endian
|
FF FE
|
UTF-32 Big Endian
|
00 00 FE FF
|
UTF-32 Little Endian
|
FF FE 00 00
|
(
表
1)
为什么我们对
UTF-16,UTF-32
等编码方式文件存在
BOM
标识时没有问题呢?其实这个问题应该是
Java
的一个
bug
,
Java
的文本流在处理其他编码方式的时候能够很好的处理这个
BOM
标识,但是对于
UTF-8
编码时不能够正确处理。该
bug
可以参考以下地址:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4508058