昨天通过mysqldump，将数据库字符集转换到gbk，过程算得上颇为顺利。但再次意外的是，居然没有解决问题。当数据量比较多的时侯，mysqldump转换字符集不太可靠，特别是采用外部工具修改大文件里面的字符名称，可能会导致一些不该改的也改了，结果几万条sql在插入过程中，可能就会出错。空的小的数据库很容易处理，大的话，文件达到一个G以上，不可能作任何编辑。所以要分两步走，先将它dump出表文件，然后再dump出数据。表文件容易修改，数据文件不用修改。
这样处理后，重新生成数据库，mysql < .sql文件，就搞完了。原来的latin1的原库仍然备份着，以备解决可能出现的问题。没想到真出了问题。如同上一次一样，手工检验mysql --default_charater_set=字符集，证明是gbk，可以在CRT中检索。 上一次是可以检索的字符集是latin1。
然后采用测试页面jdbc:uri检索，同样的编码，上一次是需要将<%contentype%>设为latin1，才能读出了正确的latin1字符，同时却把浏览器搞糊涂了，需要手工指定简体中文，——这不可接受。因此预计如果完全是gbk，就不需要修改contentype，这样就可以直接显示中文。谁知道，显示出来是问号！前后完全不一致。很大的疑问是，如果我手工可以访问正常，不能证明j正常，那又说明了什么？1+1被发现不等于2，就会有点投降的感觉，检索网上资料，从来没有人碰到过这种情况。
一次次地试，修改这里，修改那里，查找网上所有资料，无一对头。不过也渐渐更深入地了解到内部的过程。以前都没有怎么注意，也发现网上很多人的经验，也是知其然“忽然行了”，不知其所以然。无意中想到，“defaultset那里改一改，看看会不会出奇迹？”，改到utf-8，忽然好了。useUnicode=true&characterEncoding=utf-8原因呢？需要重新组织起来。