深入Mysql字符集設(shè)置，深入mysql字符集

在mysql客戶端與mysql服務(wù)端之間，存在著一個字符集轉(zhuǎn)換器。 ? character_set_client ? ? ? ? ?=>gbk：轉(zhuǎn)換器就知道客戶端發(fā)送過來的是gbk格式的編碼 character_set_connection=>gbk：將客戶端傳送過來的數(shù)據(jù)轉(zhuǎn)換成gbk格式 character_set_results????????=>gbk: ? 注：以上三個字符集可以使用set names gbk來統(tǒng)一進(jìn)行設(shè)置 例子: create table test( name varchar(64) NOT NULL )charset utf8;#這里的utf8表示服務(wù)器端的字符編碼 ? 首先，往數(shù)據(jù)表test中插入一條數(shù)據(jù) inert into test values('測試'); 則，數(shù)據(jù)“測試”在數(shù)據(jù)庫中是以“utf8”格式保存的 過程：

? 首先，通過mysql客戶端，將數(shù)據(jù)發(fā)送給Mysql服務(wù)器，經(jīng)過字符集轉(zhuǎn)換器的時候，由于character_set_connection 值為gbk，所以會將客戶端發(fā)送過來的數(shù)據(jù)轉(zhuǎn)為gbk格式，緊接著，字符集轉(zhuǎn)換器將數(shù)據(jù)要傳送給服務(wù)器的時候，發(fā)現(xiàn)服務(wù)器是以utf8保存數(shù)據(jù)的，所以，在其內(nèi)部會自動將數(shù)據(jù)由gbk轉(zhuǎn)換成utf8格式 ? ? 什么時候會出現(xiàn)亂碼？ ? ? ? ? 通過?header('Content-type:text/html;charset=utf8');將客戶端的數(shù)據(jù)轉(zhuǎn)成utf8格式的，在數(shù)據(jù)經(jīng)過“字符集轉(zhuǎn)換器”的時候，由于character_set_client=gbk，而character_set_connection也等于gbk，所以從客戶端傳送過來的數(shù)據(jù)（其實是utf8格式）并不會被轉(zhuǎn)換格式。 ????????但是，字符集轉(zhuǎn)換器在講數(shù)據(jù)發(fā)送給服務(wù)器的時候，發(fā)現(xiàn)服務(wù)器要的格式是utf8，所以會將當(dāng)前數(shù) ? ? ? ? ?據(jù)當(dāng)做gbk格式來處理，從而轉(zhuǎn)成utf8（但是，這一步其實已經(jīng)錯了。。。）。 ????2.? result與客戶端頁面不符合的時候 ????? ??

?將返回結(jié)果的格式設(shè)置為utf8，但是客戶端接受的格式為gbk，因此會出現(xiàn)亂碼 ?

---

通過show character set 語法，可以顯示所有可用的字符集 latin字符集

注意：Maxlen列顯示用于存儲一個字符的最大的字節(jié)數(shù)目。 ? utf8字符集

? gbk字符集

? 什么時候會丟失數(shù)據(jù)？ 對比以上三幅圖可以知道，每種字符集中，用于存儲一個字符的最大的字節(jié)數(shù)目都不同，utf8最大，latin最小。所以在經(jīng)過字符集轉(zhuǎn)換器的時候，如果處理不當(dāng)，會造成數(shù)據(jù)丟失，而且是無法挽回的。 比如： 將character_set_connection的值改為lantin的時候

從客戶端發(fā)送過來的gbk數(shù)據(jù)，會被轉(zhuǎn)成lantin1格式，因為gbk格式的數(shù)據(jù)占用的字符數(shù)較多，從而會造成數(shù)據(jù)丟失 ?

總結(jié)：