MySQL字符集 GBK、GB2312、UTF8區(qū)別 解決MYSQL中文亂碼問題
更新時(shí)間:2012年08月27日 21:17:11 作者:
MYSQL中文亂碼問題原因有很多,腳本之家以前發(fā)布過很多相關(guān)文章,這篇文章介紹mysql相關(guān)的一些知識更詳細(xì)
MySQL中涉及的幾個(gè)字符集
character-set-server/default-character-set:服務(wù)器字符集,默認(rèn)情況下所采用的。
character-set-database:數(shù)據(jù)庫字符集。
character-set-table:數(shù)據(jù)庫表字符集。
優(yōu)先級依次增加。所以一般情況下只需要設(shè)置character-set-server,而在創(chuàng)建數(shù)據(jù)庫和表時(shí)不特別指定字符集,這樣統(tǒng)一采用character-set-server字符集。
character-set-client:客戶端的字符集??蛻舳四J(rèn)字符集。當(dāng)客戶端向服務(wù)器發(fā)送請求時(shí),請求以該字符集進(jìn)行編碼。
character-set-results:結(jié)果字符集。服務(wù)器向客戶端返回結(jié)果或者信息時(shí),結(jié)果以該字符集進(jìn)行編碼。
在客戶端,如果沒有定義character-set-results,則采用character-set-client字符集作為默認(rèn)的字符集。所以只需要設(shè)置character-set-client字符集。
要處理中文,則可以將character-set-server和character-set-client均設(shè)置為GB2312,如果要同時(shí)處理多國語言,則設(shè)置為UTF8。
關(guān)于MySQL的中文問題
解決亂碼的方法是,在執(zhí)行SQL語句之前,將MySQL以下三個(gè)系統(tǒng)參數(shù)設(shè)置為與服務(wù)器字符集character-set-server相同的字符集。
character_set_client:客戶端的字符集。
character_set_results:結(jié)果字符集。
character_set_connection:連接字符集。
設(shè)置這三個(gè)系統(tǒng)參數(shù)通過向MySQL發(fā)送語句:set names gb2312
關(guān)于GBK、GB2312、UTF8
UTF-8:Unicode Transformation Format-8bit,允許含BOM,但通常不含BOM。是用以解決國際上字符的一種多字節(jié)編碼,它對英文使用8位(即一個(gè)字節(jié)),中文使用24為(三個(gè)字節(jié))來編碼。UTF-8包含全世界所有國家需要用到的字符,是國際編碼,通用性強(qiáng)。UTF-8編碼的文字可以在各國支持UTF8字符集的瀏覽器上顯示。如,如果是UTF8編碼,則在外國人的英文IE上也能顯示中文,他們無需下載IE的中文語言支持包。
GBK是國家標(biāo)準(zhǔn)GB2312基礎(chǔ)上擴(kuò)容后兼容GB2312的標(biāo)準(zhǔn)。GBK的文字編碼是用雙字節(jié)來表示的,即不論中、英文字符均使用雙字節(jié)來表示,為了區(qū)分中文,將其最高位都設(shè)定成1。GBK包含全部中文字符,是國家編碼,通用性比UTF8差,不過UTF8占用的數(shù)據(jù)庫比GBD大。
GBK、GB2312等與UTF8之間都必須通過Unicode編碼才能相互轉(zhuǎn)換:
GBK、GB2312--Unicode--UTF8
UTF8--Unicode--GBK、GB2312
對于一個(gè)網(wǎng)站、論壇來說,如果英文字符較多,則建議使用UTF-8節(jié)省空間。不過現(xiàn)在很多論壇的插件一般只支持GBK。
GB2312是GBK的子集,GBK是GB18030的子集
GBK是包括中日韓字符的大字符集合
如果是中文的網(wǎng)站 推薦GB2312 GBK有時(shí)還是有點(diǎn)問題
為了避免所有亂碼問題,應(yīng)該采用UTF-8,將來要支持國際化也非常方便
UTF-8可以看作是大字符集,它包含了大部分文字的編碼。
使用UTF-8的一個(gè)好處是其他地區(qū)的用戶(如香港臺灣)無需安裝簡體中文支持就能正常觀看你的文字而不會出現(xiàn)亂碼。
gb2312是簡體中文的碼
gbk支持簡體中文及繁體中文
big5支持繁體中文
utf-8支持幾乎所有字符
首先分析亂碼的情況
1.寫入數(shù)據(jù)庫時(shí)作為亂碼寫入
2.查詢結(jié)果以亂碼返回
究竟在發(fā)生亂碼時(shí)是哪一種情況呢?
我們先在mysql 命令行下輸入
show variables like '%char%';
查看mysql 字符集設(shè)置情況:
mysql> show variables like '%char%';
+--------------------------+----------------------------------------+
| Variable_name | Value |
+--------------------------+----------------------------------------+
| character_set_client | gbk |
| character_set_connection | gbk |
| character_set_database | gbk |
| character_set_filesystem | binary |
| character_set_results | gbk |
| character_set_server | gbk |
| character_set_system | utf8 |
| character_sets_dir | /usr/local/mysql/share/mysql/charsets/ |
+--------------------------+----------------------------------------+
在查詢結(jié)果中可以看到mysql 數(shù)據(jù)庫系統(tǒng)中客戶端、數(shù)據(jù)庫連接、數(shù)據(jù)庫、文件系統(tǒng)、查詢
結(jié)果、服務(wù)器、系統(tǒng)的字符集設(shè)置
在這里,文件系統(tǒng)字符集是固定的,系統(tǒng)、服務(wù)器的字符集在安裝時(shí)確定,與亂碼問題無關(guān)
亂碼的問題與客戶端、數(shù)據(jù)庫連接、數(shù)據(jù)庫、查詢結(jié)果的字符集設(shè)置有關(guān)
*注:客戶端是看訪問mysql 數(shù)據(jù)庫的方式,通過命令行訪問,命令行窗口就是客戶端,通
過JDBC 等連接訪問,程序就是客戶端
我們在向mysql 寫入中文數(shù)據(jù)時(shí),在客戶端、數(shù)據(jù)庫連接、寫入數(shù)據(jù)庫時(shí)分別要進(jìn)行編碼轉(zhuǎn)
換
在執(zhí)行查詢時(shí),在返回結(jié)果、數(shù)據(jù)庫連接、客戶端分別進(jìn)行編碼轉(zhuǎn)換
現(xiàn)在我們應(yīng)該清楚,亂碼發(fā)生在數(shù)據(jù)庫、客戶端、查詢結(jié)果以及數(shù)據(jù)庫連接這其中一個(gè)或多
個(gè)環(huán)節(jié)
接下來我們來解決這個(gè)問題
在登錄數(shù)據(jù)庫時(shí),我們用mysql --default-character-set=字符集-u root -p 進(jìn)行連接,這時(shí)我們
再用show variables like '%char%';命令查看字符集設(shè)置情況,可以發(fā)現(xiàn)客戶端、數(shù)據(jù)庫連接、
查詢結(jié)果的字符集已經(jīng)設(shè)置成登錄時(shí)選擇的字符集了
如果是已經(jīng)登錄了,可以使用set names 字符集;命令來實(shí)現(xiàn)上述效果,等同于下面的命令:
set character_set_client = 字符集
set character_set_connection = 字符集
set character_set_results = 字符集
如果是通過JDBC 連接數(shù)據(jù)庫,可以這樣寫URL:
URL=jdbc:mysql://localhost:3306/abs?useUnicode=true&characterEncoding=字符集
JSP 頁面等終端也要設(shè)置相應(yīng)的字符集
數(shù)據(jù)庫的字符集可以修改mysql 的啟動配置來指定字符集,也可以在create database 時(shí)加上
default character set 字符集來強(qiáng)制設(shè)置database 的字符集
通過這樣的設(shè)置,整個(gè)數(shù)據(jù)寫入讀出流程中都統(tǒng)一了字符集,就不會出現(xiàn)亂碼了
為什么從命令行直接寫入中文不設(shè)置也不會出現(xiàn)亂碼?
可以明確的是從命令行下,客戶端、數(shù)據(jù)庫連接、查詢結(jié)果的字符集設(shè)置沒有變化
輸入的中文經(jīng)過一系列轉(zhuǎn)碼又轉(zhuǎn)回初始的字符集,我們查看到的當(dāng)然不是亂碼
但這并不代表中文在數(shù)據(jù)庫里被正確作為中文字符存儲
舉例來說,現(xiàn)在有一個(gè)utf8 編碼數(shù)據(jù)庫,客戶端連接使用GBK 編碼,connection 使用默認(rèn)
的ISO8859-1(也就是mysql 中的latin1),我們在客戶端發(fā)送“中文”這個(gè)字符串,客戶端
將發(fā)送一串GBK 格式的二進(jìn)制碼給connection 層,connection 層以ISO8859-1 格式將這段
二進(jìn)制碼發(fā)送給數(shù)據(jù)庫,數(shù)據(jù)庫將這段編碼以utf8 格式存儲下來,我們將這個(gè)字段以utf8
格式讀取出來,肯定是得到亂碼,也就是說中文數(shù)據(jù)在寫入數(shù)據(jù)庫時(shí)是以亂碼形式存儲的,
在同一個(gè)客戶端進(jìn)行查詢操作時(shí),做了一套和寫入時(shí)相反的操作,錯(cuò)誤的utf8 格式二進(jìn)制
碼又被轉(zhuǎn)換成正確的GBK 碼并正確顯示出來。
character-set-server/default-character-set:服務(wù)器字符集,默認(rèn)情況下所采用的。
character-set-database:數(shù)據(jù)庫字符集。
character-set-table:數(shù)據(jù)庫表字符集。
優(yōu)先級依次增加。所以一般情況下只需要設(shè)置character-set-server,而在創(chuàng)建數(shù)據(jù)庫和表時(shí)不特別指定字符集,這樣統(tǒng)一采用character-set-server字符集。
character-set-client:客戶端的字符集??蛻舳四J(rèn)字符集。當(dāng)客戶端向服務(wù)器發(fā)送請求時(shí),請求以該字符集進(jìn)行編碼。
character-set-results:結(jié)果字符集。服務(wù)器向客戶端返回結(jié)果或者信息時(shí),結(jié)果以該字符集進(jìn)行編碼。
在客戶端,如果沒有定義character-set-results,則采用character-set-client字符集作為默認(rèn)的字符集。所以只需要設(shè)置character-set-client字符集。
要處理中文,則可以將character-set-server和character-set-client均設(shè)置為GB2312,如果要同時(shí)處理多國語言,則設(shè)置為UTF8。
關(guān)于MySQL的中文問題
解決亂碼的方法是,在執(zhí)行SQL語句之前,將MySQL以下三個(gè)系統(tǒng)參數(shù)設(shè)置為與服務(wù)器字符集character-set-server相同的字符集。
character_set_client:客戶端的字符集。
character_set_results:結(jié)果字符集。
character_set_connection:連接字符集。
設(shè)置這三個(gè)系統(tǒng)參數(shù)通過向MySQL發(fā)送語句:set names gb2312
關(guān)于GBK、GB2312、UTF8
UTF-8:Unicode Transformation Format-8bit,允許含BOM,但通常不含BOM。是用以解決國際上字符的一種多字節(jié)編碼,它對英文使用8位(即一個(gè)字節(jié)),中文使用24為(三個(gè)字節(jié))來編碼。UTF-8包含全世界所有國家需要用到的字符,是國際編碼,通用性強(qiáng)。UTF-8編碼的文字可以在各國支持UTF8字符集的瀏覽器上顯示。如,如果是UTF8編碼,則在外國人的英文IE上也能顯示中文,他們無需下載IE的中文語言支持包。
GBK是國家標(biāo)準(zhǔn)GB2312基礎(chǔ)上擴(kuò)容后兼容GB2312的標(biāo)準(zhǔn)。GBK的文字編碼是用雙字節(jié)來表示的,即不論中、英文字符均使用雙字節(jié)來表示,為了區(qū)分中文,將其最高位都設(shè)定成1。GBK包含全部中文字符,是國家編碼,通用性比UTF8差,不過UTF8占用的數(shù)據(jù)庫比GBD大。
GBK、GB2312等與UTF8之間都必須通過Unicode編碼才能相互轉(zhuǎn)換:
GBK、GB2312--Unicode--UTF8
UTF8--Unicode--GBK、GB2312
對于一個(gè)網(wǎng)站、論壇來說,如果英文字符較多,則建議使用UTF-8節(jié)省空間。不過現(xiàn)在很多論壇的插件一般只支持GBK。
GB2312是GBK的子集,GBK是GB18030的子集
GBK是包括中日韓字符的大字符集合
如果是中文的網(wǎng)站 推薦GB2312 GBK有時(shí)還是有點(diǎn)問題
為了避免所有亂碼問題,應(yīng)該采用UTF-8,將來要支持國際化也非常方便
UTF-8可以看作是大字符集,它包含了大部分文字的編碼。
使用UTF-8的一個(gè)好處是其他地區(qū)的用戶(如香港臺灣)無需安裝簡體中文支持就能正常觀看你的文字而不會出現(xiàn)亂碼。
gb2312是簡體中文的碼
gbk支持簡體中文及繁體中文
big5支持繁體中文
utf-8支持幾乎所有字符
首先分析亂碼的情況
1.寫入數(shù)據(jù)庫時(shí)作為亂碼寫入
2.查詢結(jié)果以亂碼返回
究竟在發(fā)生亂碼時(shí)是哪一種情況呢?
我們先在mysql 命令行下輸入
show variables like '%char%';
查看mysql 字符集設(shè)置情況:
mysql> show variables like '%char%';
+--------------------------+----------------------------------------+
| Variable_name | Value |
+--------------------------+----------------------------------------+
| character_set_client | gbk |
| character_set_connection | gbk |
| character_set_database | gbk |
| character_set_filesystem | binary |
| character_set_results | gbk |
| character_set_server | gbk |
| character_set_system | utf8 |
| character_sets_dir | /usr/local/mysql/share/mysql/charsets/ |
+--------------------------+----------------------------------------+
在查詢結(jié)果中可以看到mysql 數(shù)據(jù)庫系統(tǒng)中客戶端、數(shù)據(jù)庫連接、數(shù)據(jù)庫、文件系統(tǒng)、查詢
結(jié)果、服務(wù)器、系統(tǒng)的字符集設(shè)置
在這里,文件系統(tǒng)字符集是固定的,系統(tǒng)、服務(wù)器的字符集在安裝時(shí)確定,與亂碼問題無關(guān)
亂碼的問題與客戶端、數(shù)據(jù)庫連接、數(shù)據(jù)庫、查詢結(jié)果的字符集設(shè)置有關(guān)
*注:客戶端是看訪問mysql 數(shù)據(jù)庫的方式,通過命令行訪問,命令行窗口就是客戶端,通
過JDBC 等連接訪問,程序就是客戶端
我們在向mysql 寫入中文數(shù)據(jù)時(shí),在客戶端、數(shù)據(jù)庫連接、寫入數(shù)據(jù)庫時(shí)分別要進(jìn)行編碼轉(zhuǎn)
換
在執(zhí)行查詢時(shí),在返回結(jié)果、數(shù)據(jù)庫連接、客戶端分別進(jìn)行編碼轉(zhuǎn)換
現(xiàn)在我們應(yīng)該清楚,亂碼發(fā)生在數(shù)據(jù)庫、客戶端、查詢結(jié)果以及數(shù)據(jù)庫連接這其中一個(gè)或多
個(gè)環(huán)節(jié)
接下來我們來解決這個(gè)問題
在登錄數(shù)據(jù)庫時(shí),我們用mysql --default-character-set=字符集-u root -p 進(jìn)行連接,這時(shí)我們
再用show variables like '%char%';命令查看字符集設(shè)置情況,可以發(fā)現(xiàn)客戶端、數(shù)據(jù)庫連接、
查詢結(jié)果的字符集已經(jīng)設(shè)置成登錄時(shí)選擇的字符集了
如果是已經(jīng)登錄了,可以使用set names 字符集;命令來實(shí)現(xiàn)上述效果,等同于下面的命令:
set character_set_client = 字符集
set character_set_connection = 字符集
set character_set_results = 字符集
如果是通過JDBC 連接數(shù)據(jù)庫,可以這樣寫URL:
URL=jdbc:mysql://localhost:3306/abs?useUnicode=true&characterEncoding=字符集
JSP 頁面等終端也要設(shè)置相應(yīng)的字符集
數(shù)據(jù)庫的字符集可以修改mysql 的啟動配置來指定字符集,也可以在create database 時(shí)加上
default character set 字符集來強(qiáng)制設(shè)置database 的字符集
通過這樣的設(shè)置,整個(gè)數(shù)據(jù)寫入讀出流程中都統(tǒng)一了字符集,就不會出現(xiàn)亂碼了
為什么從命令行直接寫入中文不設(shè)置也不會出現(xiàn)亂碼?
可以明確的是從命令行下,客戶端、數(shù)據(jù)庫連接、查詢結(jié)果的字符集設(shè)置沒有變化
輸入的中文經(jīng)過一系列轉(zhuǎn)碼又轉(zhuǎn)回初始的字符集,我們查看到的當(dāng)然不是亂碼
但這并不代表中文在數(shù)據(jù)庫里被正確作為中文字符存儲
舉例來說,現(xiàn)在有一個(gè)utf8 編碼數(shù)據(jù)庫,客戶端連接使用GBK 編碼,connection 使用默認(rèn)
的ISO8859-1(也就是mysql 中的latin1),我們在客戶端發(fā)送“中文”這個(gè)字符串,客戶端
將發(fā)送一串GBK 格式的二進(jìn)制碼給connection 層,connection 層以ISO8859-1 格式將這段
二進(jìn)制碼發(fā)送給數(shù)據(jù)庫,數(shù)據(jù)庫將這段編碼以utf8 格式存儲下來,我們將這個(gè)字段以utf8
格式讀取出來,肯定是得到亂碼,也就是說中文數(shù)據(jù)在寫入數(shù)據(jù)庫時(shí)是以亂碼形式存儲的,
在同一個(gè)客戶端進(jìn)行查詢操作時(shí),做了一套和寫入時(shí)相反的操作,錯(cuò)誤的utf8 格式二進(jìn)制
碼又被轉(zhuǎn)換成正確的GBK 碼并正確顯示出來。
相關(guān)文章
Mysql根據(jù)一個(gè)表的數(shù)據(jù)更新另一個(gè)表數(shù)據(jù)的SQL寫法(三種寫法)
這篇文章主要介紹了Mysql根據(jù)一個(gè)表的數(shù)據(jù)更新另一個(gè)表數(shù)據(jù)的SQL寫法,本文給大家分享三種解決方法,需要的朋友可以參考下2023-06-06為什么Mysql?數(shù)據(jù)庫表中有索引還是查詢慢
這篇文章主要介紹了為什么Mysql數(shù)據(jù)庫表中有索引還是查詢慢,以?user_info?這張表來作為分析的基礎(chǔ),在?user_info?這張表上,我們分別創(chuàng)建了idx_name以及idx_phone?二級索引以及?idx_age_address?聯(lián)合索引展開詳細(xì)內(nèi)容,需要的小伙伴可以參考一下2022-05-05CentOS下將MySQL 5.1升級到MySQL 5.5的步驟
這篇文章主要介紹了CentOS下將MySQL 5.1升級到MySQL 5.5的步驟,需要的朋友可以參考下2015-08-08Win7、WinXP下MySql安裝出錯(cuò)完全卸載的方法步驟
這篇文章主要介紹了Win7、WinXP下MySql安裝出錯(cuò)完全卸載的方法步驟,本文給出詳細(xì)的操作步驟,按本文方法清理后,重新安裝,應(yīng)該就不會有錯(cuò)誤了,需要的朋友可以參考下2015-06-06zabbix監(jiān)控MySQL主從狀態(tài)的方法詳解
這篇文章主要介紹了zabbix--監(jiān)控MySQL主從狀態(tài)的方法,本文圖文并茂給大家介紹的非常詳細(xì),具有一定的參考借鑒價(jià)值 ,需要的朋友可以參考下2019-06-06