一直对于一些在程序中司空见惯的东西无动于衷，所以很麻木，但是今天终于明白了一些东西。
来源于CSDN上面的一个问题，
现在有一个聊天室，每个房间都有一个radiobutton而不是一个radiobuttonlist,他们都autopostback,每次postback时都要获取他的value,我可以为每个radiobuton写一段代码，这样可以获取value,但是可以就写一段吗，就像为很多个button指定不同的commandname一样,但是事件相同onclick="enter_click"
谢谢
zhangweisjz(啸傲沧海) ( ) 信誉：100 Blog 加为好友 2007-06-29 11:18:05 得分: 0
public void enter_click(Object sender, EventArgs e){
//在sender 上面做文章
string myName=((RadioButton)sender).Name.ToString();
if(myName=="张三"){
}
if(myName=="李四"){
}
}
哈哈，这是我的回答。能不能得分呢？我们拭目以待。
Jun 29, 2007
Jun 22, 2007
我所写过的最复杂的Sql 语句——合并记录，合并值
select distinct A.word, sum(A.count) as Count
from ( select WORD_B as Word,CO_LIT_COUNT as Count from WORD_RELATION_MATRIX
where WORD_A like '知识管理'
UNION all
select WORD_A,CO_LIT_COUNT from WORD_RELATION_MATRIX where WORD_B like '知识管理') A
group by A.word order by Count desc
from ( select WORD_B as Word,CO_LIT_COUNT as Count from WORD_RELATION_MATRIX
where WORD_A like '知识管理'
UNION all
select WORD_A,CO_LIT_COUNT from WORD_RELATION_MATRIX where WORD_B like '知识管理') A
group by A.word order by Count desc
Jun 18, 2007
皇马下赛季展望
四年的期待有多大的份量？当看到卡西在第一个进球后夺眶而出的泪水时，你就知道它有多重，就知道皇马的将士承受了多大的压力。
四年的渴望有多大的力量？当看到贝克汉姆打封闭上场，卡洛斯、萨尔加多几乎拼命的争抢时，你就知道，这种渴望能给人多大的力量。
四年的收获有多大的幸福？当你看到迪亚拉两次跪着亲吻土地，看到你我彻夜不眠却仍精神振奋的情形，就知道这种发自内心的喜悦能给人带来多大的喜悦。
当胜利的喜悦渐渐平静的时候，我们该想些什么呢？
回顾本赛季皇马夺冠的历程，如果这是一部话剧，即使最有才华的作家也写不出如此惊心动魄、跌宕起伏的剧本，也许上帝本人看了，也会对自己这近乎神话般的创作而惊讶不已。
形容本赛季皇马最后阶段的表演，只有一个字最为贴切——“险”！
3比2胜塞维利亚，3比2胜维尔瓦，2比2平萨拉格萨……最后一轮的惊险已经无需多言：只要马洛卡那个单刀再偏十几厘米，也许这一切的努力都将化为泡影。但是，最终我们得到了冠军，我们在丰收女神广场疯狂的庆祝。
明年我们还能再来到女神身旁吗？
看看皇马自身以及竞争对手的情况，我们只能说局面依然困难，但大幕已经开启。
首先，皇马还存在着不少动荡的因素，而且是影响大局的重大因素。
第一，卡佩罗是否留任。本赛季卡帅的表现争议颇多，从球迷到董事会对其看法都有分歧。若不换，卡氏足球是否适合皇马？本赛季的一次次救赎还能否重现？这到底是卡帅的兵行险道还是球员的自我拯救？若重选教练，换帅如换刀，新帅势必带来新的磨合期，新帅的执教理念又会带来怎样的冲击？目前的人员构成能否符合新帅所擅长的打法？
第二，主席是否稳固，球队经理之争结果如何。卡尔德隆摇摇晃晃的坐上主席之位，之后就一直风雨飘摇般的在这个位置上遭受着各方的压力。球队管理上，米亚托维奇和桑切斯的明争暗斗始终存在。当俱乐部的首脑心神不宁，内部斗争纷乱不休，在如此大的内耗下，高层们还有多少力量去管理球队的正常运转，还有多少力量去和其他俱乐部斗智斗力？
接着，球员的去留带来打法的变化。当最后阶段贝克汉姆屡屡帮助球队的时候，多数人都在呼唤着他的留下，当确定要走的消息从他嘴里斩钉截铁的说出来的时候，我们将面临着下个赛季贝克汉姆不在的时候。贝克汉姆不在，代表了任意球质量的下降，代表了右路进攻手段的改变。当我们所依赖的右边路缺少那高质量的传球后，皇马的打法又将转向何方？11年的功勋球员卡洛斯也离去了，卡萨诺离去了，雷耶斯、埃默森、卡纳瓦罗也去留不明，难道让一帮青年近卫军暴露在老谋深算的西甲诸强脚下？年轻队员的起伏不定，经验欠缺也许会将明年变成一份必要的学费。
然后，对手实力的增强。国内赛场群雄并起，巴萨一如既往的强大，传言中亨利的加盟不得不让人对下赛季的巴萨的强大实力产生担忧的心理。放眼国外赛场，现在的国际米兰、AC米兰、切尔西、不可不谓兵强马壮，皇马要想捧起久违的冠军杯，以现在的人员构成还真是前路漫漫。
最后，转会市场困难重重。谁都知道皇马对于卡卡的渴望，可是AC一次又一次的以奇货可居，甚至对我们进行侮辱。还有C罗，罗本，法布，里贝里，阿尔维斯，不是此路不通就是已有所属，转会市场上皇马呼风唤雨的时候已经不复返了，难以补充最需要的人员也会影响下赛季球队人员的构建。
说这些并不是说丧气话，而是我们要把困难估计的足一点。总而言之，下赛季的皇马想要卫冕，想问鼎欧洲还面临着各方面的问题，希望大家各抒己见，谈教练，论打法，说高层，讲转会，展望下赛季的情况。苟用滕王阁序一段作结：
临别赠言， 幸承恩于伟饯； 登高作赋， 是所望于群公。
敢竭鄙诚， 恭疏短引。一言均赋， 四韵俱成。
请洒潘江， 各倾陆海云尔。
四年的渴望有多大的力量？当看到贝克汉姆打封闭上场，卡洛斯、萨尔加多几乎拼命的争抢时，你就知道，这种渴望能给人多大的力量。
四年的收获有多大的幸福？当你看到迪亚拉两次跪着亲吻土地，看到你我彻夜不眠却仍精神振奋的情形，就知道这种发自内心的喜悦能给人带来多大的喜悦。
当胜利的喜悦渐渐平静的时候，我们该想些什么呢？
回顾本赛季皇马夺冠的历程，如果这是一部话剧，即使最有才华的作家也写不出如此惊心动魄、跌宕起伏的剧本，也许上帝本人看了，也会对自己这近乎神话般的创作而惊讶不已。
形容本赛季皇马最后阶段的表演，只有一个字最为贴切——“险”！
3比2胜塞维利亚，3比2胜维尔瓦，2比2平萨拉格萨……最后一轮的惊险已经无需多言：只要马洛卡那个单刀再偏十几厘米，也许这一切的努力都将化为泡影。但是，最终我们得到了冠军，我们在丰收女神广场疯狂的庆祝。
明年我们还能再来到女神身旁吗？
看看皇马自身以及竞争对手的情况，我们只能说局面依然困难，但大幕已经开启。
首先，皇马还存在着不少动荡的因素，而且是影响大局的重大因素。
第一，卡佩罗是否留任。本赛季卡帅的表现争议颇多，从球迷到董事会对其看法都有分歧。若不换，卡氏足球是否适合皇马？本赛季的一次次救赎还能否重现？这到底是卡帅的兵行险道还是球员的自我拯救？若重选教练，换帅如换刀，新帅势必带来新的磨合期，新帅的执教理念又会带来怎样的冲击？目前的人员构成能否符合新帅所擅长的打法？
第二，主席是否稳固，球队经理之争结果如何。卡尔德隆摇摇晃晃的坐上主席之位，之后就一直风雨飘摇般的在这个位置上遭受着各方的压力。球队管理上，米亚托维奇和桑切斯的明争暗斗始终存在。当俱乐部的首脑心神不宁，内部斗争纷乱不休，在如此大的内耗下，高层们还有多少力量去管理球队的正常运转，还有多少力量去和其他俱乐部斗智斗力？
接着，球员的去留带来打法的变化。当最后阶段贝克汉姆屡屡帮助球队的时候，多数人都在呼唤着他的留下，当确定要走的消息从他嘴里斩钉截铁的说出来的时候，我们将面临着下个赛季贝克汉姆不在的时候。贝克汉姆不在，代表了任意球质量的下降，代表了右路进攻手段的改变。当我们所依赖的右边路缺少那高质量的传球后，皇马的打法又将转向何方？11年的功勋球员卡洛斯也离去了，卡萨诺离去了，雷耶斯、埃默森、卡纳瓦罗也去留不明，难道让一帮青年近卫军暴露在老谋深算的西甲诸强脚下？年轻队员的起伏不定，经验欠缺也许会将明年变成一份必要的学费。
然后，对手实力的增强。国内赛场群雄并起，巴萨一如既往的强大，传言中亨利的加盟不得不让人对下赛季的巴萨的强大实力产生担忧的心理。放眼国外赛场，现在的国际米兰、AC米兰、切尔西、不可不谓兵强马壮，皇马要想捧起久违的冠军杯，以现在的人员构成还真是前路漫漫。
最后，转会市场困难重重。谁都知道皇马对于卡卡的渴望，可是AC一次又一次的以奇货可居，甚至对我们进行侮辱。还有C罗，罗本，法布，里贝里，阿尔维斯，不是此路不通就是已有所属，转会市场上皇马呼风唤雨的时候已经不复返了，难以补充最需要的人员也会影响下赛季球队人员的构建。
说这些并不是说丧气话，而是我们要把困难估计的足一点。总而言之，下赛季的皇马想要卫冕，想问鼎欧洲还面临着各方面的问题，希望大家各抒己见，谈教练，论打法，说高层，讲转会，展望下赛季的情况。苟用滕王阁序一段作结：
临别赠言， 幸承恩于伟饯； 登高作赋， 是所望于群公。
敢竭鄙诚， 恭疏短引。一言均赋， 四韵俱成。
请洒潘江， 各倾陆海云尔。
Jun 14, 2007
Sql语言之沧海一滴，时间查询
似乎我最头疼的就是DateTime类型的数据了。一部分原因是由于DateTime数据存储的是
年月日和时分秒，所以处理起来麻烦，还有原因是由于这部分的函数和一些常用的处理方法不熟，一句话，不就是认生嘛。
今天遇到一个问题，Sql Server里面要判断某个日期相等。
即如何与一个DateTime类型的字段值进行相等比较？这其中有这样的问题：
1、一般来说，用户输入的日期值就是yyyy/mm/dd，不带时、分、秒；
2、数据库中存储的日期值是带时、分、秒的。
所以我必须假定：我们所谓的两个日期相等就是年、月、日相等。
这里有一个比较好的处理方法，
即
假定我们要查的日期是2004/7/10，则其实我们想要的就是这一天的00:00:00至23:59:59之间的。提到之间，我们就会想到between...and！！只要 between 2004/7/10 and 2004/7/11 即可了。具体地说：between Cast('2004-7-10' as DateTime) and dateadd(day, 1, Cast('2004-7-10' as DateTime))。但这个方法有一个小小问题，它会把7/11 0点的东西也找到，而这其实不应算做7/10的。如果你还想精益求精的话，就只能用...>=... and ...<... 了。（一般情况下没有必要）
年月日和时分秒，所以处理起来麻烦，还有原因是由于这部分的函数和一些常用的处理方法不熟，一句话，不就是认生嘛。
今天遇到一个问题，Sql Server里面要判断某个日期相等。
即如何与一个DateTime类型的字段值进行相等比较？这其中有这样的问题：
1、一般来说，用户输入的日期值就是yyyy/mm/dd，不带时、分、秒；
2、数据库中存储的日期值是带时、分、秒的。
所以我必须假定：我们所谓的两个日期相等就是年、月、日相等。
这里有一个比较好的处理方法，
即
假定我们要查的日期是2004/7/10，则其实我们想要的就是这一天的00:00:00至23:59:59之间的。提到之间，我们就会想到between...and！！只要 between 2004/7/10 and 2004/7/11 即可了。具体地说：between Cast('2004-7-10' as DateTime) and dateadd(day, 1, Cast('2004-7-10' as DateTime))。但这个方法有一个小小问题，它会把7/11 0点的东西也找到，而这其实不应算做7/10的。如果你还想精益求精的话，就只能用...>=... and ...<... 了。（一般情况下没有必要）
Jun 4, 2007
没有金刚钻，也揽瓷器活
常常责怪自己，当初不应该……
古人云，没有金刚钻，不揽瓷器活。意思和看菜吃饭，量体裁衣，因材施用，量入为出差不多。
这也符合我的想法，我有一个关于择业的论调。
以后如果我的小孩，生出来智商在135以下，那我绝对不让他做程序员。
今天的情形有一次佐证了我的想法。
论文截至日期临近，本来时间非常宝贵，遇到一个解析XML的事情。
不久是遍历嘛，用递归的方法嘛。说是在的，我写程序最喜欢写普通的循环，
遇到递归就头疼的很，好像思维就是没有那种层层推进的感觉。
今天的情况就是：原来以为30分钟就能搞好的代码，从8点钟开始写，不断的修正，不断的实验，总是看不到我想要的结果，如果我练过铁头功，那么我住的地方现在已经是蜂巢了。
终于到下午2点钟，得到了我想要的结果。虽然最终实现了自己的需求，但是我不禁在想，如果一个厉害的人，估计是不用这么长时间，就能很轻松的搞定这个事情，唉，我这又是何苦呢，走上了这一条和编程相关的工作。
然而既然走上了这条道路，就要一直走下去，而且要很努力的奋然前行，总有一天你会看到，就是当年“没有金刚钻，也揽瓷器活”的勇气，带来了日后令人欣慰的成绩。
祝天下所有没有天赋的程序员，拥有好运。
Jun 3, 2007
惠普，你要加油了
惠普给我的印象一直是不上不下。感觉什么都做，却又往往都做不到第一。卖电脑卖不过Dell,做电脑做不过华硕，做软件服务做不过IBM, 卖服务器也卖不过蓝色巨人，也许只有打印机的业务还勉强说的过去。
去年因为招聘的事情，惠普给我的印象很不好，不过话说回来也应该感谢他，也算是机缘巧合了。
为什么现在又提起这个本来和我没什么干系的公司呢？
因为我现在在用jena插件——一个查询本体的API。
发现jena的版本里面好多东西真的做的不怎么样，举几个例子。
我们知道OntClass有listSuperClasses的函数，但是Individual就没有了？
你能说“歼击机”的上位类是“军用飞机”，而F16就没有上位类了？
还要我从Root还是查找到实例，从上到下梳理一遍，不知道HP那些人怎么想的。
还有，
在API Document中指出， listSuperClasses(boolean direct)
如果：listSuperClasses(true)，则仅仅列出直接的上位类，
如果：listSuperClasses(false)，则把它的祖宗们全找出来，
结果发现呢，无论true还是false,结果都是一样。这叫什么？不负责任。
同样还有listSubClasses(boolean direct)，都犯了同样的错误，令人无语。
也许他们不知道，就是这样的一些缺陷，不断消磨了潜在顾客的信心，
小处不慎，焉能托之以江上社稷也？
也难怪步步维艰了，HP,你要加油了。
去年因为招聘的事情，惠普给我的印象很不好，不过话说回来也应该感谢他，也算是机缘巧合了。
为什么现在又提起这个本来和我没什么干系的公司呢？
因为我现在在用jena插件——一个查询本体的API。
发现jena的版本里面好多东西真的做的不怎么样，举几个例子。
我们知道OntClass有listSuperClasses的函数，但是Individual就没有了？
你能说“歼击机”的上位类是“军用飞机”，而F16就没有上位类了？
还要我从Root还是查找到实例，从上到下梳理一遍，不知道HP那些人怎么想的。
还有，
在API Document中指出， listSuperClasses(boolean direct)
如果：listSuperClasses(true)，则仅仅列出直接的上位类，
如果：listSuperClasses(false)，则把它的祖宗们全找出来，
结果发现呢，无论true还是false,结果都是一样。这叫什么？不负责任。
同样还有listSubClasses(boolean direct)，都犯了同样的错误，令人无语。
也许他们不知道，就是这样的一些缺陷，不断消磨了潜在顾客的信心，
小处不慎，焉能托之以江上社稷也？
也难怪步步维艰了，HP,你要加油了。
Jun 2, 2007
dom4j 中文问题：java.io.UTFDataFormatException: Invalid byte 1 of 1-byte UTF-8 sequence.
几乎每一个编程的人都会遇到中文的问题，但偏偏你可能不知道问题是由于中文引起的，而往往从代码逻辑中寻找原因。也难怪，谁能想到我们伟大祖国的文字在八国联军以及小日本鬼子的开发工具里面就成了导致错误的罪魁祸首了呢？
在XML的开发中，我就遇到了类似的问题。
在Dom4J的API支持下，
用
Document document=null .........
XMLWriter output = new XMLWriter(new FileWriter(new File( "c:/test/Interest.xml")));
output.write(document);
然而在用SAX解析的时候却出现了这样的问题：
SAXReader saxReader = new SAXReader();
Document document=null;
document = saxReader.read(inputXml);
报错：java.io.UTFDataFormatException: Invalid byte 1 of 1-byte UTF-8 sequence.
查了半天代码，最后才发现：是UTF字符的问题。当XML中含有中文，而没有指定XML Encoding="UTF-8"的时候，就会产生这样的错误。（咬牙切齿，磨刀霍霍向鬼子）
修改方法：
OutputStream os=new FileOutputStream("c:/test/Interest.xml");
XMLWriter output=new XMLWriter(new OutputStreamWriter(os,"UTF-8"));
output.write(document);
总有一天，我们要用我们的冠绝天下的工具来折磨那些不重视我们中国语言的人。
在XML的开发中，我就遇到了类似的问题。
在Dom4J的API支持下，
用
Document document=null .........
XMLWriter output = new XMLWriter(new FileWriter(new File( "c:/test/Interest.xml")));
output.write(document);
然而在用SAX解析的时候却出现了这样的问题：
SAXReader saxReader = new SAXReader();
Document document=null;
document = saxReader.read(inputXml);
报错：java.io.UTFDataFormatException: Invalid byte 1 of 1-byte UTF-8 sequence.
查了半天代码，最后才发现：是UTF字符的问题。当XML中含有中文，而没有指定XML Encoding="UTF-8"的时候，就会产生这样的错误。（咬牙切齿，磨刀霍霍向鬼子）
修改方法：
OutputStream os=new FileOutputStream("c:/test/Interest.xml");
XMLWriter output=new XMLWriter(new OutputStreamWriter(os,"UTF-8"));
output.write(document);
总有一天，我们要用我们的冠绝天下的工具来折磨那些不重视我们中国语言的人。
Jun 1, 2007
关于SAX，DOM，JAXP，JDOM，DOM4J的一些理解（转）
第一：首先介绍一下SAX，DOM，JAXP，JDOM，DOM4J的基本知识：（注意：至于 JAXP JAXB JAXM JAXR JAX-RPC 分别指什么，查看http://gceclub.sun.com.cn/staticcontent/html/xml/faq/#jaxr_）
1、sax、dom是两种对xml文档进行分析的方法（没有具体的实现，只有接口）所以不是解释器，如果光有他们，你是完成不了对xml文档的处理的。sax的包是org.xml.saxdom的包是org.w3c.dom包的名称很重要，它有助于你理解他们之间的关系。
2、jaxp是api，他封装了sax\dom两种接口。并在sax\dom的基础之上，作了一套比较简单的api以供开发人员使用。jaxp的包是javax.xml.parsers可以看看jaxp的源文件，它的文件中包含了对sax或者dom的引用（import）jaxp也不是具体的实现，他只是一套api。如果你仅仅有jaxp那是无法工作的（其实jaxp只是完成对sax、dom的包装，生成了DocumentBuilderFactory\DocumentBuilder和SAXParserFactory SAXParser。也就是设计模式中的工厂模式，他的好处就是具体的对象（ 解释器）建立由子类完成）
3、xerces解释器（号称地球上最快的xml解释器）在xerces中对jaxp中定义的SAXParser SAXParserFactory DocumentBuilder DocumentBuilderFactory进行了继承（extends）对应SAXParserImpl SAXParserFactoryImpl DocumentBuilderImpl DocumentBuilderFactoryImpl这就是为什么你的classpath中只要有xerces.jar（其中包含了sax dom jaxp ）和 xercesImpl.jar就可以的原因了.
4、什么时候可以用别的解释器 比如crimson呢他也是和xerces一样 是解释器，很简单，用crimson.jar 替代xercesImpl.jar
5、jdom和dom4j W3C的DOM标准API难用的让人想撞墙，于是有一帮人开发Java专用的XML API目的是为了便于使用，这就是jdom的由来，开发到一半的时候，另一部分人又分了出来，他们有自己的想法，于是他们就去开发dom4j，形成了今天这样两个API，至于他们之间的性能，jdom全面惨败，dom4j大获全胜。我觉得jdom和dom4j就相当于sax/dom+jaxp，具体的解释器可以选择。
第二：再介绍一下，dom,sax,jdom,dom4j的技术特点：
1: DOMDOM 是用与平台和语言无关的方式表示 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 http://www.jdom.orgJDOM 的目的是成为 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 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。
最后：我建议用dom4j
JDOM 和 DOM 在性能测试时表现不佳，在测试 10M 文档时内存溢出。在小文档情况下还值得考虑使用 DOM 和 JDOM。虽然 JDOM 的开发者已经说明他们期望在正式发行版前专注性能问题，但是从性能观点来看，它确实没有值得推荐之处。另外，DOM 仍是一个非常好的选择。DOM 实现广泛应用于多种编程语言。它还是许多其它与 XML 相关的标准的基础，因为它正式获得 W3C 推荐（与基于非标准的 Java 模型相对），所以在某些类型的项目中可能也需要它（如在 javascript 中使用 DOM）。 SAX表现较好，这要依赖于它特定的解析方式。一个 SAX 检测即将到来的XML流，但并没有载入到内存（当然当XML流被读入时，会有部分文档暂时隐藏在内存中）。 无疑，DOM4J是最好的，目前许多开源项目中大量采用 DOM4J，例如大名鼎鼎的 Hibernate 也用 DOM4J 来读取 XML 配置文件。如果不考虑可移植性，那就采用DOM4J吧！
1、sax、dom是两种对xml文档进行分析的方法（没有具体的实现，只有接口）所以不是解释器，如果光有他们，你是完成不了对xml文档的处理的。sax的包是org.xml.saxdom的包是org.w3c.dom包的名称很重要，它有助于你理解他们之间的关系。
2、jaxp是api，他封装了sax\dom两种接口。并在sax\dom的基础之上，作了一套比较简单的api以供开发人员使用。jaxp的包是javax.xml.parsers可以看看jaxp的源文件，它的文件中包含了对sax或者dom的引用（import）jaxp也不是具体的实现，他只是一套api。如果你仅仅有jaxp那是无法工作的（其实jaxp只是完成对sax、dom的包装，生成了DocumentBuilderFactory\DocumentBuilder和SAXParserFactory SAXParser。也就是设计模式中的工厂模式，他的好处就是具体的对象（ 解释器）建立由子类完成）
3、xerces解释器（号称地球上最快的xml解释器）在xerces中对jaxp中定义的SAXParser SAXParserFactory DocumentBuilder DocumentBuilderFactory进行了继承（extends）对应SAXParserImpl SAXParserFactoryImpl DocumentBuilderImpl DocumentBuilderFactoryImpl这就是为什么你的classpath中只要有xerces.jar（其中包含了sax dom jaxp ）和 xercesImpl.jar就可以的原因了.
4、什么时候可以用别的解释器 比如crimson呢他也是和xerces一样 是解释器，很简单，用crimson.jar 替代xercesImpl.jar
5、jdom和dom4j W3C的DOM标准API难用的让人想撞墙，于是有一帮人开发Java专用的XML API目的是为了便于使用，这就是jdom的由来，开发到一半的时候，另一部分人又分了出来，他们有自己的想法，于是他们就去开发dom4j，形成了今天这样两个API，至于他们之间的性能，jdom全面惨败，dom4j大获全胜。我觉得jdom和dom4j就相当于sax/dom+jaxp，具体的解释器可以选择。
第二：再介绍一下，dom,sax,jdom,dom4j的技术特点：
1: DOMDOM 是用与平台和语言无关的方式表示 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 http://www.jdom.orgJDOM 的目的是成为 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 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。
最后：我建议用dom4j
JDOM 和 DOM 在性能测试时表现不佳，在测试 10M 文档时内存溢出。在小文档情况下还值得考虑使用 DOM 和 JDOM。虽然 JDOM 的开发者已经说明他们期望在正式发行版前专注性能问题，但是从性能观点来看，它确实没有值得推荐之处。另外，DOM 仍是一个非常好的选择。DOM 实现广泛应用于多种编程语言。它还是许多其它与 XML 相关的标准的基础，因为它正式获得 W3C 推荐（与基于非标准的 Java 模型相对），所以在某些类型的项目中可能也需要它（如在 javascript 中使用 DOM）。 SAX表现较好，这要依赖于它特定的解析方式。一个 SAX 检测即将到来的XML流，但并没有载入到内存（当然当XML流被读入时，会有部分文档暂时隐藏在内存中）。 无疑，DOM4J是最好的，目前许多开源项目中大量采用 DOM4J，例如大名鼎鼎的 Hibernate 也用 DOM4J 来读取 XML 配置文件。如果不考虑可移植性，那就采用DOM4J吧！
Subscribe to:
Posts (Atom)