[原创]本人数据库转换经验.

我敢说我的文字绝对是启智有效的.
你们要转帖嘛,一定要附上我的朋友hun的网址,千万别盗版权啊.谢谢.笑.
本人经验丰富.愿意帮你的忙.并写出长长的感言.欢迎联系我.

大略的参考一下这个https://discuz.dismall.com/thread-650767-1-1.html,再来看本文.

[ 本帖最后由 tiancheng 于 2007-6-19 14:52 编辑 ]

首先谈谈我遇到的问题:

相同论坛+数据库的乱码问题. 急求解决方案!
我遇到的问题:西安主机和江苏主机装的是一模一样的论坛,但是西安主机运行完好,江苏主机全是乱码.

西安主机环境是:
*
windows2003+php 4.3.11+mysql 5.0.41+discuz4.0  
说明:
mysql 5.0.41 运行时打勾了Enable Strict Mode.和Standard Character Set(Makes Latin1 the default charse)
用phpMyAdmin-2.8.2.4 查看是:
mysql charset=utf8-unicode,mysql collation=utf8_general_ci
Discuz的版本是4.0 GBK版本.
disucuz config.inc.php 里headercharset = 0;        $charset = 'gb2312';(此为重点!)
西安的表是全部是latin1_swedish_ci.




**江苏主机环境是是:
(?)+php 5.0+mysql5.0.16+discuz4.0(当然是这个,一样的,数据库都和上面一样)
说明:
mysql 5.0.16运行时情况未知.
用phpMyAdmin-2.8.2.4 查看是:
MySQL charset: UTF-8 Unicode (utf8) ;mysql collation=utf8_general_ci 和上面一样的.
Discuz的版本是4.0 GBK版本(这个就废话了.都说了一样的又重复,真是抱歉).disucuz config.inc.php 里的$headercharset = 0;        $charset = '内容填写在后有说明';(此无论怎么填写都是乱码!)

江苏的表是有些是latin1_swedish_ci. 有些是gb2312_bin.

[ 本帖最后由 tiancheng 于 2007-6-15 23:30 编辑 ]

占位.


西安主机的dz4.0一切都完好.浏览,发帖正常.备份数据,恢复数据,反反复复一万次一千次都没有问题.
江苏主机的dz4.0就是内容乱码而已.其标题栏文字比如"控制面板"都是正常文字.把西安主机的备份给江苏主机恢复的话,江苏的还是乱码.
奇怪.

我说的信息够详细了.我该怎么解决?



问题A(就是如上说的问题)暂时解决了.

问题B(在线会员中文名字乱码,其它方面没有故障.)仍然发生.截至07.6.14,已经自行解决.
所以:
我总结的经验,包含有一些看法(不一定要多么专业,毛主席说的"厚积薄发"在这里不生效,因为我关心的是你们新手):
1 , discuz的 "强制设置字符集,只乱码时... ..." 是垃圾功能.一般用不到的.
    config.inc.php 里的$headercharset = 0;别说一般人,就所有的人在几乎所有的情况下都不会感兴趣的.因为它能产生效力的地方仅仅是标标题栏文字而已!而这个地方就有用了,尤其对主机环境是mysql4.1.x或mysql5.x的朋友:
$charset = '****';        论坛默认字符集, 可选 'gbk', 'big5', 'utf-8'. 其实****还可以填写 gb2312. 或变为空.
这个例子就是改为gb2312解决的.

[ 本帖最后由 tiancheng 于 2007-6-15 23:31 编辑 ]

2 第一次装论坛时要把论坛当作自己的女人一样.切莫为了以下愚蠢的意图而顾此失彼(在未来的大环境下!就像法国大革命那样的环境.要知道以后的日子mysql4.0不会有好日子过了.大部分的主机将会是mysql5.x以上的天下,所谓未雨绸缪啊,朋友们.比如仅限目前情况的MySQL charsetUTF-8 Unicode+MySQL connection collation utf8_unicode_ci.不要再说中华的语言文字多么多么优秀.世界大环境初始mysql5.x的时候都是以拉丁文字latin1为默认,人家大部分主机的my.ini最高级别的字符集定义collocation就是latin1_swedish_ci. 我们的专业编程者们也应该抛弃旧有的mysql引用,连接了吧?).

