MySQL数据库中数据库移植中的乱码问题
时间：2008-04-01 来源：剑心通明
mysql移植含有中文的数据时，很容易出现乱码问题。很多是在从mysql4.x向mysql5.x移植的时候出现。mysql的缺省字符集是latin1，在使用mysql4.x的时候，很多人都是用的latin1字符集。而当使用mysql5时往往愿意使用utf8。那么我们的任务是不是要把数据中的字符从latin1转为utf8呢？ m)?p3
不是的。 J9X4q+
用一句不大准确，但又比较形象的说法是，在之前的系统中，我们是用latin1保存了使用gb系列字符集（gbk、gb2312等）的汉字。怎么这样说呢？ -UupUXO5
G;w^]F"91
mysql> show create table test\G P Xd/yb)
*************************** 1. row *************************** yA!_V^~
Table: test "hKSc}AH
Create Table: CREATE TABLE `test` ( &"nL!ct^L
`a` varchar(100) default NULL b;it Mv
) ENGINE=InnoDB DEFAULT CHARSET=utf8 1*Y{a0[s
1 row in set (0.00 sec) {RI1y?>>
^`;^1K.2
mysql> show create table testlatin1\G ouo^Y9
*************************** 1. row *************************** ^$:o
Table: testlatin1 |A<wk5
Create Table: CREATE TABLE `testlatin1` ( ]&*w\i7YU
`a` varchar(100) default NULL wZrF{Qc$
) ENGINE=InnoDB DEFAULT CHARSET=latin1 !~C*W/ D3I
1 row in set (0.01 sec) t/[ihd *U@
I79xX1p>
我们看到这两个表有不同的缺省字符集。此字符集是告诉我们，如果没有特别指定列的字符集，那么字符类型列的字符集与表的缺省字符集一样。 lL(K-&Oc,*
T"`~8 wi
列的字符集是要告诉mysql，这里面保存的字符所使用的字符集是什么。但到底保存的是什么字符集的字符，不由mysql决定，mysql也不进行检查。 p)5o=:Qn
ud{eg
在utf8广泛使用之前，我们使用的汉字都是GB系列的字符集，比如GB2312、GBK、GB18030等等。 5 R60Fn
"PIyL{ F:
在缺省字符集为latin1的mysql中，我们通常就把GB字符集的汉字保存到数据库中，但是却告诉mysql那是latin1字符集。而GB字符集是一个汉字占两个字节，latin1是一个字符占一个字节。也就是说一个GB汉字被当成两个latin1字符来保存了。这让我想起了当初的iso8859_1，也是类似的情况。只要我们保存和读取时都当作latin1，不进行转换，然后在显示时当作gb字符集，就能够正确使用。 k,'j9Y4
|r&:o?%B
那么怎么把latin1保存的汉字正确地导到utf8字符集的数据库中呢？ z ~1y brW
U:A-0
首先，新的数据库中的列，要使用utf8字符集。一种办法是创建database时指定缺省字符集，这样在建表时如果不指定字符集则使用database的缺省字符集。 I[^H*<}#\X
s9M@uSF_
导出的数据要以latin1字符集导出，实际上就是告诉mysql导出时不做转换（因为原有的表都是latin1字符集的）。 P*Hj'^&
q{S0kT*
mysqldump出来以后，再用mysql进行导入时，还要告诉mysql，当前的数据是gb系列的字符集，比如gbk。这样，mysql负责把数据由gbk转换为utf8，保存到数据库中。 wgP-"ft
#D&k7pQ,f
如何告诉mysql导入的SQL是什么字符集呢，一种方法是用--default-character-set，但有时会起不到实际作用。这是因为mysqldump出来的文件里有set names语句。比如： Tr@M]hQ
1AnTJL=
head EA192.060913.sql yk 0^rh2
cSHe'MN
-- MySQL dump 10.10 eBCAh~D<f
-- DN%TlQ8A
-- Host: localhost Database: EA192 pTf1_O$xw
-- ------------------------------------------------------ :{*^mb"`
-- Server version 5.0.16-standard-log s4q N~SZ
h: k6LM
/*!40101 SET @OLD_CHARACTER_SET_CLIENT=@@CHARACTER_SET_CLIENT */; [=QE>r)
/*!40101 SET @OLD_CHARACTER_SET_RESULTS=@@CHARACTER_SET_RESULTS */; zM%TV7G8-
/*!40101 SET @OLD_COLLATION_CONNECTION=@@COLLATION_CONNECTION */; 45lujOV
/*!40101 SET NAMES latin1 */; l.AX
{7uQJZ %
/*! */是mysql特有有句法，在其他数据库会被当成注释忽略掉。/*!后面的 40101是表示版本，在4.1.1及以上版才执行该条语句。 !S(DKIU2
}7!=@Zb)m|
这里看到有一条SET NAMES latin1。它的一个作用是告诉mysql，客户端传过去的数据是latin1字符集。因为有这样一条SET NAMES，--default-character-set也就起不到作用了。如果不幸有这样一条SQL，那么需要把它去掉或者改成SET NAMES gbk。修改或者删除的办法，当数据量比较大的时候，可以用head和tail来配合。比如还是上面的那个文件： {X(zB+
RX?'ekj+V
先用head看一下SET NAMES在第几行（数一下），上面看到是第10行。 Z"F )N&
Z|,igKp}
wc -l EA192.060913.sql 4" Ggkq
1987 EA192.060913.sql *roC[1i/N
得到总行数是1987 Tik>LU #
VSiIuRT
head -9 EA192.060913.sql > final.sql xfx\`@B s
brum@brum-laptop:~$ tail -1977 EA192.060913.sql >> final.sql k&t,69K%+
brum@brum-laptop:~$ D$q4'][9
head -9是取前9行，tail -1977是取后1977行，这样就把第10行隔过去了。 )-}v]6^
NI?9h i
得到final.sql再用mysql运行时，就可以使用--default-character-set=gbk了。 Ra( Ilo(
BR?eE@3
还有一种办法是mysqldump时使用--set-charset=false，这样就不会出现SET NAMES了。 S~)g=gB
>:fqN')
目前为止，还可能有问题，出在create table的SQL中，比如： <M8: m 3
S]| MM(A^
DROP TABLE IF EXISTS `test`; J0n!B+D<
CREATE TABLE `test` ( KxyQ
`a` varchar(100) default NULL c7n"^MK+
) ENGINE=InnoDB DEFAULT CHARSET=latin1; e#O*0 H.
{NAMzR]n
这里仍然有个CHARSET=latin1，它将导致新创建的表的缺省字符集是latin1，而不是我们想要的utf8。 x X:\E-L
;dw*g5L)
怎么办呢，如果数据量不大的话，可以考虑用编辑器把它去掉或者改成utf8，如果数据量大的话可以考虑用sed，但可能仍然时间比较长。 \'u8 16
]tzV'>Pn
还有一种办法就是mysqldump，使用--create-options=false，不导出表的创建属性。但如果导出的表的存储引擎不同的话就有问题了，因为引擎类型（innodb、myisam等）都被忽略了。 dE$ 9`i
ONRuaQ!?Y
此外，mysqldump导出时，不要使用-B，而是直接指定一个database名字，目的是不出现CREATE DATABASE语句，因为其中也可能会有缺省字符集的子句，会影响那些未在CREATE TABLE中指定字符集的表。如果你导出的SQL中有CREATE DATABASE，那么需要注意一下有没有字符集的子句，如果有的话，也需要修改。 +:]|T=;
X;;MD Wy
好了，通过上述方法导出或者处理过的导出文件可以使用mysql --default-character-set=gbk来导入了。 Vy\$emJ#y
7=`TXwr
今天有一哥们并没有碰到如此复杂的情况，只是用mysqldump从4.1中导出，再在5.0中导入，导入的时候指定--default-character-set=gb2312就行了。我想那是因为导出的文件中没有我前面说那些问题。 EM*n$t;
l@5zC l
是不是有几十个G或者更多的数据等着你移植，而且恰巧有字符集问题？祝你好运吧！
不是的。 J9X4q+
用一句不大准确，但又比较形象的说法是，在之前的系统中，我们是用latin1保存了使用gb系列字符集（gbk、gb2312等）的汉字。怎么这样说呢？ -UupUXO5
G;w^]F"91
mysql> show create table test\G P Xd/yb)
*************************** 1. row *************************** yA!_V^~
Table: test "hKSc}AH
Create Table: CREATE TABLE `test` ( &"nL!ct^L
`a` varchar(100) default NULL b;it Mv
) ENGINE=InnoDB DEFAULT CHARSET=utf8 1*Y{a0[s
1 row in set (0.00 sec) {RI1y?>>
^`;^1K.2
mysql> show create table testlatin1\G ouo^Y9
*************************** 1. row *************************** ^$:o
Table: testlatin1 |A<wk5
Create Table: CREATE TABLE `testlatin1` ( ]&*w\i7YU
`a` varchar(100) default NULL wZrF{Qc$
) ENGINE=InnoDB DEFAULT CHARSET=latin1 !~C*W/ D3I
1 row in set (0.01 sec) t/[ihd *U@
I79xX1p>
我们看到这两个表有不同的缺省字符集。此字符集是告诉我们，如果没有特别指定列的字符集，那么字符类型列的字符集与表的缺省字符集一样。 lL(K-&Oc,*
T"`~8 wi
列的字符集是要告诉mysql，这里面保存的字符所使用的字符集是什么。但到底保存的是什么字符集的字符，不由mysql决定，mysql也不进行检查。 p)5o=:Qn
ud{eg
在utf8广泛使用之前，我们使用的汉字都是GB系列的字符集，比如GB2312、GBK、GB18030等等。 5 R60Fn
"PIyL{ F:
在缺省字符集为latin1的mysql中，我们通常就把GB字符集的汉字保存到数据库中，但是却告诉mysql那是latin1字符集。而GB字符集是一个汉字占两个字节，latin1是一个字符占一个字节。也就是说一个GB汉字被当成两个latin1字符来保存了。这让我想起了当初的iso8859_1，也是类似的情况。只要我们保存和读取时都当作latin1，不进行转换，然后在显示时当作gb字符集，就能够正确使用。 k,'j9Y4
|r&:o?%B
那么怎么把latin1保存的汉字正确地导到utf8字符集的数据库中呢？ z ~1y brW
U:A-0
首先，新的数据库中的列，要使用utf8字符集。一种办法是创建database时指定缺省字符集，这样在建表时如果不指定字符集则使用database的缺省字符集。 I[^H*<}#\X
s9M@uSF_
导出的数据要以latin1字符集导出，实际上就是告诉mysql导出时不做转换（因为原有的表都是latin1字符集的）。 P*Hj'^&
q{S0kT*
mysqldump出来以后，再用mysql进行导入时，还要告诉mysql，当前的数据是gb系列的字符集，比如gbk。这样，mysql负责把数据由gbk转换为utf8，保存到数据库中。 wgP-"ft
#D&k7pQ,f
如何告诉mysql导入的SQL是什么字符集呢，一种方法是用--default-character-set，但有时会起不到实际作用。这是因为mysqldump出来的文件里有set names语句。比如： Tr@M]hQ
1AnTJL=
head EA192.060913.sql yk 0^rh2
cSHe'MN
-- MySQL dump 10.10 eBCAh~D<f
-- DN%TlQ8A
-- Host: localhost Database: EA192 pTf1_O$xw
-- ------------------------------------------------------ :{*^mb"`
-- Server version 5.0.16-standard-log s4q N~SZ
h: k6LM
/*!40101 SET @OLD_CHARACTER_SET_CLIENT=@@CHARACTER_SET_CLIENT */; [=QE>r)
/*!40101 SET @OLD_CHARACTER_SET_RESULTS=@@CHARACTER_SET_RESULTS */; zM%TV7G8-
/*!40101 SET @OLD_COLLATION_CONNECTION=@@COLLATION_CONNECTION */; 45lujOV
/*!40101 SET NAMES latin1 */; l.AX
{7uQJZ %
/*! */是mysql特有有句法，在其他数据库会被当成注释忽略掉。/*!后面的 40101是表示版本，在4.1.1及以上版才执行该条语句。 !S(DKIU2
}7!=@Zb)m|
这里看到有一条SET NAMES latin1。它的一个作用是告诉mysql，客户端传过去的数据是latin1字符集。因为有这样一条SET NAMES，--default-character-set也就起不到作用了。如果不幸有这样一条SQL，那么需要把它去掉或者改成SET NAMES gbk。修改或者删除的办法，当数据量比较大的时候，可以用head和tail来配合。比如还是上面的那个文件： {X(zB+
RX?'ekj+V
先用head看一下SET NAMES在第几行（数一下），上面看到是第10行。 Z"F )N&
Z|,igKp}
wc -l EA192.060913.sql 4" Ggkq
1987 EA192.060913.sql *roC[1i/N
得到总行数是1987 Tik>LU #
VSiIuRT
head -9 EA192.060913.sql > final.sql xfx\`@B s
brum@brum-laptop:~$ tail -1977 EA192.060913.sql >> final.sql k&t,69K%+
brum@brum-laptop:~$ D$q4'][9
head -9是取前9行，tail -1977是取后1977行，这样就把第10行隔过去了。 )-}v]6^
NI?9h i
得到final.sql再用mysql运行时，就可以使用--default-character-set=gbk了。 Ra( Ilo(
BR?eE@3
还有一种办法是mysqldump时使用--set-charset=false，这样就不会出现SET NAMES了。 S~)g=gB
>:fqN')
目前为止，还可能有问题，出在create table的SQL中，比如： <M8: m 3
S]| MM(A^
DROP TABLE IF EXISTS `test`; J0n!B+D<
CREATE TABLE `test` ( KxyQ
`a` varchar(100) default NULL c7n"^MK+
) ENGINE=InnoDB DEFAULT CHARSET=latin1; e#O*0 H.
{NAMzR]n
这里仍然有个CHARSET=latin1，它将导致新创建的表的缺省字符集是latin1，而不是我们想要的utf8。 x X:\E-L
;dw*g5L)
怎么办呢，如果数据量不大的话，可以考虑用编辑器把它去掉或者改成utf8，如果数据量大的话可以考虑用sed，但可能仍然时间比较长。 \'u8 16
]tzV'>Pn
还有一种办法就是mysqldump，使用--create-options=false，不导出表的创建属性。但如果导出的表的存储引擎不同的话就有问题了，因为引擎类型（innodb、myisam等）都被忽略了。 dE$ 9`i
ONRuaQ!?Y
此外，mysqldump导出时，不要使用-B，而是直接指定一个database名字，目的是不出现CREATE DATABASE语句，因为其中也可能会有缺省字符集的子句，会影响那些未在CREATE TABLE中指定字符集的表。如果你导出的SQL中有CREATE DATABASE，那么需要注意一下有没有字符集的子句，如果有的话，也需要修改。 +:]|T=;
X;;MD Wy
好了，通过上述方法导出或者处理过的导出文件可以使用mysql --default-character-set=gbk来导入了。 Vy\$emJ#y
7=`TXwr
今天有一哥们并没有碰到如此复杂的情况，只是用mysqldump从4.1中导出，再在5.0中导入，导入的时候指定--default-character-set=gb2312就行了。我想那是因为导出的文件中没有我前面说那些问题。 EM*n$t;
l@5zC l
是不是有几十个G或者更多的数据等着你移植，而且恰巧有字符集问题？祝你好运吧！
相关阅读 更多 +
