MySQL移植含有中文的數(shù)據(jù)時(shí)，很容易出現(xiàn)亂碼問(wèn)題。很多是在從MySQL4.x向MySQL5.x移植的時(shí)候出現(xiàn)。MySQL的缺省字符集是latin1，在使用MySQL4.x的時(shí)候，很多人都是用的latin1字符集。而當(dāng)使用MySQL5時(shí)往往愿意使用UTF-8。那么我們的任務(wù)是不是要把數(shù)據(jù)中的字符從latin1轉(zhuǎn)為UTF-8呢？不是的。

用一句不大準(zhǔn)確，但又比較形象的說(shuō)法是，在之前的系統(tǒng)中，我們是用latin1保存了使用GB系列字符集（GBK、GB2312等）的漢字。怎么這樣說(shuō)呢？

以下為引用的內(nèi)容： 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)

 
字符集是告訴我們，如果沒(méi)有特別指定列的字符集，那么字符類型列的字符集與表的缺省字符集一樣。

列的字符集是要告訴MySQL，這里面保存的字符所使用的字符集是什么。但到底保存的是什么字符集的字符，不由MySQL決定，MySQL也不進(jìn)行檢查。

在UTF-8廣泛使用之前，我們使用的漢字都是GB系列的字符集，比如GB2312、GBK、GB18030等等。

在缺省字符集為latin1的MySQL中，我們通常就把GB字符集的漢字保存到數(shù)據(jù)庫(kù)中，但是卻告訴MySQL那是latin1字符集。而GB字符集是一個(gè)漢字占兩個(gè)字節(jié)，latin1是一個(gè)字符占一個(gè)字節(jié)。也就是說(shuō)一個(gè)GB漢字被當(dāng)成兩個(gè)latin1字符來(lái)保存了。這讓我想起了當(dāng)初的iso8859_1，也是類似的情況。只要我們保存和讀取時(shí)都當(dāng)作latin1，不進(jìn)行轉(zhuǎn)換，然后在顯示時(shí)當(dāng)作GB字符集，就能夠正確使用。

那么怎么把latin1保存的漢字正確地導(dǎo)UTF-8字符集的數(shù)據(jù)庫(kù)中呢？

首先，新的數(shù)據(jù)庫(kù)中的列，要使用UTF-8字符集。一種辦法是創(chuàng)建database時(shí)指定缺省字符集，這樣在建表時(shí)如果不指定字符集則使用database的缺省字符集。

導(dǎo)出的數(shù)據(jù)要以latin1字符集導(dǎo)出，實(shí)際上就是告訴MySQL導(dǎo)出時(shí)不做轉(zhuǎn)換（因?yàn)樵�有的表都是latin1字符集的）。

mysqldump出來(lái)以后，再用MySQL進(jìn)行導(dǎo)入時(shí)，還要告訴MySQL，當(dāng)前的數(shù)據(jù)是gb系列的字符集，比如gbk。這樣，MySQL負(fù)責(zé)把數(shù)據(jù)由gbk轉(zhuǎn)換為UTF-8，保存到數(shù)據(jù)庫(kù)中。

如何告訴MySQL導(dǎo)入的SQL是什么字符集呢，一種方法是用--default-character-set，但有時(shí)會(huì)起不到實(shí)際作用。這是因?yàn)閙ysqldump出來(lái)的文件里有set names語(yǔ)句。比如：

以下為引用的內(nèi)容： 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特有有句法，在其他數(shù)據(jù)庫(kù)會(huì)被當(dāng)成注釋忽略掉。/*!后面的40101是表示版本，在4.1.1及以上版才執(zhí)行該條語(yǔ)句。

這里看到有一條SET NAMES latin1。它的一個(gè)作用是告訴mysql，客戶端傳過(guò)去的數(shù)據(jù)是latin1字符集。因?yàn)橛羞@樣一條SET NAMES，--default-character-set也就起不到作用了。如果不幸有這樣一條SQL，那么需要把它去掉或者改成SET NAMES gbk。修改或者刪除的辦法，當(dāng)數(shù)據(jù)量比較大的時(shí)候，可以用head和tail來(lái)配合。比如還是上面的那個(gè)文件：

先用head看一下SET NAMES在第幾行（數(shù)一下），上面看到是第10行。

以下為引用的內(nèi)容： wc -l EA192.060913.sql 1987 EA192.060913.sql 得到總行數(shù)是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行隔過(guò)去了。

得到final.sql再用MySQL運(yùn)行時(shí)，就可以使用--default-character-set=gbk了。

還有一種辦法是mysqldump時(shí)使用--set-charset=false，這樣就不會(huì)出現(xiàn)SET NAMES了。

目前為止，還可能有問(wèn)題，出在create table的SQL中，比如：

以下為引用的內(nèi)容： DROP TABLE IF EXISTS `test`; CREATE TABLE `test` ( `a` varchar(100) default NULL ) ENGINE=InnoDB DEFAULT CHARSET=latin1;

 
這里仍然有個(gè)CHARSET=latin1，它將導(dǎo)致新創(chuàng)建的表的缺省字符集是latin1，而不是我們想要的UTF8。

怎么辦呢，如果數(shù)據(jù)量不大的話，可以考慮用編輯器把它去掉或者改成UTF8，如果數(shù)據(jù)量大的話可以考慮用sed，但可能仍然時(shí)間比較長(zhǎng)。

還有一種辦法就是mysqldump，使用--create-options=false，不導(dǎo)出表的創(chuàng)建屬性。但如果導(dǎo)出的表的存儲(chǔ)引擎不同的話就有問(wèn)題了，因?yàn)橐�擎類型（innodb、myisam等）都被忽略了。

此外，mysqldump導(dǎo)出時(shí)，不要使用-B，而是直接指定一個(gè)database名字，目的是不出現(xiàn)CREATE DATABASE語(yǔ)句，因?yàn)槠渲幸部赡軙?huì)有缺省字符集的子句，會(huì)影響那些未在CREATE TABLE中指定字符集的表。如果你導(dǎo)出的SQL中有CREATE DATABASE，那么需要注意一下有沒(méi)有字符集的子句，如果有的話，也需要修改。

好了，通過(guò)上述方法導(dǎo)出或者處理過(guò)的導(dǎo)出文件可以使用mysql --default-character-set=gbk來(lái)導(dǎo)入了。

關(guān)鍵字：MySQL、數(shù)據(jù)庫(kù)

【 頂部 】 【 關(guān)閉 】