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

从昨天晚上开始奋战到凌晨一点三刻无果，今早大约七点三刻起来又继续尝试，经过了无数次的安装——恢复——升级，直到刚才12：30才算是终于搞好了，有些心得体会愿与各位共享：

1.首先一定要备份！！数据库不大的话就选完全备份！我使用的是国外的免费空间，数据库到达了20多M，选的标准分卷备份，1M一个有24个，2M一个有12个文件；
这可实在是让我费了不少周折！
2.我是一开始upgrade25to4在第三步失败了，只好先进行数据恢复了：重装2.5F没费多少事，因为是和D4目录分开的；不过后来恶梦就开始了，2.5F自带的恢复功能居然不起任何作用！我想通过PMA导入也不行！毕竟空间在国外，没那么快的上传速度！就在我快要绝望的时候发现了restore.php，虽然麻烦一点，开始我是24个1M的分卷，也就要运行24次，但毕竟是可以把数据库给恢复过来了。
3.然后上传upgrade30.php和db_mysql.class.php以及db_mysql_error.inc.php（这个文件没有错误的话应该是不需要的），接着把config.php改为config.inc.php，再运行
upgrade30就可以顺利完成了。
4.上传d3ftod4.php并修改config.inc.php，里面的字符编码设为GBK，运行d3ftod4就可以成功完成了，然而乱码也就随之产生了……

凌晨看了很多关于乱码问题的帖子也尝试了不断更换各种字符编码均未能解决问题。
后来发现有帖子说可以通过PMA更改字符编码，又加上我对其他帖子内容的理解以及对PMA的进一步摸索，一个解决方案基本浮现在我脑海里了，但是已经太晚了，我要睡觉了，只好决定早起再战！

1. 我又重新安装了2.5F，然后我想下载我那24个备份文件，没想到这个国外的空间好像是对下载速度和下载时间综合进行限制的，我一高速下载大文件就断（速度低于5K好像就不断了），还不支持续传！唉——还有一些我尝试下载的细节我就不细说了。总之是又运行了24次restore，而且这也早不是第二三回了！所以我就想起来又备份了一次，这次是12个2M文件了，少了一半，恢复起来方便多了。
2.但是下载的问题还是一直困扰着我！在我万般无奈之际，想到用国外服务商提供的基于WEB的文件管理时，突然相到了HTTP，^_^，我立刻使用FLASHGET批量建立下载任务！IT IS VERY GREAT！我以几十K的速度把那12个备份文件都下载下来了！
3.接着我用CRIMSON EDITOR（喜欢用ULTRAEDIT的也可以，本人更喜欢免费软件）在这12个文件中进行批量查找latin1，好像共有24处，这也就是说有24个表是用这种字符集进行定义的；然后我就用替换功能把它们全部改成gbk，实际上也就是只有第1个和第12个文件中有需要替换的内容，所以我就只需要再把这两个文件传回去就可以了。
4.进入PMA，在数据库最右边有“操作”菜单，点击进入以后最下方有“整理”功能，在这里可以设置数据库默认的字符集，我于是把它从以前的latin1_swedish_ci改成了gbk_chinese_ci，然后我又运行restore12次恢复了我的数据库，可以看到PMA里面的字符集都已经变过来了，但是这时在打开2.5的话，好像就有乱码了（我记不清了），然后又重复上面的步骤，先升级到3.0，再升级到4.0，很遗憾还有乱码没有成功！

没有办法，只好又再次重复安装2.5F并再恢复升级之路，不过这次我又将数据库默认的编码改成了utf8_general_ci（这里不知与utf8_unicode_ci有什么区别？，而且我的MYSQL似乎默认编码就是utf8_unicode_ci，不过D4的UNICODE似乎用的是utf8_general_ci，所以我就选了这个，另外也不建议大家再尝试使用utf8_unicode_ci，因为我好像也试过是不行的），当然这次需要把那两个备份文件中的gbk再次替换为utf8；然后又恢复数据库以后，我看到2.5F看到的一切正常，PMA里显示的各种数据表的字符编码都是utf8_general_ci，但是浏览器识别的编码是GB2312；我想这应该没有什么关系，接着再升级到3.0，然后把config.inc.php中的编码改成utf-8，再用UTF8的简体版本升级到了4.0，不过很遗憾恼人的乱码又出现了！

