MySQL字符集 GBK、GB2312、UTF8差別 處理MYSQL中文亂碼成績。本站提示廣大學習愛好者：（MySQL字符集 GBK、GB2312、UTF8差別 處理MYSQL中文亂碼成績）文章只能為提供參考，不一定能成為您想要的結果。以下是MySQL字符集 GBK、GB2312、UTF8差別 處理MYSQL中文亂碼成績正文
MySQL中觸及的幾個字符集
character-set-server/default-character-set：辦事器字符集，默許情形下所采取的。
character-set-database：數據庫字符集。
character-set-table：數據庫表字符集。
優先級順次增長。所以普通情形下只須要設置character-set-server，而在創立數據庫和表時不特殊指定字符集，如許同一采取character-set-server字符集。
character-set-client：客戶真個字符集。客戶端默許字符集。當客戶端向辦事器發送要求時，要求以該字符集停止編碼。
character-set-results：成果字符集。辦事器向客戶端前往成果或許信息時，成果以該字符集停止編碼。
在客戶端，假如沒有界說character-set-results，則采取character-set-client字符集作為默許的字符集。所以只須要設置character-set-client字符集。
要處置中文，則可以將character-set-server和character-set-client均設置為GB2312，假如要同時處置多國說話，則設置為UTF8。
關於MySQL的中文成績
處理亂碼的辦法是，在履行SQL語句之前，將MySQL以下三個體系參數設置為與辦事器字符集character-set-server雷同的字符集。
character_set_client：客戶真個字符集。
character_set_results：成果字符集。
character_set_connection：銜接字符集。
設置這三個體系參數經由過程向MySQL發送語句：set names gb2312
關於GBK、GB2312、UTF8
UTF-8：Unicode Transformation Format-8bit，許可含BOM，但平日不含BOM。是用以處理國際上字符的一種多字節編碼，它對英文應用8位（即一個字節），中文應用24為（三個字節）來編碼。UTF-8包括全球一切國度須要用到的字符，是國際編碼，通用性強。UTF-8編碼的文字可以在列國支撐UTF8字符集的閱讀器上顯示。如，假如是UTF8編碼，則在本國人的英文IE上也能顯示中文，他們無需下載IE的中文說話支撐包。
GBK是國度尺度GB2312基本上擴容後兼容GB2312的尺度。GBK的文字編碼是用雙字節來表現的，即豈論中、英文字符均應用雙字節來表現，為了辨別中文，將其最高位都設定成1。GBK包括全體中文字符，是國度編碼，通用性比UTF8差，不外UTF8占用的數據庫比GBD年夜。
GBK、GB2312等與UTF8之間都必需經由過程Unicode編碼能力互相轉換：
GBK、GB2312－－Unicode－－UTF8
UTF8－－Unicode－－GBK、GB2312
關於一個網站、服裝論壇t.vhao.net來講，假如英文字符較多，則建議應用UTF－8節儉空間。不外如今許多服裝論壇t.vhao.net的插件普通只支撐GBK。
GB2312是GBK的子集，GBK是GB18030的子集
GBK是包含中日韓字符的年夜字符聚集
假如是中文的網站 推舉GB2312 GBK有時照樣有點成績
為了不一切亂碼成績，應當采取UTF-8，未來要支撐國際化也異常便利
UTF-8可以看做是年夜字符集，它包括了年夜部門文字的編碼。
應用UTF-8的一個利益是其他地域的用戶（如噴鼻港台灣）無需裝置簡體中文支撐就可以正常不雅看你的文字而不會湧現亂碼。
gb2312是簡體中文的碼
gbk支撐簡體中文及繁體中文
big5支撐繁體中文
utf-8支撐簡直一切字符
起首剖析亂碼的情形
1.寫入數據庫時作為亂碼寫入
2.查詢成果以亂碼前往
畢竟在產生亂碼時是哪種情形呢？
我們先在mysql 敕令行下輸出
show variables like '%char%';
檢查mysql 字符集設置情形:
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/ |
+--------------------------+----------------------------------------+
在查詢成果中可以看到mysql 數據庫體系中客戶端、數據庫銜接、數據庫、文件體系、查詢
成果、辦事器、體系的字符集設置
在這裡，文件體系字符集是固定的，體系、辦事器的字符集在裝置時肯定，與亂碼成績有關
亂碼的成績與客戶端、數據庫銜接、數據庫、查詢成果的字符集設置有關
*注：客戶端是看拜訪mysql 數據庫的方法，經由過程敕令行拜訪，敕令行窗口就是客戶端，通
過JDBC 等銜接拜訪，法式就是客戶端
我們在向mysql 寫入中文數據時，在客戶端、數據庫銜接、寫入數據庫時分離要停止編碼轉
換
在履行查詢時，在前往成果、數據庫銜接、客戶端分離停止編碼轉換
如今我們應當清晰，亂碼產生在數據庫、客戶端、查詢成果和數據庫銜接這個中一個或多
個環節
接上去我們來處理這個成績
在登錄數據庫時，我們用mysql --default-character-set=字符集-u root -p 停止銜接，這時候我們
再用show variables like '%char%';敕令檢查字符集設置情形，可以發明客戶端、數據庫銜接、
查詢成果的字符集曾經設置成登錄時選擇的字符集了
假如是曾經登錄了，可使用set names 字符集;敕令來完成上述後果，同等於上面的敕令：
set character_set_client = 字符集
set character_set_connection = 字符集
set character_set_results = 字符集
假如是經由過程JDBC 銜接數據庫，可以如許寫URL：
URL=jdbc:mysql://localhost:3306/abs?useUnicode=true&characterEncoding=字符集
JSP 頁面等終端也要設置響應的字符集
數據庫的字符集可以修正mysql 的啟動設置裝備擺設來指定字符集，也能夠在create database 時加上
default character set 字符集來強迫設置database 的字符集
經由過程如許的設置，全部數據寫入讀出流程中都同一了字符集，就不會湧現亂碼了
為何從敕令行直接寫入中文不設置也不會湧現亂碼？
可以明白的是從敕令行下，客戶端、數據庫銜接、查詢成果的字符集設置沒有變更
輸出的中文經由一系列轉碼又轉回初始的字符集，我們檢查到確當然不是亂碼
但這其實不代表中文在數據庫裡被准確作為中文字符存儲
舉例來講，如今有一個utf8 編碼數據庫，客戶端銜接應用GBK 編碼，connection 應用默許
的ISO8859-1（也就是mysql 中的latin1），我們在客戶端發送“中文”這個字符串，客戶端
將發送一串GBK 格局的二進制碼給connection 層，connection 層以ISO8859-1 格局將這段
二進制碼發送給數據庫，數據庫將這段編碼以utf8 格局存儲上去，我們將這個字段以utf8
格局讀掏出來，確定是獲得亂碼，也就是說中文數據在寫入數據庫時是以亂碼情勢存儲的，
在統一個客戶端停止查詢操作時，做了一套和寫入時相反的操作，毛病的utf8 格局二進制
碼又被轉換成准確的GBK 碼並准確顯示出來。
