Java堂  

为了防止升级失败我特意用sqlYog将数据备份了一下，然后升级的过程中没有任何问题，因为我发现原来的栏目排列有些改变，于是就直接清空数据然后再导入备份过的数据重新安装一下系统。当前清空数据库的时候没有多想，反正之前有备份。这个时候问题出现了：导入备份后的数据全部变成了乱码！确切的应该说是错码才对，因为出现的不是问号而是一些错误的中文字。

反复试了很多种方法依然是无效，后来从sqlYog官方网站上查到sqlYog从6.0开始每次生成的sql文件编码都是utf-8格式的，另外在操作数据之前都使用

将所有的环境都设置为utf8编码，你可以在sqlYog的查询窗口中使用

查看一下语言环境。sqlYog在查看数据的时候首先查看原来数据库设置的编码格式，然后将其转换为utf8格式的数据，最后输出出来；如果修改数据则相反。上次我在博文中提到使用sqlYog6.03可以直接查看gbk编码的数据，但是查看utf8格式的编码是乱码，我觉得这应该是sqlYog6.03版本中转换编码算法的一个bug，果然在最新发布的6.10rc版本中就修复了这个错误；另外一个就是根数据库默认设置的编码也有很大的关系，因为MySQL使用的默认编码是latin1，正是这样一个非常具有历史原因的设置成为了造成乱码的最直接的原因。这里可能有人会说不是sqlYog操作之前都已经将环境设置为utf8格式了吗？这个时候应该跟MySQL本身的编码没有任何关系了呀。sqlYog操作的时候是不会有关系，但是其他进程(比如php、java等)操作的时候呢？数据写入的时候已经出现乱码了，问题就出在这里。所以为了完全杜绝MySQL的乱码问题，建议将MySQL的默认编码设置为utf8格式。

因为wordpress数据库中的编码都是utf8格式的，我又使用的sqlYog6.03版本，所以无论查看还是备份utf8的数据都是乱码。最后只能是逐一从百度快照中将数据找出来添加到数据库中，因为我在wordpress中设置的remark规则跟时间和最后的数据id号有关系，为了不至于造成在百度中搜索出来的结果失效，所以首先先将原来数据库中的这些数据导入到新的数据中。当然这个时候wordpress已经升级成2.3了，呵呵(苦笑中…)

目前在2006年8月份之前的数据还没有恢复，将近有80条。我会在最近这段时间将他升级完成的。

参考资料：Which MySQL Character Sets are supported by SQLyog?