如果你转换过程中出现: 乱码,丢帖,丢用户,丢版块,错误率过高,不是错误都被程序识别为错误,DV的UBB和DZ的UBB的差异 等等等等,认真的看完这篇文章,应该对你会有帮助的.
目的 : 通过试验的方式寻找一个从DV7.0 to Discuz!5.0.0(GBK,utf-8)最好的方法
使用程序 : 动网DvBBS 7.x Access to Discuz!5.0.0 转换程序 v1.3.3
QUOTE:
环境一: WINXP IIS PHP5.1.4 MySQL5.0.24
DV7.0 ACC数据库500M
1.重复用户名问题
重复用户名 f*****g 不能被转换，uid = 924 ；
转换报告中有这么一行,我觉得好奇怪,原来的DV数据库是如何有两个一模一样的会员ID捏?是DZ的转换程序搞错了?
我打开MDB来看,我晕923,924,都是f*****g这个会员.
两个ID的注册时间均为:2003-11-24 10:32:36
923 最后登陆时间:2004-6-28 16:33:31
924 最后登陆时间:2003-11-24 10:55:18
ID924 是一个死帐号.不会影响最终转换结果的正确性,因为这个ID本来就是多余的,^_^
很显然DZ的转换程序转出来的结果是没有错的.
那是谁的错捏?IIS?MDB?ASP?DV?应该是其中的一个吧,iis嫌疑更大.
2.DZ5(GBK) VS DZ5(UTF8)
DZ5(GBK) 转换报告如下:
转换会员数据 失败 61 条，成功率：99.92744487%
转换主题与投票数据 失败 24 条，成功率：99.9350385708%
转换帖子数据 失败 337 条，成功率：99.9420524108%
转换短消息数据 失败 8 条，成功率：99.9873493785%
DZ5(UTF8) 转换报告如下:
转换会员数据 失败 63 条，成功率：99.9250660133%
主要错误是因为”非法用户名”,其次是”重复用户名”,也有几个用户名长度超过15的.
转换主题与投票数据 失败 24 条，成功率：99.9350385708%
转换帖子数据 失败 337 条，成功率：99.9420524108%
转换短消息数据 失败 8 条，成功率：99.9873146753%
提示错误是:”错误 1064：可能原因：1.数据超长或类型不匹配；2.数据库记录重复。”
个人分析主要原因是因为文字中含有”\“这个符号,因为这个符号我在sql语句中从来没有用到过,哈哈哈
适乎以比较僻的字,结尾,都会出现被莫名的加上一个”\”
例如:在MDB中是”簽名大集錦”,最后生成的SQL则是”簽名大集錦\”
测试结果表明:
在MySQL5.0.24 的环境下.
转换为GBK的出错率会小一些
QUOTE:
环境二:MySQL4.1.21
DZ5(GBK) 转换报告如下:
转换会员数据 失败 61 条，成功率：99.92744487%
转换主题与投票数据 失败 24 条，成功率：99.9350385708%
转换帖子数据 失败 337 条，成功率：99.9420524108%
转换短消息数据 失败 8 条，成功率：99.9873493785%
DZ5(UTF8) 转换报告如下:
转换会员数据 失败 63 条，成功率：99.9250660133%
转换主题与投票数据 失败 24 条，成功率：99.9350385708%
转换帖子数据 失败 337 条，成功率：99.9420524108%
转换短消息数据 失败 8 条，成功率：99.9873146753%
QUOTE:
环境三:MySQL4.0.27
DZ5(GBK) 转换报告如下:
转换会员数据 失败 464 条，成功率：99.4481052406%
DZ5(UTF8) 转换报告如下:
转换会员数据 失败 464 条，成功率：99.4481052406%
4.0.27这个版本,虽然说只有会员数据出错,但是出错率太高了,没有重复的用户名也被识别为重复的用户名了.可以说是根本不正确的.
| Mysql-5.0.24 | Mysql-4.1.21 | Mysql-4.0.27 | ||||
| GBK | UTF-8 | GBK | UTF-8 | GBK | UTF-8 | |
| 转换会员数据失败数 | 61 | 63 | 61 | 63 | 464 | 464 |
| 转换主题与投票数据失败数 | 24 | 24 | 24 | 24 | 0 | 0 |
| 转换帖子数据失败数 | 337 | 337 | 337 | 337 | 0 | 0 |
| 转换短消息数据失败数 | 8 | 8 | 8 | 8 | 0 | 0 |
| 转换后数据大小 | 292.5 | 355.3 | 281.2 | 344.0 | 242.4 | 242.4 |
| 转换后显示出来的结果 | 正常 | 正常 | 正常 | 正常 | 正常 | 乱码 |
其他发现:
GBK转换报告中,有2个提示重复用户名的在UTF-8转换报中没有出现提示.
UTF-8转换报告中,有4个提示重复用户名的在GBK转换报中没有出现提示.
这六个用户名已查证,在MDB数据库中都不是重复的用户名.
由此看出转换程序并完善,再有必要的情况下,最好手动检查一下:报错的数据是否真实.
当然不真实的就自己手动添加上去了,哈哈哈
mysql4.0 + DZ(GBK)是一个最不好的搭配,为什么怎么说捏?看看这副图你就会明白了.
所以为什么会有464个会员名字不能转换了,当然这不是DZ的错,^_^ (具体原因请看十楼)
转换技巧:
1.登陆DV的后台在 上传头像管理 ,上传文件管理 中清理多余的上传文件
2.因为DZ只支持3级分类,转换前先对论坛的4级分类做一些处理,比如说新建一个4级分类的版块出来,移动全部4级分类版块过去,以此类推.(如果DV的程序移动帖子有问题，那么你只能在转换后用DZ来一个一个版块复位了)
3.DZ的主分类,也就是第一分类,不允许有帖子,所以,你要新建一个版块,在该主分类下面,然后后转移帖子到新建的版块下.(如果DV的程序移动帖子有问题，也不要要紧，帖子都还是真实存在于mysql中的，想办法把它移动出来就可以了.)
不管你是合并,还是移动,还是新建版块的方式.总之就是想尽一切办法在还没有转换之前,就把论坛调整成 一级分类没有帖子,不存在四级版块.
4.转换程序中的$discuz_charset = 'gbk'; 这个值,最好不要修改,保持为gbk,不然会遇到N多的错误和乱码.
最终我使用的转换方法如下:
1.用mysql4.0 ,新建一个空DZ5(GBK)论坛bb1
2.在bbs1,转好一个全部数据,登陆后台备份(全部数据,建表语句格式MySQL 4.1.x/5.x)得到数据A.
3.用mysql5.0 ,新建一个空DZ5(GBK)论坛bb2
4.在bbs2的后台,导入数据A
5.在bbs2中再次使用转换程序,只转换会员数据,这样就做好一个DZ5 (GBK,Mysql5.0)的转换了.
6.最后在转换结果报表中添加一些你认为不是非法用户名的用户(如果你使用GBK的话,到此就可以结束了)
7.将bbs2备份,强制utf8,这样就生成了数据C
8.用mysql5.0 ,新建一个空DZ5(UTF-8)论坛bb3
9.将刚刚备份好的数据C导入bb3. 最终得到一个错误率最低的 DZ5 (UTF-8,Mysql5.0)
我修改的转换程序
我自己对转换程序进行的修改,更加人性化一些.
动网DvBBS 7.x Access to Discuz!5.0.0 转换程序 v1.3.3_特别版本.zip
(2006-09-07 12:48:56, Size: 25 KB, Downloads: 242)
对现有转换程序的意见:
report.htm这一个显示的结果太多,如果错误率比较高的话,那这个文件就太大了,在IE显示报告都会比较慢
可以考虑分页显示report_01.htm,report_02.htm,report_03.htm,report_04.htm………
dvbbs这文件夹应该写成变量.这样可以给用户更好的DIY比如叫oldbbs,bbs01什么的.
呵呵,因为我不想让别人知道我以前用过什么论坛程序.
9月07更新的代码是这个，官方可以see一下，我的坛子转好以后发现 DV的威望变成金钱，金钱变成威望了。
如果已经转好的朋友可以用phpmyadmin改字段名就解决了。
CODE:
$extcredits4 = $user['userep']; //经验值
$extcredits1 = $user['userpower']; //威望
$extcredits2 = $user['userwealth']; //金钱
$extcredits3 = $user['usercp']; //魅力偷懒,我自己就不写,留给DZ的开发人员搞定吧,哈哈哈哈[ 本帖最后由 spzgy 于 2006-9-7 12:55 编辑 ]
最新回复
有谁知道为什么4.0转用户名的时候出错率那么高,而且出错的地方都不正确,都不应该出错的.
QUOTE:
事实证明了你说的话,我在mysql4.0,死活都搞不定.不过好像DZ自带的备份数据库功能能解决 5.0/4.1和4.0 GBK和UTF-8之间的转换.不知道会不会存在出错率的问题,
导入导出都没有什么报告生成,看起来万事大吉的样子,哈哈哈
--------------------------------------------------------------------------------
本转换程序基于 DvBBS 7.x Access 标准数据结构设计
--------------------------------------------------------------------------------
当前操作第 3 / 9 步 => 转换主题与投票数据
正在处理第 1 —— 3000 行数据......
[中止操作并返回程序首页]
清空数据表 cdb_polloptions 出错
Error 1146 : Table 'discuz.cdb_polloptions' doesn't exist.
错误 1146：数据表不存在。
请根据以上提示信息进行调整，然后刷新本程序继续进行转换！
我遇到一个很郁闷的问题
mysql 4.0 搜索用户表名为nono的用户:
SELECT *
FROM `bbs_members`
WHERE `username` = 'nono'
LIMIT 0 , 30
结果,给我列出了"洋洋"
我真是晕倒,差太远了吧,这就是mysql 4.0转换用户名出错 464 条那么多的原因....
哪位朋友可以解释一下.
在 latin1 字符集中 nono 和 洋洋 编码是一样的，类似的例子还很多，比如 六库 和 名酷
所以，现在的 mysql 支持多字符集，不会出现这种问题
1.请问你的如何转换大体步骤和思路是怎么样的。我这篇文章只是提供你一些思路和统计数据以及我使用的转换方法。
2.你是否有读完我全文。你可以看出来MySQL4.0的环境下面，是不能直接dvbbs-ac7-GBK转DISCUZ-UTF8的，那样会乱码。