MySQL数据移植中的乱码问题(二)

2015-07-24 10:43:22 · 作者: · 浏览: 8
7是取后1977行,这样就把第10行隔过去了。

?

得到final.sql再用MySQL运行时,就可以使用--default-character-set=gbk了。

?

还有一种办法是mysqldump时使用--set-charset=false,这样就不会出现SET NAMES了。

?

目前为止,还可能有问题,出在create table的SQL中,比如:

DROP TABLE IF EXISTS `test`;

CREATE TABLE `test` (

`a` varchar(100) default NULL

) ENGINE=InnoDB DEFAULT CHARSET=latin1;

这里仍然有个CHARSET=latin1,它将导致新创建的表的缺省字符集是latin1,而不是我们想要的UTF8。

怎么办呢,如果数据量不大的话,可以考虑用编辑器把它去掉或者改成UTF8,如果数据量大的话可以考虑用sed,但可能仍然时间比较长。

还有一种办法就是mysqldump,使用--create-options=false,不导出表的创建属性。但如果导出的表的存储引擎不同的话就有问题了,因为引擎类型(innodb、myisam等)都被忽略了。

此外,mysqldump导出时,不要使用-B,而是直接指定一个database名字,目的是不出现CREATE DATABASE语句,因为其中也可能会有缺省字符集的子句,会影响那些未在CREATETABLE中指定字符集的表。如果你导出的SQL中有CREATEDATABASE,那么需要注意一下有没有字符集的子句,如果有的话,也需要修改。

好了,通过上述方法导出或者处理过的导出文件可以使用mysql--default-character-set=gbk来导入了。