深刻Mysql字符集設置 圖文版。本站提示廣大學習愛好者：（深刻Mysql字符集設置 圖文版）文章只能為提供參考，不一定能成為您想要的結果。以下是深刻Mysql字符集設置 圖文版正文
在mysql客戶端與mysql辦事端之間，存在著一個字符集轉換器。
character_set_client =>gbk：轉換器就曉得客戶端發送過去的是gbk格局的編碼
character_set_connection=>gbk：將客戶端傳送過去的數據轉換成gbk格局
character_set_results =>gbk:
注：以上三個字符集可使用set names gbk來同一停止設置
例子:
create table test(
name varchar(64) NOT NULL
)charset utf8;#這裡的utf8表現辦事器真個字符編碼
起首，往數據表test中拔出一條數據
inert into test values('測試');
則，數據“測試”在數據庫中是以“utf8”格局保留的
進程：
起首，經由過程mysql客戶端，將數據發送給Mysql辦事器，經由字符集轉換器的時刻，因為character_set_connection 值為gbk，所以會將客戶端發送過去的數據轉為gbk格局，緊接著，字符集轉換器將數據要傳送給辦事器的時刻，發明辦事器是以utf8保留數據的，所以，在其外部會主動將數據由gbk轉換成utf8格局
甚麼時刻會湧現亂碼？
經由過程 header('Content-type:text/html;charset=utf8');將客戶真個數據轉成utf8格局的，在數據經由“字符集轉換器”的時刻，因為character_set_client=gbk，而character_set_connection也等於gbk，所以從客戶端傳送過去的數據（實際上是utf8格局）其實不會被轉換格局。
然則，字符集轉換器在講數據發送給辦事器的時刻，發明辦事器要的格局是utf8，所以會將以後數 據當作gbk格局來處置，從而轉成utf8（然則，這一步其實曾經錯了。。。）。
2. result與客戶端頁面不相符的時刻
將前往成果的格局設置為utf8，然則客戶端接收的格局為gbk，是以會湧現亂碼
經由過程show character set 語法，可以顯示一切可用的字符集
latin字符集
留意：Maxlen列顯示用於存儲一個字符的最年夜的字節數量。
utf8字符集
gbk字符集
甚麼時刻會喪失數據？
比較以上三幅圖可以曉得，每種字符集中，用於存儲一個字符的最年夜的字節數量都分歧，utf8最年夜，latin最小。所以在經由字符集轉換器的時刻，假如處置欠妥，會形成數據喪失，並且是沒法挽回的。
好比：
將character_set_connection的值改成lantin的時刻
從客戶端發送過去的gbk數據，會被轉成lantin1格局，由於gbk格局的數據占用的字符數較多，從而會形成數據喪失
總結：
character_set_client和character_set_results 普通情形下要分歧，由於一個表現客戶端發送的數據格局，另外一個表現客戶端接收的數據格局為了不形成數據喪失，需讓 character_set_connection的字符編碼 年夜於 character_set_client的字符編碼
