MYSQL的字符集是怎樣的

137次閱讀

共計 3773 個字符，預計需要花費 10 分鐘才能閱讀完成。

MYSQL 的字符集是怎樣的，很多新手對此不是很清楚，為了幫助大家解決這個難題，下面丸趣 TV 小編將為大家詳細講解，有這方面需求的人可以來學習下，希望你能有所收獲。

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

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_warninggbkutf8utf8203f3fIncorrect 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 xE4xB8xADE4B8ADgbkutf8e6b693e4b83fCLENT 轉 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 ;

看完上述內容是否對您有幫助呢？如果還想對相關知識有進一步的了解或閱讀更多相關文章，請關注丸趣 TV 行業資訊頻道，感謝您對丸趣 TV 的支持。

正文完