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

　　[email protected]:~$ tail -1977 EA192.060913.sql >> final.sql

　　[email protected]:~$

　 　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 系統中進行登入。如果這個“女生”是管理員的話，那麼你就得到了 最高許可權。

MySQL編碼latin1轉utf8