Chinaunix首页 | 论坛 | 认证专区 | 博客 登录 | 注册

大笑三声liuxd.blog.chinaunix.net

爱开源,爱互联,爱足球,爱巴萨。LAMP+C+NoSQL+JavaScript。

  • 博客访问: 117308
  • 博文数量: 33
  • 博客积分: 708
  • 博客等级: 上士
  • 技术积分: 285
  • 用 户 组: 普通用户
  • 注册时间: 2010-11-28 23:05
文章分类

全部博文(33)

文章存档

2012年(1)

2011年(32)

微信关注

IT168企业级官微



微信号:IT168qiye



系统架构师大会



微信号:SACC2013

分类: Mysql/postgreSQL

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

  /*!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,如果数据量大的话可以考虑用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  数据库名称

阅读(443) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~
评论热议
请登录后评论。

登录 注册