MySQL编码latin1转utf8

mysql移植含有中文的数据时，很容易出现乱码问题。很多是在从mysql4.x向mysql5.x移植的时候出现。mysql的缺省字符集是 latin1，在使用mysql4.x的时候，很多人都是用的latin1字符集。而当使用mysql5时往往愿意使用utf8。那么我们的任务是不是要 把数据中的字符从latin1转为utf8呢？

　　不是的。

　　用一句不大准确，但又比较形象的说法是，在之前的系 统中，我们是用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也不进行检查。

　 　在utf8广泛使用之前，我们使用的汉字都是GB系列的字符集，比如GB2312、GBK、GB18030等等。

　　在缺省字符集为 latin1的mysql中，我们通常就把GB字符集的汉字保存到数据库中，但是却告诉mysql那是latin1字符集。而GB字符集是一个汉字占两个 字节，latin1是一个字符占一个字节。也就是说一个GB汉字被当成两个latin1字符来保存了。这让我想起了当初的iso8859_1，也是类似的 情况。只要我们保存和读取时都当作latin1，不进行转换，然后在显示时当作gb字符集，就能够正确使用。

　　那么怎么把 latin1保存的汉字正确地导到utf8字符集的数据库中呢？

　　首先，新的数据库中的列，要使用utf8字符集。一种办法是创建 database时指定缺省字符集，这样在建表时如果不指定字符集则使用database的缺省字符集。

　　导出的数据要以 latin1字符集导出，实际上就是告诉mysql导出时不做转换（因为原有的表都是latin1字符集的）。

　　mysqldump 出来以后，再用mysql进行导入时，还要告诉mysql，当前的数据是gb系列的字符集，比如gbk。这样，mysql负责把数据由gbk转换为 utf8，保存到数据库中。

　　如何告诉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

　　;

　　;

　　 ;

　 　;

　　是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，如果数据量大的 话可以考虑用sed，但可能仍然时间比较长。

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

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

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

总结，基本上执行的命令如下：

1、备份数据库

mysqldump --default-character-set=latin1 --create-options=false --set-charset=false  -u root -p 数据库名称

>E:\back.sql

2、创建新数据库

CREATE DATABASE 数据库名称 CHARACTER SET utf8 COLLATE utf8_general_ci;

3、导入数据

MySQL -u root -p --default-character-set=gbk  数据库名称<E:\back.sql

》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》

从 MySQL4.1 开始，增加了对字符集的明细区分。字符集常遇到的问题是乱码和查询结果不准 两个问题，后面这个结果隐患还是非常大的。

MySQL 默认字符集为 latin1 或者叫 iso-8859-1。 请查看

http://faqs.cs.uu.nl/na-dir/internationalization/iso-8859-1-charset.html

在这个字符集中二进制的 0x F9、0xFA、0x FB 都是拉丁字母 U 的不同读音，雷同与中文的四 声说法。

| F9 | 249 | ù | LATIN SMALL LETTER U WITH GRAVE ACCENT

| FA | 250 | ú | LATIN SMALL LETTER U WITH ACUTE ACCENT

| FB | 251 | û | LATIN SMALL LETTER U WITH CIRCUMFLEX ACCENT

这样一来，中文的“女生” 0xC9FA 与 0xC9F9、0xC9FB，也就是“声甥”两个字在 latin1 都 对应字母 U，以下语句就会返回错误的结果

SELECT * FROM article author = &apos;女生&apos; 就会出现女声、女生、女甥、三个结果。 举个例子：
DROP TABLE IF EXISTS article; CREATE TABLE article (
message varchar(255) collate latin1_swedish_ci NOT NULL, message2 varchar(255) collate latin1_bin NOT NULL,
KEY message (message)
) ENGINE=MyISAM charset=latin1;
INSERT INTO article (message, message2) VALUES (&apos;女生&apos;,&apos;女生&apos;); INSERT INTO article (message, message2) VALUES (&apos;女声&apos;,&apos;女声&apos;); INSERT INTO article (message, message2) VALUES (&apos;女牲&apos;,&apos;女牲&apos;); INSERT INTO article (message, message2) VALUES (&apos;女甥&apos;,&apos;女甥&apos;); INSERT INTO article (message, message2) VALUES (&apos;女升&apos;,&apos;女升&apos;); INSERT INTO article (message, message2) VALUES (&apos;女渗&apos;,&apos;女渗&apos;);

我们建立两种不同校对字符集的字段，存储同样的内容。使用：

SELECT * FROM article WHERE message = &apos;女生&apos;;

得到三条记录 女生 女生

女声 女声

女甥 女甥

使用：

SELECT * FROM article WHERE message2 = &apos;女生&apos;;

得到一条记录 女生 女生

解决方法有两种，使用 PHP 的一种方法是：

$sql = "SELECT * FROM article author=&apos;女生&apos;";

$res = mysql_query($sql);

$article = array();

while($row = mysql_fetch_assoc($res))

{

if($row[&apos;author&apos;] == &apos;女生&apos;)

{

$article = $row;

break;

}

}

使用 MySQL 本身特性解决的方法是使用 latin1_bin 校对字符集，如 message2，但如果你的数据 已经是其它 latin 校对字符集，使用下面的方法补救：

SELECT * FROM article WHERE message = &apos;女生&apos; collate latin1_bin; SELECT * FROM article WHERE BINARY message = &apos;女生&apos;;

从 MySQL 手册中说，这两种方式是一样的，而实质上，上面一种方法会利用到索引，下面一 种方法没有使用任何索引。

可以使用 EXPLAIN 语法检查以下三句的区别：

explain SELECT * FROM article WHERE message = &apos;女生&apos; collate latin1_bin;
explain SELECT * FROM article WHERE BINARY message = &apos;女生&apos;;
explain SELECT * FROM article WHERE message = &apos;女生&apos;;

如果一套系统中使用唯一索引或者关键字，危险性还小一些，顶多是注册了女生，当你在注册 女甥的时候，系统报“该用户名已经存在”这样的谎言。

对于多个系统使用同一套 SSO 通行证来说。这个安全隐患非常大，可以在非 MySQL 的系统中 注册“女甥”，在回到 MySQL 系统中进行登录。如果这个“女生”是管理员的话，那么你就得到了 最高权限。