xml乱码不会是读数据库的原因。因为数据库直接打出来是正确显示的中文。但是这里因为经过浏览器的转换，不太清楚浏览器是否接受到的utf还是gbk，看不出来。java的XML解释器直接处理文本，如果不是刚好的那一种文体，解释和重新生成xml都会出错。所以需要做一个测试程序。
当初在设计该系统时，引入了java和xml的对象绑定的概念，而没有使用sql生成后输出表格的做法。主要原因是数据结构复杂后，多重关联的sql只适合使用在查询量较少的内部网站如Arp2之类的系统，采用对象化绑定的做法可以简化查询。道理是数据库直接存储的就是xml，xml本身就是对象化结构，所以可以直接通过程序，转化为java的对象；在处理完毕后，再自动存回数据库。这样调用时，只要给一个ID，类文件就可以按照提取的数据初始化为一个对象。
其实就是J2EE的概念。J2EE有现成的，但总是不太成熟的应用产品可卖，只不过价格昂贵，而我们能够用得上的功能又叫是一小部分，而且似乎自已实现也不太困难。所以我就自已编了这个系统出来，用的时侯还挺好用。只不过在开始布置时，就会碰到这样那样的问题。degbug清光后，就顺了。这里应该已经完全degbug过的，但在系统灾难后，不知怎的又出错的，有可能是某人某年某月动过了这个备份版本中的某些东西，有了bug，只能一点点地查找。
系统在jakarta中，通过引入现成的structs，提供了自已定造tag的功能。这个tag比以前的serverlt有改进，提供了联结jsp和bean的工具，而且调用上与一般的html:tag没有什么区别。所以jsp也简化了。数据库对象实例化，通过一个实体bean，从request中取得了id，实例化成java对象，然后放在对话上下文中。中间经过了两个过程，第一个是从数据加得到的一个不带XML解释的对象DAO，与j2ee的bean一样。然后按默认的xml字段提取其中的xml字段，通过一个合并了数据库读取的DAO接中的虚拟类，使用apache.Digester digester = ((XPROCESSOR)(clazz.newInstance())).getDigester(this);得到了对xml的解释，然后将它填充到一个与之字段相同的xmlobject类中。数据库字段与entytie字段需要一模一样；还有xml类，则通过一个自动编写代码的程序，读取用xml描述的结构字段，自动生成。每次修改后就自动生成一次。
检查虚拟类（xml对象实体类，全部继承这个类的方法，这样就只需要编写一次）；
在从xml字符串解析出对象的方法中：
//由xml字段转为内部集合对象
public void doSychronize() throws Exception{
System.out.println("doSynchroize here ");
String name ="xml";
String value =(String)BeanUtilities.invokeGetter(this,name,getClass(),true);
value =Utilities.chknull(value);
if(value!=null){
String sxpro =null;
try{
if(this.entity==null) throw new Exception("entity为空,不能同步XML属性");
sxpro =entity.getCls().getXpro();
Class clazz =Class.forName(sxpro);
Digester digester = ((XPROCESSOR)(clazz.newInstance())).getDigester(this);
//准备解释的xml文本；
byte[] bts =value.getBytes("gbk");
ByteArrayInputStream stream =new ByteArrayInputStream(bts);
digester.parse((InputStream)stream);
}catch(Exception ex){
String msg ="in the VEntity.doSynchronize,——>sxpro:="+sxpro+";entity:="+entity+";msg:="+ex.getMessage();
logger.error(msg,getClass());
throw new Exception(msg);
}
}
}
将 byte[] bts =value.getBytes("");默认取得的符串，改用 byte[] bts =value.getBytes("gbk")，暂时解决了问题。
这也证实从数据加读出来的是gbk字符集的串，所以就更难理解，为什么当时的连接字段是setUnicode=true&defaultset=utf-8
另一个现实的问题是，除非此后曾经作过类似的修改，总之，为什么先前的库读取（肯定也是gbk），解析就没有事？中间环节太多，一时想不通，暂时也不重要，到处理完眼前的恢复，再细细回味。