以下是谈到的愚蠢意图.
  *贪图所谓的"gbk版数据库体积小..."
  **贪图所谓的"gbk版更新rss没有乱码..."
  ***贪图所谓的"gbk版更不像utf-8版本容易出现乱码..."

其实啊什么玩!utf-8才是大势所趋,或者说是被"大势"所趋.大势以上提到了.

[ 本帖最后由 tiancheng 于 2007-6-15 23:32 编辑 ]

这回谈经验:
1 第一次装论坛时,最好要确保你的主机环境是mysql4.1.x或以上版本.因为这个是趋势.这样做了你以后就会少遇到乱码情况.乱码问题一般人是没有什么耐心去弄的.
若你一开始就  mysql4.0,那么就一直在这样的环境下用论坛.除非你不怕数据库毁灭然后为了恢复数据出1000左右人民币,给官方作为手续费.

2 和官方反调: 开始使用论坛的时候绝对的推荐用dz utf-8版本!
  以后也要延续下去.不要换.
  这个错不了.否则出了猴儿急的情况你别来诉苦.(另无关的题外题: 后台显示的备份数据版本和mysql版本是两码事.别混淆.sviq.com的hun提醒过我)
  其实discuz gbk和discuz utf-8只有一个文件不同 就是cinfig.inc.php.也可以说仅仅是各自里面的$charset不同.

3 换主机意味着换环境,你新配置了主机的话也意味着换了环境,切忌:
   *要以"常规备份"模式备份数据.
    **删除插件,删除一切潜力破坏默认模板的东西.这个切记!原因?就是数据表导入时避免出错. 我担保你们很容易出错,要是不遵守这条的话.

[ 本帖最后由 tiancheng 于 2007-6-15 23:32 编辑 ]

4 $charset = '*';的星号处留空试试或者改为gb2312,gb18030试一试.你会有稍许改观.
   但是星号改为不能使你的浏览器正常显示论坛的时候,就危险了.这时候的危险是:
   *你的会员发了帖子,帖子将会是乱码,即便是星号改回到正常(能使你的浏览器正常浏览叫正常),也不能挽回那帖子的正常.
    这个地方不是能随意改的.这个原因可能就在mysql的连接上.
   **禁止会员发帖子或者另一个管理员这时候(星号改为不正常期间)修改后台.
   ***最好的方式是看http://kb.discuz.com/index.php?t ... 7.E7.AC.A6.E9.9B.86
      因为之前的两个方法是不稳妥的,是游离于官方论坛潜在支持之外的.毕竟让论坛不用改charset也能工作是多么的"可靠".对不对?这个方法生效后,往往会有底部管理员版主说明成乱码的现象,怎么办?后台反复确定一下就好.可能是缓存问题.
      以上这个网址说明不够透彻,我来完善做法吧.
看:
主要的思想就是把数据库的字符集有latin1改为gbk，big5,或者utf8; 以下操作必须拥有主机权限。假设当前操作的数据库名为：fuuck
[编辑]导出
首先需要把数据导为mysql4.0/5.0的格式，具体的命令如下：
cmd
..mysql/bin>
mysqldump -uroot -p --default-character-set=latin1 --set-charset=gbk --skip-opt fuuck > test.sql

[--default-characte-set 以前数据库的字符集，这个一般情况下都是latin1的，
--set-charset 导出的数据的字符集，这个可以设置为gbk，utf8,或者big5 ]

[编辑]导入
首先使用下面语句新建一个GBK字符集的数据库（test）
删除mysql data的test(务必!)
mysql(务必,这个废话了)
CREATE DATABASE `test` DEFAULT CHARACTER SET gbk COLLATE gbk_chinese_ci;
然后把刚才导出的数据导入到当前的数据库中就ok了。
ctrl+c 退回...bin
mysql -uroot -p --default-character-set=gbk -f test<test.sql
再把test里的数据放到你的目标文件夹.
通过以上的导出和导入就把数据库的字符集改为正确的存储方式了。

总结：这种方案比较麻烦，但相对以后则一直都是使用MySQL“正确”的方式进行存储和数据连接(官方论坛指导文件云云)......

PS Warning: Invalid argument supplied for foreach() in **\viewthread.php on line 149 反复两次启停设置积分就好了



PS.要以怀疑的眼光看待的帖子主题是(也就是没有必要去照作以及他们的办法根本没有完全解决问题):
https://discuz.dismall.com/thread-313395-1-1.html
穆亦风 (陈书艺,还是dz administrator呢) 的帖子部分是放屁:
https://discuz.dismall.com/viewth ... E0%B7%E7&page=1
你们看

