MySQL数据库中数据库移植中的乱码问题[MySQL防范]

MySQL移植含有中文的数据时,很简单呈现乱码问题.很多是在从MySQL4.x向MySQL5.x移植的时刻呈现.MySQL的缺省字符集是latin1,在利用MySQL4.x的时刻,很多人都是用的latin1字符集.而当利用MySQL5时常常乐意利用UTF-8.那么我们的任务是不是要把数据中的字符从latin1转为UTF-8呢?不是的.

用一句不大精确,但又对比形象的说法是,在之前的系统中,我们是用latin1保存了利用GB系列字符集（GBK、GB2312等）的汉字.怎么这样说呢?

mysql> show create table test\G
*************************** 1. row 
Table: test
Create Table: CREATE TABLE `test` (
`a` varchar(100) default NULL
) ENGINE=InnoDB DEFAULT CHARSET=utf8
1 row in set (0.00 sec)

mysql> show create table testlatin1\G
*************************** 1. row *
Table: testlatin1
Create Table: CREATE TABLE `testlatin1` (
`a` varchar(100) default NULL
) ENGINE=InnoDB DEFAULT CHARSET=latin1
1 row in set (0.01 sec)

字符集是奉告我们,假如没有分外指定列的字符集,那么字符范例列的字符集与表的缺省字符集一样.

列的字符集是要奉告MySQL,这里面保存的字符所利用的字符集是什么.但到底保存的是什么字符集的字符,不由MySQL决意,MySQL也不举行查抄.

在UTF-8遍及利用之前,我们利用的汉字都是GB系列的字符集,比方GB2312、GBK、GB18030等等.

在缺省字符集为latin1的MySQL中,我们普通就把GB字符集的汉字保存到数据库中,但是却奉告MySQL那是latin1字符集.而GB字符集是一个汉字占两个字节,latin1是一个字符占一个字节.也就是说一个GB汉字被当作两个latin1字符来保存了.这让我想起了当初的iso8859_1,也是近似的情形.只要我们保存和读取时都当作latin1,不举行转换,然后在显示时当作GB字符集,就可以够精确利用.

那么怎么把latin1保存的汉字精确地导UTF-8字符集的数据库中呢?

首先,新的数据库中的列,要利用UTF-8字符集.一种办法是成立database时指定缺省字符集,这样在建表时假如不指定字符集则利用database的缺省字符集.

导出的数据要以latin1字符集导出,实际上就是奉告MySQL导出时不做转换（因为原有的表都是latin1字符集的）.

mysqldump出来今后,再用MySQL举行导入时,还要奉告MySQL,当前的数据是gb系列的字符集,比方gbk.这样,MySQL负责把数据由gbk转换为UTF-8,保存到数据库中.

若何奉告MySQL导入的SQL是什么字符集呢,一种办法是用--default-character-set,但有时会起不到实际作用.这是因为mysqldump出来的文件里有set names语句.比方:

head EA192.060913.sql 

-- MySQL dump 10.10
--
-- Host: localhost Database: EA192
-- ----------------------------------
-- Server version 5.0.16-standard-log

/*!40101 SET @OLD_CHARACTER_SET_CLIENT
=@@CHARACTER_SET_CLIENT */;
/*!40101 SET @OLD_CHARACTER_SET_RESULTS
=@@CHARACTER_SET_RESULTS */;
/*!40101 SET @OLD_COLLATION_CONNECTION
=@@COLLATION_CONNECTION */;
/*!40101 SET NAMES latin1 */;

/*! */是MySQL特有有句法,在其他数据库会被当作注释忽视掉./*!背面的40101是表示版本,在4.1.1及以上版才履行该条语句.

这里看到有一条SET NAMES latin1.它的一个作用是奉告mysql,客户端传过去的数据是latin1字符集.因为有这样一条SET NAMES,--default-character-set也就起不到作用了.假如不幸有这样一条SQL,那么需求把它去掉大概改成SET NAMES gbk.改正大概删除的办法,当数据量对比大的时刻,可以用head和tail来配合.比方还是上面的那个文件:

先用head看一下SET NAMES在第几行（数一下）,上面看到是第10行.

wc -l EA192.060913.sql 
1987 EA192.060913.sql
得到总行数是1987

head -9 EA192.060913.sql > final.sql
brum@brum-laptop:~$ tail -1977 EA192.060913.sql
 >> final.sql 
brum@brum-laptop:~$

head -9是取前9行,tail -1977是取后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语句,因为此中也大概会有缺省字符集的子句,会影响那些未在CREATE TABLE中指定字符集的表.假如你导出的SQL中有CREATE DATABASE,那么需求注意一下有没有字符集的子句,假若有的话,也需求改正.

好了,通过上述办法导出大概处理过的导出文件可以利用mysql --default-character-set=gbk来导入了.