如何解決MySQL字符集亂碼問題

1、字符集本概念

字符集的基本概念以下 :

字符(Character)是指人類語言中最小的表義符號。例如’A’、’B’等
  給定一系列字符，對每一個字符賦予一個數值，用數值來表明對應的字符，這一數值就是字符的編碼(Encoding)。例如，咱們給字 符’A’賦予數值0，給字符’B’賦予數值1，則0就是字符’A’的編碼
  給定一系列字符並賦予對應的編碼後，全部這些字符和編碼對組成的集合就是字符集(Character Set)。例如，給定字符列表爲{’A’,’B’}時，{’A’=>0, ‘B’=>1}就是一個字符集
  字符序(Collation)是指在同一字符集內字符之間的比較規則
  肯定字符序後，才能在一個字符集上定義什麼是等價的字符，以及字符之間的大小關係
  每一個字符序惟一對應一種字符集，但一個字符集能夠對應多種字符序，其中有一個是默認字符序(Default Collation)
  MySQL中的字符序名稱聽從命名慣例：以字符序對應的字符集名稱開頭；以_ci(表示大小寫不敏感)、_cs(表示大小寫敏感)或_bin(表示按編碼值比較)結尾。例如：在字符序「utf8_general_ci」下，字符「a」和「A」是等價的。

2、常見字符集

1） ASCII

ASCII是英文American Standard Code for Information Interchange的縮寫,美國標準信息交換代碼是由美國國家標準學會(American National Standard Institute , ANSI )制定的，標準的單字節字符編碼方案，用於基於文本的數據。是基於拉丁字母的一套電腦編碼系統。它主要用於顯示現代英語和其餘西歐語言。它是現今最通用的 單字節編碼系統，並等同於國際標準ISO/IEC 646。

ASCII 碼使用指定的7 位或8 位二進制數組合來表示128 或256 種可能的字符。標準ASCII 碼也叫基礎ASCII碼，使用7 位二進制數來表示全部的大寫和小寫字母，數字0 到九、標點符號， 以及在美式英語中使用的特殊控制字符。

2）GBK

GBK即漢字內碼擴展規範，K爲擴展的漢語拼音中「擴」字的聲母。英文全稱Chinese Internal Code Specification。GBK編碼標準兼容GB2312，共收錄漢字21003個、符號883個，並提供1894個造字碼位，簡、繁體字融於一庫。

GB2312碼是中華人民共和國國家漢字信息交換用編碼，全稱《信息交換用漢字編碼字符集——基本集》，1980年由國家標準總局發佈。基本集共收入漢字 6763個和非漢字圖形字符682個，通行於中國大陸。新加坡等地也使用此編碼。GBK是對GB2312-80的擴展，也就是CP936字碼表 (Code Page 936)的擴展（以前CP936和GB 2312-80如出一轍）。

3）latin1

Latin1是ISO-8859-1的別名，有些環境下寫做Latin-1。

ISO-8859-1
ISO-8859-1編碼是單字節編碼，向下兼容ASCII，其編碼範圍是0x00-0xFF，0x00-0x7F之間徹底和ASCII一致，0x80-0x9F之間是控制字符，0xA0-0xFF之間是文字符號。

ISO-8859-1收錄的字符除ASCII收錄的字符外，還包括西歐語言、希臘語、泰語、阿拉伯語、希伯來語對應的文字符號。歐元符號出現的比較晚，沒有被收錄在ISO-8859-1當中。

由於ISO-8859-1編碼範圍使用了單字節內的全部空間，在支持ISO-8859-1的系統中傳輸和存儲其餘任何編碼的字節流都不會被拋棄。換言之，把其餘任何編碼的字節流看成ISO-8859-1編碼看待都沒有問題。這是個很重要的特性，MySQL數據庫默認編碼是Latin1就是利用了這個 特性。ASCII編碼是一個7位的容器，ISO-8859-1編碼是一個8位的容器。

4）UTF-8

UTF-8（8-bit Unicode Transformation Format）是一種針對Unicode的可變長度字符編碼，又稱萬國碼。由Ken Thompson於1992年建立。如今已經標準化爲RFC 3629。UTF-8用1到4個字節編碼UNICODE字符。用在網頁上能夠同一頁面顯示中文簡體繁體及其它語言（如日文，韓文）

UTF-8以字節爲單位對Unicode進行編碼。

UTF-8的特色是對不一樣範圍的字符使用不一樣長度的編碼。對於0x00-0x7F之間的字符，UTF-8編碼與ASCII編碼徹底相同。UTF-8 編碼的最大長度是4個字節。

從上表能夠看出，4字節模板有21個x，便可以容納21位二進制數字。Unicod的最大碼位0x10FFFF也只有21 位。

3、MySQL字符集轉換過程

1. MySQL Server收到請求時將請求數據從character_set_client轉換爲character_set_connection

2. 進行內部操做前將請求數據從character_set_connection轉換爲內部操做字符集，其肯定方法以下:

1) 使用每一個Column的CHARACTER SET設定值；
2) 如未設置Column的Character SET，則使用對應表的DEFAULT CHARACTER SET設定值
3) 如Column、Table均未設地Charater SET，則使用對應數據庫的DEFAULT CHARACTER SET設定值
4) 如Column、Table、Database均未設地Charater SET，則使用character_set_server設定值。

3. 將操做結果從內部操做字符集轉換爲character_set_results

4、中文亂碼現象

Mysqldump導入亂碼

Load data導入亂碼

5、程序及MySQL字符集配置狀況

出現亂碼狀況，首先確認寫入程序使用的字符集，MySQL使用的字符集
MySQL使用的字符集狀況

經過SHOW VARIABLES LIKE ‘character%’，在上面例子中經過語句得到字符集設置狀況以下:

Mysqldump導入亂碼緣由 :

一、 首先確認mysqldump –help或查看備份文件頭部信息確認默認字符集
在上例中經過mysqldump –help查看

經過備份文件查看

二、 經過 mysql –help 確認導入字符集

default-character-set        gbk

導入的兩種狀況以下

1）不修改備份文件，導入因爲sql文件中存在set names utf8，則導入後字符集使用的依然是utf8,在系統默認顯示字符集爲gbk的狀況下，則顯示爲亂碼，此時則須要使用set names utf8 才能正常顯示字符

2）修改備份文件，導入前將sql中的set names utf8 去除，在mysql默認字符集爲gbk的狀況下導入後字符集爲gbk,此時mysql顯示字符集爲 gbk，二者一致，則顯示正常

Load data導入亂碼緣由

對於load data導入亂碼問題的具體解釋在官方文檔中有說起，請參考:

這些是沒法影響到導入結果的，所以應使用Load 自身的字符集參數來進行數據導入，以下方式:

mysql>load data infile '/tmp/gongzuoshi.ttt' into chartest ; CHARACTER
SET gbk

6、總結

一、 編譯安裝MySQL的時候指定DEFAULT_CHARSET=[charset] 與寫入程序保持一致
二、 my.cnf中字符集設置與寫入程序保持一致
三、 導入數據時，將導入程序與數據庫的連接配置爲與數據庫字符集一致
四、load data須要在語句中設置字符集參數

原文來自：雲計算實戰

本文地址：http://www.linuxprobe.com/solve-mysql-character.html