MySQL編碼latin1轉utf8

時間 2019-12-09

標籤 mysql 編碼 latin1 latin utf8 utf 欄目 MySQL 简体版

原文原文鏈接

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系列的字符集，好比GB23十二、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

　　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來導入了。html

總結，基本上執行的命令以下：mysql

一、備份數據庫sql

mysqldump --default-character-set=latin1 --create-options=false --set-charset=false -u root -p 數據庫名稱數據庫

>E:\back.sql安全

二、建立新數據庫編輯器

CREATE DATABASE 數據庫名稱 CHARACTER SET utf8 COLLATE utf8_general_ci;fetch

三、導入數據spa

MySQL -u root -p --default-character-set=gbk 數據庫名稱<E:\back.sql.net

》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》》htm

從 MySQL4.1 開始，增長了對字符集的明細區分。字符集常遇到的問題是亂碼和查詢結果不許兩個問題，後面這個結果隱患仍是很是大的。

MySQL 默認字符集爲 latin1 或者叫 iso-8859-1。請查看

http://faqs.cs.uu.nl/na-dir/internationalization/iso-8859-1-charset.html

在這個字符集中二進制的 0x F九、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 與 0xC9F九、0xC9FB，也就是「聲甥」兩個字在 latin1 都對應字母 U，如下語句就會返回錯誤的結果

SELECT * FROM article author = '女生' 就會出現女聲、女生、女甥、三個結果。舉個例子：
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 ('女生','女生'); INSERT INTO article (message, message2) VALUES ('女聲','女聲'); INSERT INTO article (message, message2) VALUES ('女牲','女牲'); INSERT INTO article (message, message2) VALUES ('女甥','女甥'); INSERT INTO article (message, message2) VALUES ('女升','女升'); INSERT INTO article (message, message2) VALUES ('女滲','女滲');

咱們創建兩種不一樣校對字符集的字段，存儲一樣的內容。使用：

SELECT * FROM article WHERE message = '女生';

獲得三條記錄女生女生

女聲女聲

女甥女甥

使用：

SELECT * FROM article WHERE message2 = '女生';

獲得一條記錄女生女生

解決方法有兩種，使用 PHP 的一種方法是：

$sql = "SELECT * FROM article author='女生'";

$res = mysql_query($sql);

$article = array();

while($row = mysql_fetch_assoc($res))

{

if($row['author'] == '女生')

{

$article = $row;

break;

}

使用 MySQL 自己特性解決的方法是使用 latin1_bin 校對字符集，如 message2，但若是你的數據已是其它 latin 校對字符集，使用下面的方法補救：

SELECT * FROM article WHERE message = '女生' collate latin1_bin; SELECT * FROM article WHERE BINARY message = '女生';

從 MySQL 手冊中說，這兩種方式是同樣的，而實質上，上面一種方法會利用到索引，下面一種方法沒有使用任何索引。

可使用 EXPLAIN 語法檢查如下三句的區別：

explain SELECT * FROM article WHERE message = '女生' collate latin1_bin;
explain SELECT * FROM article WHERE BINARY message = '女生';
explain SELECT * FROM article WHERE message = '女生';

若是一套系統中使用惟一索引或者關鍵字，危險性還小一些，頂可能是註冊了女生，當你在註冊女甥的時候，系統報「該用戶名已經存在」這樣的謊話。

對於多個系統使用同一套 SSO 通行證來講。這個安全隱患很是大，能夠在非 MySQL 的系統中註冊「女甥」，在回到 MySQL 系統中進行登陸。若是這個「女生」是管理員的話，那麼你就獲得了最高權限。