A机器上mysql的字符集设为gb2312,那么你通过mysqldump备份的sql文件,里面包含了建表的SQL,你可以用文本编辑器打开看一下,里面的中文有没有乱码,同时你可以每个建表语句后都会有一句:default-character-set=gb2312吧,所以你在B机器上进行恢复的时候,就相当于执行了一句
set names=gb2312,但是B机器上默认的字符集是utf8,查看当然会出现乱码,如果你查看之前执行一句set names=gb2312再来查看,看看能不能正确显示?"提示说字符集是invalid"则说明,你用的MySQL的版本应该是4.1以前的,4.1以前的版本并没有将字符集细分,也没有gb2312和gbk这样的字符集.你可以用:show charset;来查看一下你mysql支持的字符集.试试这样做,备份mysqldump -uroot -p db --default-character-set=utf-8 > $path,然后再做恢复.如果你temp数据库里的表类型全部都是myisam类型的话,就可以直接复制到B机器mysql的data目录,再重启mysql服务就可以了.但是照上面做的话,你jsp页面的字符集也应该相应的改成utf-8编码才能正确显示.

解决方案 »

  1.   

    备份出来的sql文件 打开来看 里面的中文显示正常 在建表最后也有 ENGINE=MyISAM DEFAULT CHARSET=gb2312 的语句 但如果直接导进去 中文就是会显示为? 我的jsp页面也是utf8的 这样导进去后 并不影响页面上的使用 就是数据库中文都显示为? 影响了数据库的管理
    show charset后 没有gbk这个字符集 但是有gb2312 我的数据库版本是5.1.20的 之前服务器上有4.1.18的版本 当初用那个版本时 直接导入数据后数据库显示正常 只是页面有乱码 我就直接修改了my.cnf文件 在[mysqld]中添加了 character-set-client=gbk character-set-server=gbk  然后重启mysql 并重建数据库 之后页面显示就正常 但由于备份出来的sql脚本中有个字段bit在4.1.18中是没有的 而这个字段又很重要 所以就把4.1.18的版本删除了 安装了5.0.20这个版本 现在就是导入脚本后 中文显示就为?  在my.cnf文件中添加gbk或gb2312的字符集就启动不了mysql 添加utf8的就没问题  由于我这个项目数据库的表结构可以通过hibernate自动生成 后来就先产生表后导入数据  导入后数据库显示正常 但是页面有乱码 没法修改my.cnf 问题也就没法解决了
    我的数据导入是通过source实现的 用mysqldump会提示找不到脚本文件 估计是脚本放错地方了 
    现在最头疼的就是不能在my.cnf中添加gbk或gb2312字符集 查了资料说是由于/usr/bin下有别的mysq存在 但又不知道怎么去掉才不会影响
      

  2.   

    show charset后 有gb2312 在my.cnf中指定字符集为gb2312  mysql也可以启动了 如果先创建表后 再单独导入数据会有很多warning 如果直接导入数据整个数据库脚本 那么数据库中的中文还是乱码 还有在导入后会提示
    OLD_CHARACTER_SET_CLIENT=@@CHARACTER_SET_CLIENT 
    这边字符集为null  请问这边要如何添加 数据库里的表类型全部都是myisam类型 我直接复制脚本到mysql的data目录下  重启mysql  但数据并没有导入数据库