A导出4.1/5.0的库
B进行处理，转换成gbk字符集
C彻底卸载4.1或者5.0
D安装4.0.26
E然后导入处理完的库

你们看:我们就是为了在mysql4.1.x环境下用dz的,他还说什么降到4.0(D安装4.0.26)?真是服了他!


5 以下方法解决问题B(在线会员中文名字乱码,其它方面没有故障).注意,这里涉及的环境是mysql5.0的之下.mysql4.0之下的问题不谈.
  *utf8可以改为gbk试一试.期间可不能有人发帖子,修改后台.


(dz 4.0)后台升级数据库:

DROP TABLE IF EXISTS cdb_sessions;
CREATE TABLE cdb_sessions (
  sid char(6) binary NOT NULL default '',
  ip1 tinyint(3) unsigned NOT NULL default '0',
  ip2 tinyint(3) unsigned NOT NULL default '0',
  ip3 tinyint(3) unsigned NOT NULL default '0',
  ip4 tinyint(3) unsigned NOT NULL default '0',
  uid mediumint(8) unsigned NOT NULL default '0',
  username char(15) NOT NULL default '',
  groupid smallint(6) unsigned NOT NULL default '0',
  styleid smallint(6) unsigned NOT NULL default '0',
  invisible tinyint(1) NOT NULL default '0',
  `action` tinyint(1) unsigned NOT NULL default '0',
  lastactivity int(10) unsigned NOT NULL default '0',
  lastolupdate int(10) unsigned NOT NULL default '0',
  pageviews smallint(6) unsigned NOT NULL default '0',
  seccode smallint(6) unsigned NOT NULL default '0',
  fid smallint(6) unsigned NOT NULL default '0',
  tid mediumint(8) unsigned NOT NULL default '0',
  bloguid mediumint(8) unsigned NOT NULL default '0',
  UNIQUE KEY sid (sid),
  KEY uid (uid),
  KEY bloguid (bloguid)
) DEFAULT CHARSET=utf8 TYPE=HEAP;



思想总结:

MySQL 4.1/5.0 对于字符集的指定可以细化到一台机器上安装的 MySQL，其中的一个数据库，其中的一张表，其中的一栏，应该用什么字符集。
但是，传统的 Web 程序(比如dz4.0RC ,DZ2.0)在创建数据库和数据表时并没有使用那么复杂的配置，它们用的是默认的配置，那么，默认的配置从何而来呢？

编译 MySQL 时(可以理解为主机装mysql时)，指定了一个默认的字符集A，这个字符集是 latin1；
安装 MySQL 时，可以在配置文件 (my.ini) 中指定一个默认的的字符集B，如果没指定，这个值继承自编译时指定的；B如果不在my.ini指定,就有 B=A;
启动 mysqld 时，可以在命令行参数中指定一个默认的的字符集C，如果没指定，这个值继承自配置文件中的； C若没有指定,C=B;
此时 character_set_server(D) 被设定为这个默认的字符集； D强制等于C;
当创建一个新的数据库时，除非明确指定，这个数据库的字符集E被缺省设定为 character_set_server(D)； E没有指定那么E=D;
当选定了一个数据库时，character_set_database(F) 被设定为这个数据库默认的字符集(G)；F=G;
在这个数据库里创建一张表时，表默认的字符集H被设定为 character_set_database(F)，也就是这个数据库默认的字符集； H=F;
当在表内设置一栏时，该栏字符集是I, 除非明确指定，否则此栏缺省的字符集就是表默认的字符集H； 若不明确指定,I=H
这个字符集(I)就是数据库中实际存储数据采用的字符集(I)，mysqldump 出来的内容就是这个字符集下的；



I不一定等于H,(H=F=G=character_set_database),E不一定等于D(D=character_set_server=C),C不一定等于B,B不一定等于A.
进而看,装mysql时的指定集为A,my.ini集为B;

这下mysql就招骂了:
my.ini某人控制不到,加上旧dz程序等,就有我们mysqldump导出的集是latin1.

[ 本帖最后由 tiancheng 于 2007-6-16 00:30 编辑 ]

不知道怎么换的，现在换空间了，就是没办法的。

不知道怎么换的，现在换空间了，就是没办法的。