教育行業(yè)A股IPO第一股（股票代碼 003032）

全國(guó)咨詢(xún)/投訴熱線(xiàn)：400-618-4000

MySQL字符集亂碼總結(jié)

更新時(shí)間:2018年07月20日17時(shí)34分 來(lái)源:傳智播客 瀏覽次數(shù):

查看數(shù)據(jù)庫(kù)編碼：
showcreate database db_name;
查看表編碼：
showcreate table tbl_name;
查看字段編碼：
showfull columns from tbl_name;
showfull fields from tbl_name;
MySql 端配置
1. 修改my.ini文件
[mysql]
default-character-set=utf8   
說(shuō)明：修改鏈接字符集和校對(duì)規(guī)則，它會(huì)同時(shí)設(shè)置character_set_client, character_set_connection, character_set_results
也可以修改
[mysqld]
default-character-set=utf8
說(shuō)明：這里修改的是服務(wù)器的字符集和校對(duì)規(guī)則。
查看當(dāng)前服務(wù)器的字符集和校對(duì)規(guī)則：
mysql>show variables like 'character_set_server';  
mysql>show variables like 'collation_server';
2. 修改數(shù)據(jù)庫(kù)和表的字符集和校隊(duì)規(guī)則。
例如：
--Create Database.
dropdatabase if exists HRDB;
createdatabase HRDB DEFAULT CHARACTER SET utf8; # CHARSET=utf8
useHRDB;

-- 角色表
createtable HR_ROLE (
IDbigint not null auto_increment,
NAMEvarchar(20) not null unique,
primarykey (ID)
)ENGINE=INNODB DEFAULT CHARACTER SET utf8;  # CHARSET=utf8

查看當(dāng)前數(shù)據(jù)庫(kù)的字符集和校對(duì)規(guī)則：
mysql>show variables like 'character_set_database';  
mysql>show variables like 'collation_database';

查看表的字符集和校對(duì)規(guī)則：
mysql>show create table HR_ROLE \G;

MySQL字符集終極解決方案
開(kāi)源數(shù)據(jù)庫(kù)MySQL從來(lái)都是中小企業(yè)構(gòu)建web應(yīng)用的首選，特別是和PHP配合簡(jiǎn)直就是一對(duì)黃金搭檔，深受web開(kāi)發(fā)人員的喜愛(ài)。但自從4.1以來(lái)MySQL加入了多字符集的支持，很多MySQL使用者發(fā)現(xiàn)中文居然不能使用了，顯示變成了一堆亂碼！以致于很多人還在使用3.24.58的老版本，最近上MySQL網(wǎng)站，發(fā)現(xiàn)居然不提供3.24版本的下載了，MySQL已經(jīng)徹底放棄3.24版本了。好在我還留有一份windows版的copy，就當(dāng)作紀(jì)念吧。
怎么會(huì)產(chǎn)生亂碼現(xiàn)象的，怎么解決？只要翻下網(wǎng)上的解決方案，馬上就可以得出答案：“在獲得連接之后執(zhí)行一句set names 'gb2312'”，但這樣做的原因是什么呢？總結(jié)一下我的經(jīng)驗(yàn)。
MySQL處理連接時(shí)，外部連接發(fā)送過(guò)來(lái)的SQL請(qǐng)求會(huì)根據(jù)以下順序進(jìn)行轉(zhuǎn)換：
character_set_client           //客戶(hù)連接所采用的字符集
|
character_set_connection  //MySQL連接字符集
|
character_set_database    //數(shù)據(jù)庫(kù)所采用的字符集（表，列）
|
character_set_results        //客戶(hù)機(jī)顯示所采用的字符集
一. 產(chǎn)生亂碼的根本原因在于：
1.客戶(hù)機(jī)沒(méi)有正確地設(shè)置client字符集，導(dǎo)致原先的SQL語(yǔ)句被轉(zhuǎn)換成connection所指字符集，而這種轉(zhuǎn)換，是會(huì)丟失信息的，如果client是utf8格式，那么如果轉(zhuǎn)換成gb2312格式，這其中必定會(huì)丟失信息，反之則不會(huì)丟失。一定要保證connection的字符集大于client字符集才能保證轉(zhuǎn)換不丟失信息。
2. 數(shù)據(jù)庫(kù)字體沒(méi)有設(shè)置正確，如果數(shù)據(jù)庫(kù)字體設(shè)置不正確，那么connection字符集轉(zhuǎn)換成database字符集照樣丟失編碼，原因跟上面一樣。
二.為什么set names 'gb2312'就可以了呢
setnames 'gb2312'相當(dāng)于這三條語(yǔ)句:
setcharacter_set_client = gb2312;
setcharacter_set_connection = gb2312;
setcharacter_set_results = gb2312;
這樣做的話(huà)，上述產(chǎn)生亂碼的原因1就不存在了，因?yàn)榫幋a格式都統(tǒng)一了，但是這樣做并不是萬(wàn)金油。原因有：
1.你的client不一定是用gb2312編碼發(fā)送SQL的，如果編碼不是gb2312那么轉(zhuǎn)換成gb2312就會(huì)產(chǎn)生問(wèn)題。
2.你的數(shù)據(jù)庫(kù)中的表不一定是gb2312格式，如果不是gb2312格式而是其他的比如說(shuō)latin1，那么在存儲(chǔ)字符集的時(shí)候就會(huì)產(chǎn)生信息丟失。
綜上，終極解決方案如下:
1.首先要明確你的客戶(hù)端時(shí)候何種編碼格式，這是最重要的（IE6一般用utf8，命令行一般是gbk，一般程序是gb2312)
2.確保你的數(shù)據(jù)庫(kù)使用utf8格式，很簡(jiǎn)單，所有編碼通吃。
3.一定要保證connection字符集大于等于client字符集，不然就會(huì)信息丟失，比如： latin1 < gb2312 <gbk < utf8，若設(shè)置set character_set_client = gb2312，那么至少connection的字符集要大于等于gb2312，否則就會(huì)丟失信息
4.以上三步做正確的話(huà)，那么所有中文都被正確地轉(zhuǎn)換成utf8格式存儲(chǔ)進(jìn)了數(shù)據(jù)庫(kù)，為了適應(yīng)不同的瀏覽器，不同的客戶(hù)端，你可以修改character_set_results來(lái)以不同的編碼顯示中文字體，由于utf8是大方向，因此web應(yīng)用是我還是傾向于使用utf8格式顯示中文的。

作者：傳智播客人工智能+Python學(xué)院
0 分享到：
和我們?cè)诰€(xiàn)交談！