费劲周折终于把2.5F完成升级到4.0并解除乱码

恢复2.5F以后，又做了一些尝试，并总结规律如下：

1. 2.5FSP1的database.php是好的，可以自动连续恢复2.5F的备份；
也可使用2.5FSP1的install.php先安装2.5F再恢复2.5F的备份，且不需要再升级为SP1；

2. 将数据库默认的编码设为gbk_chinese_ci，再重新安装2.5F，并使用修改为创建gbk表的备份恢复数据库以后，确实就会出现乱码；而将数据库默认的编码设为utf8_general_ci，再重新安装2.5F，并使用修改为创建utf8表的备份恢复数据库以后，就不会出现乱码。所以建议将数据库的默认编码改为utf8_general_ci

3. 3.0FB3的数据备份功能不要用！会丢失重要数据信息（THREAD表）

4. 升级4.0之前先修改连接方式：找到./include/db_mysql.class.php，将

mysql_query("SET NAMES '".str_replace('-', '', $GLOBALS['charset'])."'");
前面加上“//”，即将其注释掉

然后再运行d3ftod4就可以没有乱码了

5. 在升级到4.1之前再次需要先修改连接方式：同样找到db_mysql_class.php，
把下面这段代码注释掉
                        if($dbcharset) {
                                mysql_query("SET NAMES '$dbcharset'");
                        }
然后再运行upgrade6就可以避免再次出现乱码

6. 不过utf8的数据库确实有点大，在没有丢失数据的情况下，我大约24M的数据库变成了39.8M的！不过用D4的分卷备份还是大约24M的样子。

再次补充：

开始把数据库默认编码改为gbk并重新安装再恢复数据库以后，并不都是乱码，而是好多的问号！通过PMA查看有些表还是uft8的，而一开始使用utf8的话，最后恢复好数据库以后就全是utf8的表了；但是升级到4.1时，如果不注意在config中设置为gbk的话，就又会多出6个gbk的表来。虽然数据库是utf8的，但不要使用utf8的D4，照样会有乱码！还是使用gbk的D4就可以了。

现在又发现一个很奇怪的现象：

用PMA看数据库里面的中文内容是乱码，但是用Discuz来看就没有乱码了

在PMA中浏览器识别的是UTF-8，改成GB2312乱码更多；在Discuz中浏览器识别的是GB2312，一切显示正常