首頁Python+大數據技術文章正文

MySQL字符集亂碼總結

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

查看數據庫編碼：

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ī)則，它會同時設置character_set_client, character_set_connection, character_set_results

也可以修改

[mysqld]

default-character-set=utf8

說明：這里修改的是服務器的字符集和校對規(guī)則。

查看當前服務器的字符集和校對規(guī)則：

mysql>show variables like 'character_set_server';

mysql>show variables like 'collation_server';

2. 修改數據庫和表的字符集和校隊規(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

查看當前數據庫的字符集和校對規(guī)則：

mysql>show variables like 'character_set_database';

mysql>show variables like 'collation_database';

查看表的字符集和校對規(guī)則：

mysql>show create table HR_ROLE \G;

MySQL字符集終極解決方案

開源數據庫MySQL從來都是中小企業(yè)構建web應用的首選，特別是和PHP配合簡直就是一對黃金搭檔，深受web開發(fā)人員的喜愛。但自從4.1以來MySQL加入了多字符集的支持，很多MySQL使用者發(fā)現(xiàn)中文居然不能使用了，顯示變成了一堆亂碼！以致于很多人還在使用3.24.58的老版本，最近上MySQL網站，發(fā)現(xiàn)居然不提供3.24版本的下載了，MySQL已經徹底放棄3.24版本了。好在我還留有一份windows版的copy，就當作紀念吧。

怎么會產生亂碼現(xiàn)象的，怎么解決？只要翻下網上的解決方案，馬上就可以得出答案：“在獲得連接之后執(zhí)行一句set names 'gb2312'”，但這樣做的原因是什么呢？總結一下我的經驗。

MySQL處理連接時，外部連接發(fā)送過來的SQL請求會根據以下順序進行轉換：

character_set_client //客戶連接所采用的字符集

character_set_connection //MySQL連接字符集

character_set_database //數據庫所采用的字符集（表，列）

character_set_results //客戶機顯示所采用的字符集

一. 產生亂碼的根本原因在于：

1.客戶機沒有正確地設置client字符集，導致原先的SQL語句被轉換成connection所指字符集，而這種轉換，是會丟失信息的，如果client是utf8格式，那么如果轉換成gb2312格式，這其中必定會丟失信息，反之則不會丟失。一定要保證connection的字符集大于client字符集才能保證轉換不丟失信息。

2. 數據庫字體沒有設置正確，如果數據庫字體設置不正確，那么connection字符集轉換成database字符集照樣丟失編碼，原因跟上面一樣。

二.為什么set names 'gb2312'就可以了呢

setnames 'gb2312'相當于這三條語句:

setcharacter_set_client = gb2312;

setcharacter_set_connection = gb2312;

setcharacter_set_results = gb2312;

這樣做的話，上述產生亂碼的原因1就不存在了，因為編碼格式都統(tǒng)一了，但是這樣做并不是萬金油。原因有：

1.你的client不一定是用gb2312編碼發(fā)送SQL的，如果編碼不是gb2312那么轉換成gb2312就會產生問題。

2.你的數據庫中的表不一定是gb2312格式，如果不是gb2312格式而是其他的比如說latin1，那么在存儲字符集的時候就會產生信息丟失。

綜上，終極解決方案如下:

1.首先要明確你的客戶端時候何種編碼格式，這是最重要的（IE6一般用utf8，命令行一般是gbk，一般程序是gb2312)

2.確保你的數據庫使用utf8格式，很簡單，所有編碼通吃。

3.一定要保證connection字符集大于等于client字符集，不然就會信息丟失，比如： latin1 < gb2312 <gbk < utf8，若設置set character_set_client = gb2312，那么至少connection的字符集要大于等于gb2312，否則就會丟失信息