MySQL資料移植中的亂碼問題，mysql資料移植亂碼

MySQL資料移植中的亂碼問題，mysql資料移植亂碼

MySQL資料如果從低版本的mysql向更高的版本移植的時候，若移植的資料中含有中文的資料時，很容易出現亂碼問題。很多是在從MySQL4.x向MySQL5.x移植的時候出現。例如，我找了一個用mysql.4建立的表，表結構如下：

CREATE TABLE `tb_bookcase` (

 `id` int(10) unsigned NOT NULL AUTO_INCREMENT,

 `name` varchar(30) DEFAULT NULL,

 `Column_3` char(10) DEFAULT NULL,

 PRIMARY KEY (`id`)

) ENGINE=MyISAM AUTO_INCREMENT=4 DEFAULTCHARSET=latin1;

從上面的結果中可以看出MySQL的預設字元集是latin1，在使用MySQL4.x的時候，很多人都是用的latin1字元集。而當使用MySQL5或者更高的版本時往往使用的是UTF-8。但是這個問題怎麼決解呢？

網上找了一下，發現特別麻煩，我是這樣子決解的，就是我們先把整個資料庫按指定的字元匯出，匯出的資料的中文為正常編碼（親身試過），然後再改一下編碼方式匯入就OK了。

匯出是我們在dos命令下使用輸入

Mysqldump -hlocalhost -uroot -proot--default-character-set=latin1 dataBaseName>d:\test.sql

修改下test.sql的檔案中所有的編碼，就是把檔案中的latin1改為utf8或者其他編碼，再用source命令執行test.sql指令檔，或者按照以下的方式匯入

mysql  -uroot-p123456 --default-character-set=gb2312 test<d:/test.sql

上面的default-character-set我們指定特定的字元匯出，也就是上面我們所說的latin1，此時在test.sql中的指令碼代碼若有中文時是正常的代碼。

以下是網友的代碼：。

在之前的系統中，我們是用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看一下SETNAMES在第幾行（數一下），上面看到是第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語句，因為其中也可能會有預設字元集的子句，會影響那些未在CREATETABLE中指定字元集的表。如果你匯出的SQL中有CREATEDATABASE，那麼需要注意一下有沒有字元集的子句，如果有的話，也需要修改。

好了，通過上述方法匯出或者處理過的匯出檔案可以使用mysql--default-character-set=gbk來匯入了。