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

全國咨詢/投訴熱線：400-618-4000

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

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

查看數(shù)據(jù)庫編碼：
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   
說明：修改鏈接字符集和校對規(guī)則，它會同時設(shè)置character_set_client, character_set_connection, character_set_results
也可以修改
[mysqld]
default-character-set=utf8
說明：這里修改的是服務(wù)器的字符集和校對規(guī)則。
查看當前服務(wù)器的字符集和校對規(guī)則：
mysql>show variables like 'character_set_server';  
mysql>show variables like 'collation_server';
2. 修改數(shù)據(jù)庫和表的字符集和校隊規(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

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

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

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

作者：傳智播客人工智能+Python學院
0 分享到：
和我們在線交談！