这样的情况是可以直接拷贝数据文件的至于如果原来用的latin1现在mysql4.1中还想继续“错误的使用latin1那么只需把default-character-set设置为latin1并且在论坛中更改连接方式即可。mysql转换或者升级以后出现乱码情况的说明 ，出现这种现象的主要原因是这类用户使用的都是mysql4.1以上的版本.下面作一个说明,看到不少用户反映转换完以后是乱码的情况.希望出现这个问题的朋友都能耐心的把这个文档看完!!!
原理 ：之前的mysql版本，注意：本文档只对mysql4.1及以上的数据库版本有效。由于没有提供对字符集的完整支持，因此也不存在此类问题。对多语言的支持有了很大变化 这导致了问题的呈现)尽管大部分的地方 包括个人使用和主机提供商)mysql34.0仍然占主导地位；但 mysql4.1mysql官方推荐的数据库，mysql4.1开始。已经有主机提供商开始提供并将会越来越多；因为 latin1许多地方 下边会详细描述具体是哪些地方)作为默认的字符集，胜利的蒙蔽了许多 php顺序的开发者和用户，掩盖了中文等语言环境下会出现的问题。
其中的一张表，mysql4.1对于字符集的指定可以细化到一台机器上安装的mysql其中的一个数据库。其中的一栏，应该用什么字符集。但是保守的web顺序在创建数据库和数据表时并没有使用那么复杂的配置，用的默认的配置，那么，默认的配置从何而来呢？指定了一个默认的字符集，编译 mysql时。这个字符集是latin1，可以在配置文件 my.ini中指定一个默认的字符集，装置 mysql时。如果没指定，这个值继承自编译时指定的可以在命令行参数中指定一个默认的字符集，启动 mysqld时。如果没指定，这个值继承自配置文件中的，此时 character_set_serv被设定为这个默认的字符集；除非明确指定，当创建一个新的数据库时。这个数据库的字符集被缺省设定为 character_set_serv，character_set_databas被设定为这个数据库默认的字符集；当选定了一个数据库时，表默认的字符集被设定为 character_set_databas也就是这个数据库默认的字符集；这个数据库里创建一张表时。除非明确指定，当在表内设置一栏时。否则此栏缺省的字符集就是表默认的字符集；mysqldump进去的内容就是这个字符集下的这个字符集就是数据库中实际存储数据采用的字符集。
最方便的所有queri开始之前执行一下：想要进行“正确”存储和得到正确”结果。
setname'gbk';
其中gbk数据库字符集。
罕见问题解决方案
但phpmyadmin中中文为乱码 数据使用latin1或其他编码存储中文信息，phpmyadmin无法识别的对于简体中文，这问题是由于新版本的phpmyadmin都是强制使用正确的字符集进行数据库连接和显示的因此如果存储内码和实际内码不一致。phpmyadmin可识别gbk/utf8繁体中文，可识别big5/utf8如果你确定想使用这种“不正确”字符集（事实上通常在mysql4.1之前大家都是用“不正确”字符集存储数据的存储中文论坛数据，那么请使用phpmyadmin2.5.x老版本，会使用最老和最普通的方式连接数据库，这样便可以正常管理。
但升级到正式版后就有了乱码 论坛原来使用discuz!4.0.0rc版本+mysql4.1没有问题，您的情况和上面的情况差不多。rc版本使用“最老和最普通的方式”连接数据库，浏览这问题前请您先看一下上一个问题的解答。因此你如果使用“不正确”字符集存储，事实上是没有问题的但discuz!4.0.0正式版使用了与phpmyadmin新版本相同的正确”数据库字符集，因此导致原来“不正确”存储和“正确”连接发生抵触，进而发生乱码。
有如下两种方案：解决此类问题。
更改存储字符集，或者utf8;以下操作必需拥有主机权限。假设当前操作的数据库名为：databas主要的思想就是把数据库的字符集有latin1改为gbkbig5.
导出 ：具体的命令如下：mysqldump-uroot-p--default-character-set=latin1--set-charset=gbk--skip-optdatabs>test.sql首先需要把数据导为mysql4.0格式，这个一般情况下都是latin1--default-characte-set以前数据库的字符集；这个可以设置为gbkutf8,--set-charset导出的数据的字符集。或者big5
导入：首先使用下面语句新建一个gbk字符集的数据库testcreatdatabas`test`defaultcharactsetgbkcollatgbk_chinese_ci;然后把刚才导出的数据导入到当前的数据库中就ok，mysql-uroot-p--default-character-set=gbk-ftest
通过以上的导出和导入就把数据库的字符集改为正确的存储方式了，但相对以后则一直都是使用mysql正确”方式进行存储和数据连接，总结：这种方案比较麻烦。并且新版本phpmyadmin不会乱码。
更改连接方式
discuz!4.0.0
您可以找到./include/db_mysql.class.php将 对于discuz!4.0.0正式版。
'',mysql_queri"setname'".str_replac'-'.$globals['charset']."'";
前面加上“//即将其注释掉
discuz!4.0.0+
已经支持在config.inc.php中使用单独的$dbcharset来设定数据库字符集，对于discuz!4.0.0以后的版本。因此可根据您的实际情况选择留空（与$charset设置相同）或指定为特定的数据库字符集，但显示和使用能够正常，总结：折衷方案。数据使用“不正确”内码存储。phpmyadmin新版本乱码，老版本可用。备份和恢复时候需要特别注意字符集问题。应当如何升级mysql4.0数据到mysql4.1+中，那么将mysql4.0数据文件，直接拷贝到mysql4.1中就是不可以的即便在my.ini中设置了default-character-set为正确的字符集。虽然貌似没有问题，但mysql4.1字符集有一处非常恼人的地方，以gbk为例，原本mysql4.0数据中varchar,如果数据文件中有中文信息。char等长度都会变为原来的一半，这样存储中文容量不变，而英文的存储容量就少了一半。这是直接拷贝数据文件带来的最大问题，升级的根本，所以如果想使用“正确”字符集，还是先用mysqldump导出成文件，然后导入。