MySQL資料庫中資料庫移植中的亂碼問題

來源:互聯網
上載者:User

MySQL移植含有中文的資料時,很容易出現亂碼問題。很多是在從MySQL4.x向MySQL5.x移植的時候出現。MySQL的預設字元集是latin1,在使用MySQL4.x的時候,很多人都是用的latin1字元集。而當使用MySQL5時往往願意使用UTF-8。那麼我們的任務是不是要把資料中的字元從latin1轉為UTF-8呢?不是的。

用一句不大準確,但又比較形象的說法是,在之前的系統中,我們是用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看一下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。

怎麼辦呢,如果資料量不大的話,可以考慮用編輯器把它去掉或者改成UTF8,如果資料量大的話可以考慮用sed,但可能仍然時間比較長。

還有一種辦法就是mysqldump,使用--create-options=false,不匯出表的建立屬性。但如果匯出的表的儲存引擎不同的話就有問題了,因為引擎類型(innodb、myisam等)都被忽略了。

此外,mysqldump匯出時,不要使用-B,而是直接指定一個database名字,目的是不出現CREATE DATABASE語句,因為其中也可能會有預設字元集的子句,會影響那些未在CREATE TABLE中指定字元集的表。如果你匯出的SQL中有CREATE DATABASE,那麼需要注意一下有沒有字元集的子句,如果有的話,也需要修改。

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



相關文章

Beyond APAC's No.1 Cloud

19.6% IaaS Market Share in Asia Pacific - Gartner IT Service report, 2018

Learn more >

Apsara Conference 2019

The Rise of Data Intelligence, September 25th - 27th, Hangzhou, China

Learn more >

Alibaba Cloud Free Trial

Learn and experience the power of Alibaba Cloud with a free trial worth $300-1200 USD

Learn more >

聯繫我們

該頁面正文內容均來源於網絡整理,並不代表阿里雲官方的觀點,該頁面所提到的產品和服務也與阿里云無關,如果該頁面內容對您造成了困擾,歡迎寫郵件給我們,收到郵件我們將在5個工作日內處理。

如果您發現本社區中有涉嫌抄襲的內容,歡迎發送郵件至: info-contact@alibabacloud.com 進行舉報並提供相關證據,工作人員會在 5 個工作天內聯絡您,一經查實,本站將立刻刪除涉嫌侵權內容。