再后来我对这4.0的编码转换真是有些心灰意冷了！不过我还是继续尝试了——把config.inc.php中的编码又改为gbk，然后又用gbk的版本升级，结果还是乱码！不过这次我在转换之前也终于是不怕麻烦，又上传了3.0的所有文件，并确认显示正常以后，再次进行了数据备份。这样做的结果也是十分令我欣喜和欣慰的，因为我后来发现3.0自带的恢复功能终于又可以正常自动运行了，省掉了我多次运行restore的麻烦！

在经过了这么多次的安装恢复升级尝试以后，我也是彻底搞不懂D4升级的编码转换了！
万般无奈之下，我只好选择了屏蔽D4升级的代码转换，也就是：

更改连接方式
Discuz! 4.0.0
对于Discuz! 4.0.0正式版，您可以找到./include/db_mysql.class.php，将

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

然后再运行d3ftod4就可以了

推荐给酒旗风。

1. 在2.5升级到4.0的过程之中不要怕麻烦，我从来没装过什么插件，没想到直接升级还会失败了！所以也就丢掉了几天的备份。所以备份是非常重要的！升级之前一定要先备份！数据库不大的话就选完全备份，这样就可以免去多次重新安装旧系统的麻烦！

2. 还是不要怕麻烦，其实时常是捷径！也就是说在升级到3.0的数据库结构以后，也要把3.0的文件全部上传，再做一次数据备份！这样以后就可以省掉很多麻烦！

3. 在没有数据库的DUMP权限的时候，而且自己的数据库是MYSQL4.1的话，最好在升级到4.0之前，将D4的连接方式更改一下，不要再折腾了！

4. D4.1配置中新增的数据库编码设置，我在出现乱码时也进行过多种组合方式的尝试，结果都是失败的！所以我认为D4在升级处理代码转换时似乎是有一点问题的。

最后欢迎大家访问我的小坛子：
暂时为：
http://easteden.net
以后会改为：
http://bbs.easteden.net

恭喜，我4.0想升级4.1一直失败！哎

就要准备开始升级4.1了，刚看了一下现在的数据库变成34.97M了，我想可能因为数据库是utf8编码的缘故吧，不过又备份了一下还是12个文件！看来备份并不是按照utf8来的

原以为升到4.0以后，再升4.1就很容易了，没想到也还是费了一点功夫！

1. 首先备份了4.0，然后运行upgrade6很顺利，不幸的是部分乱码又出来了！用PMA看了一下数据库结构，发现有些表变成了gbk_chinese_ci，我想这样不好，还是统一utf8_general_cid的好，于是首先恢复4.0，然后把config.inc.php里面的字符编码改成utf-8，再次运行upgrade6就失败了！于是想到先重新安装4.0，没想到安装过程一到要开始创建表的时候就出错！说什么SQL语法不对！没办法只好在度重新安装3.0，再恢复升级！结果还是怎么都避免不了乱码

2. utf8还是显示乱码，将config.inc.php里面的字符编码又改为gbk也还是不行，不过4.0的显示还是正常的，我又找了以往别人的升级经验，才算是又在4.1中看到了正常的显示！也就是说要修改db_mysql_class.php，把下面这段代码注释掉
                        if($dbcharset) {
                                mysql_query("SET NAMES '$dbcharset'");
                        }
再更新一下缓存就好了。

3. 对于4.0&4.1的一点看法：4.0增加了字符编码以后，兼容性很不好！居然会出现无法全新安装的现象！4.1增加了数据库编码的配置，但是也很不好用，无法通过这个参数避免乱码的显示！

补充：注意上面对于字符编码有关的代码注释，应在运行upgrade6升级之前就做好

刚发现是表明上看似正确，但是各个论坛里面都不能显示出来原来的发帖数据！
这到底是怎么回事？是THREAD表的数据丢失了吗？能够重新建立索引吗？
恢复到4.0也没有！3.0也没有！现在已经太晚了，只好睡觉起来下班回来再恢复到2.5了：（