mysql的字符集

Steven1981發表於2009-10-29

character_set_client , character_set_connection , character_set_results

中文亂

[@more@]

關於MYSQL的字符集,系統裡面有很多個變數設定,很多初學者都不太搞得清楚,包括我自己也是.
所以在這裡寫點東西,希望把這幾個東西的關係搞清楚.
MYSQL的字符集變數可以透過以下命令得到:


show variables like 'char%';
+--------------------------+----------------------------+
| Variable_name | Value |
+--------------------------+----------------------------+
| character_set_client | gbk |
| character_set_connection | gbk |
| character_set_database | utf8 |
| character_set_filesystem | binary |
| character_set_results | |
| character_set_server | utf8 |
| character_set_system | utf8 |
| character_sets_dir | /usr/share/mysql/charsets/ |
+--------------------------+----------------------------+
MYSQL的字符集變數其實可以分為兩類,
一類是關於建立OBJECTS時要用到的.
character_set_database
character_set_server
一類是在伺服器處理連線的時候要用到的.
character_set_client
character_set_connection
character_set_results
我們主要關注的是處理連線的字符集.
關注字符集問題,那你肯定是遇到了亂碼的問題. 其實解決亂碼問題在網上一搜一大堆.
如果能做到, 應用/MYSQL.CLENT/MYSQL.CONNETION/表/MYSQL.RESULT 的字符集一致,存取資料肯定沒有問題.

我在這裡把這三個連線字符集的關係理理.
經過多次的測試,我把MYSQL處理字元的過程主要歸納為:
例: WINDOWS客戶端CHARSET=GBK,輸入"中" , 透過WINDOWS.GBK轉碼為 $a = D6D0,
========================================================================================
# 伺服器收到CLIENT送來的值"D6D0", 並認為"D6D0"是$MYSQL.character_set_client 指定字符集的資料.
# 從 $MYSQL.character_set_client 轉化---&gt $MYSQL.character_set_connection (如果字符集一樣就不轉換)
if 轉換成功 ; then
$a = $MYSQL.character_set_client.code
else
$a = 3f (在這個環節不會報錯!)
fi

# 從 $MYSQL.character_set_connection 轉化---&gt $TABLES.character_set (如果字符集一樣也會檢查一次)
if 轉換成功 ; then
$a = $MYSQL.character_set_client.code , 並存入表
else
$a = 3f , 並報錯: Incorrect string value
$a = 20 ($MYSQL.character_set_connection = $TABLES.character_set 的情況)
fi

# 從資料庫取資料.
# 從 $TABLES.character_set --&gt $MYSQL.character_set_result
if 轉換成功 ; then
$a = $MYSQL.character_set_result.code , 正常顯示
else
$a = 3f/亂碼 , 顯示: ?或者亂碼
fi
========================================================================================
以下是我測試過程中記錄的各種情況及報錯資訊,以便大家分析:
(在這裡我特意用了SSHTERM的兩種字符集進行測試. 我們可以把它理解為應用.)

SSHTERMCHAR_clientCHAR_connectiontutf_dumptgbk_dumptlatin1_dumptutf_warningtgbk_warningtlatin1_warning
gbkutf8utf8203f3fIncorrect 'xD6xD0'
存入表UTF8轉UTF8,這個環節字符集一樣也轉換一次.但在源字符集中沒找到.返回"空"
Incorrect 'xD6xD0'
存入表,用UTF8轉GBK時報錯
Incorrect 'xD6xD0'
存入表,用UTF8轉LATIN1時報錯
 gbkgbke4b8add6d03f正常正常Incorrect 'xD6xD0'
存入表時用GBK轉LATIN1時報錯
D6D0latin1latin1c396c3903f3fd6d0正常:(存了UTF8的D6D0)
如果以LATIN1取還是"D6D0"
Incorrect 'xD6xD0'
LATIN1轉GBK報錯
正常
 gbkutf8e4b8add6d03f正常正常Incorrect xE4xB8xAD
存入表,用UTF8轉LATIN1時報錯
 utf8gbk3f3f3fCLIENT向CONN轉換時已經丟了資料成3F,這中間的轉換不會報錯
         
utf8gbkgbke6b693e4b83fData truncated
"E4B8AD"只取了_GBK "E4B8"
Incorrect 'xAD
"E4B8AD"被兩分了兩段,而AD沒能轉換成功.
Incorrect 'xE4xB8xAD'
      在CONN向錶轉換的時候,上面兩個的處理結果為什麼不一樣呢? 
 utf8utf8e4b8add6d03f正常正常Incorrect xE4xB8xAD
E4B8ADgbkutf8e6b693e4b83fCLENT轉CONN資料被擷取,
但這樣的處理不會報錯.
CLENT轉CONN資料被擷取,
但這樣的處理不會報錯.
Incorrect 'xE6xB6x93'
 utf8gbke4b8add6d03f正常正常Incorrect 'xD6xD0'
 latin1latin1c3a4c2b8c2ad3f3f3fe4b8ad理論上這是"E4B8AD"UTF8的CODE,但又有點不像xE4xB8xAD
LATIN1向GBK轉不成功
正常
上表中,只要DUMP結果為e4b8ad/d6d0,說明資料儲存都是正常的.而且可以正常讀取.
DUMP結果為c396c390的情況比較特殊.讀者稍加分析應該還是能明白的.(其實就是原存原取).

相關命令:
========= ========= ========= ========= ========= ========= ========= =========
建立測試表:
create table tutf (name char(10)) engine=myisam default character set=utf8 ;
create table tgbk (name char(10)) engine=myisam default character set=gbk ;
create table tlat (name char(10)) engine=myisam default character set=latin1 ;
設定相關字符集:
set character_set_client=gbk ;
set character_set_connection=utf8;
set character_set_results=latin1;

插入並DUMP資料:
truncate table tutf;truncate table tgbk;truncate table tlat;
insert into tutf values ('中'); show warnings ;
insert into tgbk values ('中'); show warnings ;
insert into tlat values ('中'); show warnings ;
system hexdump /home/mysql/data/test/tutf.MYD ;
system hexdump /home/mysql/data/test/tgbk.MYD ;
system hexdump /home/mysql/data/test/tlat.MYD ;
========= ========= ========= ========= ========= ========= ========= =========
相關資料:
============================
中文: 中
GBK編碼 : D6D0
UTF8編碼: E4B8AD
============================

來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/703656/viewspace-1028279/,如需轉載,請註明出處,否則將追究法律責任。

相關文章