再次求助，转换完毕后旧会员无法登陆

用下载的uc_client覆盖了 而且转换的时候确实是用8.0AC-7.0UC的那个子体的

我以为是加密后密码是16位和32位的区别 但查了下数据库 发现转换后的密码竟然都是32位的 是不是在转换数据库的时候自动加密到32位的？但动网加密到16位的时候是丢了其中16位的啊，用什么方法能算出对应的32位哦？

可能发现原因了，由于在本地转换的数据 不知道为什么无法导出备份文件，所以转换玩以后我又手动把本地数据库里的数据导出SQL语言后导入到服务器的数据库中，因为整个库太大，所以我是分表导的，可能有个别关键的表没有导过去，导致了这个问题。不过DZ的MEMBER表和UC的MEMBER表都导过去了，而MD5用到的SALT是在UC里面吧？

在用8.0AC-7.0UC子体转的时候，用户密码转为DZ格式的方法是不是 “新的密码”= md5(md5(AC数据库中的旧密码).$ucsalt)，还是说有其他算法？如果是这样转的话，我验证了一下，在数据库中生成的新密码和我自己用$ucfounderpw = md5(md5($ucfounderpw).$ucsalt) 函数生成的密码是不一样的，$ucsalt部分是用对应用户数据中的ucsalt值

找到原因了，之所以怎么弄都不行，是因为在转换的时候 读取原DV数据库用户密码时只读了第一位，然后对这第一位密码进行了MD5加密到32位的。
但是，还是没找到为什么会只读第一位的原因

转换子体的相应部分本来是这样的
$ucpw        =convertucpw($user['userpassword'])
输出的就是转换过的32位了
后来我为了弄明白为什么转换后的密码会使得旧用户不能登陆就把它改为
$ucpw        =$user['userpassword']
结果输出的用户密码竟然只有原来16位密码的第一位字符

也就是说$ucpw        =convertucpw($user['userpassword'])中的$user['userpassword']其实也是只有1位字符的，所以转换输出的32位是不正确的

但到底是什么原因导致$user['userpassword']只有一位 我完全弄不明白，因为$user['userpassword']应该是直接引用数据的，既然$user['username’]是正确完整的，那$user['userpassword']也应该没有问题才对啊

怎么没人理了？哭.....
我后来把USER.PHP改了下 使到它也只读取原来的密码的第一位进行加密，然后验证，可还是不行啊

重新转换一下试试

试过好多遍了，都快疯了，不过慢慢还是有些进展的
现在问题卡在一个地方了，因为我转换过来的时候只能读到1位密码进行加密，所以我把用来覆盖的两个USER.PHP中

1. elseif($user['password'] != md5($passwordmd5.$user['salt']) && $user['password'] != md5(substr(md5($password),8,16).$user['salt']))

复制代码

和

1. if($user['password'] == md5(substr(md5($password),8,16).$user['salt']))

复制代码

都改为了

1. elseif($user['password'] != md5($passwordmd5.$user['salt']) && $user['password'] != md5(substr(md5($password),8,1).$user['salt']))

复制代码

和

1. if($user['password'] == md5(substr(md5($password),8,1).$user['salt']))

复制代码

，但登陆还是失败。
我自己写了个显示编码结果的小程序

1. <?php
   
2. $ucfounderpw = '密码';//密码处填入要输入的密码
   
3. $ucsalt = 'ucsalt';//ucsalt处改为数据库中对应用户的ucsalt
   
4. $ucfounderpw = md5(substr(md5($ucfounderpw),8,1).$ucsalt);
   
5. echo $ucfounderpw.'<br />'.$ucsalt;
   
6. ?>

复制代码

得出的结果跟数据库中存的密码是一样的，但是登陆依然失败，彻底崩溃了