最近,在項目組使用的mysql數據庫中,插入數據出現亂碼,關於這個問題做了下總結,我們從最基本的地方說起,到錯誤產生的深層次原因和解決辦法。
基本概念:
• 字符(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”是等價的;
MySQL的字符集支持:
1、字符集(Character set)。
2、排序比較方式(Collation)。
通過命令:show character set 和 show collation 可以分別查看Mysql支持的字符集和排序方式。
– mysql> show character set;
– mysql> show collation;
Mysql對於字符集的支持細化到四個層次:
1、服務器(server);
2、數據庫(database);
3、數據表(table)(字段column);
4、連接(connection);
MySQL字符集變量:
– character_set_server:默認的內部操作字符集
– character_set_client:客戶端來源數據使用的字符集
– character_set_connection:連接層字符集
– character_set_results:查詢結果字符集
– character_set_database:當前選中數據庫的默認字符集
– character_set_system:系統元數據(字段名等)字符集
– 還有以collation_開頭的同上面對應的變量,用來描述字符序。
用introducer指定文本字符串的字符集:
格式為:[_charset] ’string’ [COLLATE collation]
例如:
– SELECT _latin1 ’string’;
– SELECT _utf8 ‘你好’ COLLATE utf8_general_ci;
由introducer修飾的文本字符串在請求過程中不經過多余的轉碼,直接轉換為內部字符集處理。
1、查看默認字符集(默認情況下,Mysql的字符集是latin1(ISO_8859_1)
通常,查看系統的字符集和排序方式的設定可以通過下面的兩條命令:
– mysql> SHOW VARIABLES LIKE 'character%';
+--------------------------+---------------------------------+
| Variable_name | Value |
+--------------------------+---------------------------------+
| character_set_client | utf8 |
| character_set_connection | utf8 |
| character_set_database | utf8 |
| character_set_filesystem | binary |
| character_set_results | utf8 |
| character_set_server | utf8 |
| character_set_system | utf8 |
| character_sets_dir | D:Program FilesMySQLMySQL Server 5.1sharecharsets |
+--------------------------+---------------------------------+
– mysql> SHOW VARIABLES LIKE 'collation_%';
+----------------------+-----------------+
| Variable_name | Value |
+----------------------+-----------------+
| collation_connection | utf8_general_ci |
| collation_database | utf8_general_ci |
| collation_server | utf8_general_ci |
+----------------------+-----------------+
2、修改默認字符集
(1) 最簡單的修改方法,就是修改mysql的my.ini文件中的字符集鍵值(共6個),如:
[client]
default-character-set = utf8
default-character-set = utf8
character-set-server = utf8
collation-server = utf8_general_ci
init_connect = 'SET collation_connection = utf8_general_ci '
init_connect = 'SET NAMES utf8'
修改完後,重啟mysql的服務。
(2) 還有一種修改字符集的方法,就是使用mysql的命令:
代碼如下 復制代碼 – mysql> SET character_set_connection = utf8 ;一般就算設置了表的默認字符集為utf8並且通過UTF-8編碼發送查詢,你會發現存入數據庫的仍然是亂碼。問題就出在這個connection連接層上。
解決方法是在發送查詢前執行一下下面這句:
代碼如下 復制代碼 SET NAMES 'utf8';它相當於下面的三句指令:
代碼如下 復制代碼 SET character_set_client = utf8;
檢測字符集問題的一些手段
• SHOW CHARACTER SET; #查看mysql支持的字符集
• SHOW COLLATION; #查看mysql的字符序列(排序方式)
• SHOW VARIABLES LIKE ‘character%’; #查看mysql系統默認字符集設置值
• SHOW VARIABLES LIKE ‘collation%’; #查看mysql系統默認的字符序列(排序方式) 設置值
• SQL函數HEX、LENGTH、CHAR_LENGTH
• SQL函數CHARSET、COLLATION
MySQL中的字符集轉換過程:
1. MySQL Server收到請求時將請求數據從character_set_client轉換為character_set_connection;
2. 進行內部操作前將請求數據從character_set_connection轉換為內部操作字符集,其確定方法如下:
- 使用每個數據字段的CHARACTER SET設定值;
- 若上述值不存在,則使用對應數據表的DEFAULT CHARACTER SET設定值(MySQL擴展,非SQL標准);
- 若上述值不存在,則使用對應數據庫的DEFAULT CHARACTER SET設定值;
- 若上述值不存在,則使用character_set_server設定值。
3. 將操作結果從內部操作字符集轉換為character_set_results。
我們產生的亂碼問題:
a 我們的字段沒有設置字符集,因此使用表的數據集;
b 我們的表沒有指定字符集,默認使用數據庫存的字符集;
c 我們的數據庫在創建的時候沒有指定字符集,因此使用character_set_server設定值;
d 我們沒有特意去修改character_set_server的指定字符集,因此使用mysql默認;
e mysql默認的字符集是latin1,因此,我們使用了latin1字符集,而我們character_set_connection的字符集是UTF-8,插入中文亂碼也再所難免了。
MySQL默認字符集:
MySQL對於字符集的指定可以細化到一個數據庫,一張表,一列,應該用什麼字符集。但是傳統的程序在創建數據庫和數據表時並沒有使用那麼復雜的配置,它們用的是默認的配置,那麼,默認的配置從何而來呢?
(1)編譯MySQL 時,指定了一個默認的字符集,這個字符集是 latin1;
(2)安裝MySQL 時,可以在配置文件 (my.ini) 中指定一個默認的的字符集,如果沒指定,這個值繼承自編譯時指定的;
(3)啟動mysqld 時,可以在命令行參數中指定一個默認的的字符集,如果沒指定,這個值繼承自配置文件中的配置,此時 character_set_server 被設定為這個默認的字符集;
(4)當創建一個新的數據庫時,除非明確指定,這個數據庫的字符集被缺省設定為character_set_server;
(5)當選定了一個數據庫時,character_set_database 被設定為這個數據庫默認的字符集;
(6)在這個數據庫裡創建一張表時,表默認的字符集被設定為 character_set_database,也就是這個數據庫默認的字符集;
(7)當在表內設置一欄時,除非明確指定,否則此欄缺省的字符集就是表默認的字符集;
簡單的總結一下,如果什麼地方都不修改,那麼所有的數據庫的所有表的所有欄位的都用 latin1 存儲,不過我們如果安裝 MySQL,一般都會選擇多語言支持,也就是說,安裝程序會自動在配置文件中把default_character_set 設置為 UTF-8,這保證了缺省情況下,所有的數據庫的所有表的所有欄位的都用 UTF-8 存儲。
常見問題解析
1)向默認字符集為utf8的數據表插入utf8編碼的數據前沒有設置連接字符集,查詢時設置連接字符集為utf8
– 插入時根據MySQL服務器的默認設置,character_set_client、character_set_connection和character_set_results均為latin1;
– 插入操作的數據將經過latin1=>latin1=>utf8的字符集轉換過程,這一過程中每個插入的漢字都會從原始的3個字節變成6個字節保存;
– 查詢時的結果將經過utf8=>utf8的字符集轉換過程,將保存的6個字節原封不動返回,產生亂碼。
2)向默認字符集為latin1的數據表插入utf8編碼的數據前設置了連接字符集為utf8(我們遇到的錯誤就是屬於這一種)
– 插入時根據連接字符集設置,character_set_client、character_set_connection和character_set_results均為utf8;
-插入數據將經過utf8=>utf8=>latin1的字符集轉換,若原始數據中含有u0000~u00ff范圍以外的 Unicode字符,會因為無法在latin1字符集中表示而被轉換為“?”(0×3F)符號,以後查詢時不管連接字符集設置如何都無法恢復其內容了。
使用MySQL字符集時的建議
• 建立數據庫/表和進行數據庫操作時盡量顯式指出使用的字符集,而不是依賴於MySQL的默認設置,否則MySQL升級時可能帶來很大困擾;
• 數據庫和連接字符集都使用latin1時,雖然大部分情況下都可以解決亂碼問題,但缺點是無法以字符為單位來進行SQL操作,一般情況下將數據庫和連接字符集都置為utf8是較好的選擇;
• 使用mysql CAPI(mysql提供C語言操作的API)時,初始化數據庫句柄後馬上用mysql_options設定 MYSQL_SET_CHARSET_NAME屬性為utf8,這樣就不用顯式地用SET NAMES語句指定連接字符集,且用mysql_ping重連斷開的長連接時也會把連接字符集重置為utf8;
• 對於mysql PHP API,一般頁面級的PHP程序總運行時間較短,在連接到數據庫以後顯式用SET NAMES語句設置一次連接字符集即可;但當使用長連接時,請注意保持連接通暢並在斷開重連後用SET NAMES語句顯式重置連接字 符集。
其他注意事項
• my.cnf中的default_character_set設置只影響mysql命令連接服務器時的連接字符集,不會對使用libmysqlclient庫的應用程序產生任何作用!
• 對字段進行的SQL函數操作通常都是以內部操作字符集進行的,不受連接字符集設置的影響。
• SQL語句中的裸字符串會受到連接字符集或introducer設置的影響,對於比較之類的操作可能產生完全不同的結果,需要小心!
總結
根據上面的分析和建議,我們解決我們遇到問題應該使用什麼方法大家心裡應該比較清楚了。對,就是在創建database的時候指定字符集,不要去通過修改默 認配置來達到目的,當然你也可以采用指定表的字符集的形式,但很容易出現遺漏,特別是在很多人都參與設計的時候,更容易纰漏。
因此,使用什麼數據庫版本,不管是3.x,還是4.0.x還是4.1.x,其實對我們來說不重要,重要的有兩點
1.正確的設定數據庫編碼。MySQL4.0以下版本的字符集總是默認ISO8859-1,MySQL4.1在安裝的時候會讓你選擇。如果你准備使用UTF- 8,那麼在創建數據庫的時候就要指定好UTF-8(創建好以後也可以改,4.1以上版本還可以單獨指定表的字符集)
2.正確的設定數據庫connection編碼。設置好數據庫的編碼後,在連接數據庫時候,應該指定connection的編碼,比如使用jdbc連接時,指定連接為utf8方式。