xml文件是Extentsible Markup Language（可扩展标记语言）的缩写。XML文档可以是有效的（valid），但并非一定要求有效。所谓有效文档是指其符合其文档类型定义（DTD）的文档。

创建xml文件的工具

xml文件和html文件一样，实际上是一个文本文件。显然大家立刻就会明白，创建xml文件最普通的工具和html一样，就是“记事本”了。除了“记事本”之外，当然还有一些更加方便的工具，如xml notepad、xml pro、clip！xml editor等，这些工具的一大特点是：能够检查你所建立的xml文件是否符合xml规范。不过，现在这些工具都只有英文版的，并且需要付费使用。当然，你仍然能够使用frontpage、dreamweaver等工具，不过使用起来不是很方便。随着xml的逐渐普及，相信在不久后，也会出现非常好用的创建xml文件的工具。

相关介绍

测试程序时，java抛出了system.SetCharacterEncodingFilter.doFilter(SetCharacterEncodingFilter.java:42)相关的java.lang.IllegalStateException

最奇怪的是与id相关，有些数据库读的ID出错，有些不出错。因此就与网上所有提出此一错误的贴子，完全不投契。只能倒转从home.jsp从查找出错的代码行。

开始估计是由于gbk转换时，把文本中的xml的gbk设置给干掉了。因此要回到数据库层面。

按昨天处理的字符集信息，倒回到原来的latin1，这是没有经过字符处理的文件。但是结果仍然出错。

逐段检查下来，错误居然是这个毫无问题的字段

<chn><![CDATA[疼痛科]]></chn>

进一步的检查确认，这是因为读取longtext字段的xml时，digester要分析的文件里的中文是乱码，因为乱码干扰了xml分析器识别的文本标记，所以程序解释出错。

现在的问题是，数据库送过来显示的中文却是正确的。但是java中提取分析的xml数据，却是错误的。

开始时想到，可能是因为此前修改字段时，修改过request，应该可以将一个原封的应用目录抄过来，看看是否正常。

转换后仍是如此，排除了没有修改过来的可能性。事实上，如果没有修改过来，也不能通过第一次编译。

这个问题有点印象，以前碰到过。恢复的程序版本参差，有些地方可能自相矛盾。只能一点点digbug

进一步发现，成功打开过的xml实体bean自动存回数据库时，代码是变乱了。即它读到的是乱码，写回起也是乱码