[原创]数落数落Jdom和dom4j

这两个开源包都有相当久远的历史，也是最常用的XML包。想必大家都会认为它们比较稳定了吧？殊不知他们也有很多不尽如人意的地方。也许大家平时不太会注意，这里说出来只是希望大家能注意一下，不要因为这些问题影响工作。

1、 Attribute不能超过1W个！
无论是Jdom还是Dom4j，解析XML时一个标签内的Attribute不能超过1W个。这点两个包问题是同样的。如果需要用XML传输大量数据的话最好不要使用Attribute来传输。不然不知道什么时候就超过1W个，导致程序出错。我们项目中是使用一个字符创Attribute来存放所有信息，最后拆字符串的方法来做的。

2、大量Attribute的标签解析后获得的数据有可能会混乱。
问题同上，差不多上千的时候。解析出来的Attribute就开始产生混乱了。怎么个乱法呢？有很多包含了%的Attribute的一部分回合另外一些Attribute的一部分互换。这点比较费解，并且同样是两个包都会存在的问。


一时想不起来了。。。以后慢慢补充吧。。。

几千个Attribute...汗一个。

我觉得“用XML传输大量数据”本身就是个错误。

大量数据如果放在作为content的话，光标签就占去很多资源，所以选择了放在Attribute里面。

可是现在Ajax、WebService、CSV以及一些文件 还是要用XML存储和传输数据的呀。

“用XML传输大量数据”

这个出发点就错了。

“大量数据如果放在作为content的话，光标签就占去很多资源，所以选择了放在Attribute里面。”

这个用法则是错上加错。

总结一句话：没有不好的技术，只有不适当的用法。硬要开宝马去耕田的感觉...

同意楼上的。

开宝马去耕地的比喻很恰当。

如果非要传输大量的数据，为什么不考虑FTP或者更合适的协议呢？

而且把一万个attribute放到一个节点中， 不觉得很不合适吗？

在正常的XML中，属性不超过10个。

至于下面的：



Ajax我不看好，不发言。
WebService 是可以将对象序列化。这个序列化是WebService的实现框架自动生成，里面的内容很规范，一个节点里不超过10个属性。脉络非常清晰。

另外我也没看明白“光标签就占去很多资源”这句话的意思。呵呵。。。

如果非要将大量数据做传输，我也经历过。把数据分成2K多块，然后通过2K多个小的XML文件来循环传输。完成了，但是效率太低。

希望LZ好好想想，是不是XML技术用的不太恰当。

SOAP也只适合传点小数据小对象。不知道现在这个序列化过程有没有精简，04年用AJAX的时候传100个对象都觉得慢（java->delphi）

恩，可能我是有点欠考虑。没有把技术用到地方。我再思考思考