Mysql亂碼問題的原因與解決

MySQL對中文的支持程度還是很有限的，尤其是新手，一旦出現(xiàn)亂碼問題，就會頭大。下面介紹幾種亂碼問題的現(xiàn)象原因及解決方法，僅供參考。

亂碼問題1：用PHPmyAdmin操作MySQL數(shù)據(jù)庫時漢字顯示正常，但用PHP語言編寫的網(wǎng)頁顯示MySQL數(shù)據(jù)時所有漢字都變成了亂碼。

癥狀：用PHPmyAdmin輸入漢字正常，但當PHP網(wǎng)頁顯示MySQL數(shù)據(jù)時漢字就變成了?號，并且有多少個漢字就有多少個?號。

原因：沒有在PHP網(wǎng)頁中用代碼告訴MySQL該以什么字符集輸出漢字。

解決方法：

1.網(wǎng)頁文件head設置編碼

2.PHP頁面在保存的時候使用utf-8編碼保存，可以用記事本轉換，另存為…

3.在MySQL新建數(shù)據(jù)庫的時候，選擇UTF-8編碼，字符集設定為“utf-8_unicode_ci”(Unicode 多語言, 不區(qū)分大小寫)，庫里面數(shù)據(jù)表table的“整理”設置為“utf-8_general_ci”，數(shù)據(jù)表里面每個字段的“整理”都設置為“utf-8_general_ci”

4.在PHP連接數(shù)據(jù)庫的時候,也就是mysql_connect()之后加入

//設置數(shù)據(jù)的字符集utf-8

mysql_query("set names 'utf8' ");

mysql_query("set character_set_client=utf8");

mysql_query("set character_set_results=utf8");

注意是utf8,不是utf-8 。

如果你的網(wǎng)頁編碼是gb2312，那就是SET NAMES GB2312。但強烈推薦網(wǎng)頁編碼、MySQL數(shù)據(jù)表字符集、PHPmyAdmin都統(tǒng)一使用UTF-8。

以上四點即可實現(xiàn)全站utf-8編碼,而且在數(shù)據(jù)庫中也不會有中文亂碼。

亂碼問題2：用PHPmyAdmin輸入數(shù)據(jù)時發(fā)生錯誤，不讓輸入或出現(xiàn)亂碼

解決方法：這是設置問題。請安裝最新版PHPmyAdmin或Appserv，打開PHPmyAdmin，MySQL 字符集: UTF-8 Unicode (utf8)； MySQL 連接校對應該為utf8_unicode_ci；創(chuàng)建新的數(shù)據(jù)庫時整理一欄請也選成utf8_unicode_ci。網(wǎng)頁字符集也最好選用utf-8。utf-8是國際標準編碼，是趨勢。

亂碼問題3： 在本機開發(fā)好的MySQL數(shù)據(jù)表，在本機測試一切正常，但用網(wǎng)站空間商提供的PHPmyAdmin上傳時卻出現(xiàn)問題，上傳失敗。尤其是使用國外PHP空間。

解決方法：首先查看網(wǎng)站空間商提供的PHPmyAdmin字符集設定，確定自己所建數(shù)據(jù)表與服務商的是同一編碼。在國外MySQL是不支持gb2312的，甚至最新版的Apache也不支持gb2312。如果是因為編碼不統(tǒng)一，可以重建數(shù)據(jù)表，當然是用國際標準的UTF8。

MySQL中涉及的幾個字符集

character-set-server/default-character-set：服務器字符集，默認情況下所采用的。

character-set-database：數(shù)據(jù)庫字符集。

character-set-table：數(shù)據(jù)庫表字符集。

優(yōu)先級依次增加。所以一般情況下只需要設置character-set-server，而在創(chuàng)建數(shù)據(jù)庫和表時不特別指定字符集，這樣統(tǒng)一采用character-set-server字符集。

character-set-client：客戶端的字符集。客戶端默認字符集。當客戶端向服務器發(fā)送請求時，請求以該字符集進行編碼。

character-set-results：結果字符集。服務器向客戶端返回結果或者信息時，結果以該字符集進行編碼。

在客戶端，如果沒有定義character-set-results，則采用character-set-client字符集作為默認的字符集。所以只需要設置character-set-client字符集。

要處理中文，則可以將character-set-server和character-set-client均設置為GB2312，如果要同時處理多國語言，則設置為UTF8。

關于MySQL的中文問題

解決亂碼的方法是，在執(zhí)行SQL語句之前，將MySQL以下三個系統(tǒng)參數(shù)設置為與服務器字符集character-set-server相同的字符集。

character_set_client：客戶端的字符集。

character_set_results：結果字符集。

character_set_connection：連接字符集。

設置這三個系統(tǒng)參數(shù)通過向MySQL發(fā)送語句：set names gb2312

關于GBK、GB2312、UTF8

UTF- 8：Unicode Transformation Format-8bit，允許含BOM，但通常不含BOM。是用以解決國際上字符的一種多字節(jié)編碼，它對英文使用8位(即一個字節(jié))，中文使用24為(三個字節(jié))來編碼。UTF-8包含全世界所有國家需要用到的字符，是國際編碼，通用性強。UTF-8編碼的文字可以在各國支持UTF8字符集的瀏覽器上顯示。如，如果是UTF8編碼，則在外國人的英文IE上也能顯示中文，他們無需下載IE的中文語言支持包。

GBK是國家標準GB2312基礎上擴容后兼容GB2312的標準。GBK的文字編碼是用雙字節(jié)來表示的，即不論中、英文字符均使用雙字節(jié)來表示，為了區(qū)分中文，將其最高位都設定成1。GBK包含全部中文字符，是國家編碼，通用性比UTF8差，不過UTF8占用的數(shù)據(jù)庫比GBD大。

GBK、GB2312等與UTF8之間都必須通過Unicode編碼才能相互轉換：

GBK、GB2312－－Unicode－－UTF8

UTF8－－Unicode－－GBK、GB2312

對于一個網(wǎng)站、論壇來說，如果英文字符較多，則建議使用UTF－8節(jié)省空間。不過現(xiàn)在很多論壇的插件一般只支持GBK。

GB2312是GBK的子集，GBK是GB18030的子集

GBK是包括中日韓字符的大字符集合

如果是中文的網(wǎng)站 推薦GB2312，GBK有時還是有點問題

為了避免所有亂碼問題，應該采用UTF-8，將來要支持國際化也非常方便

UTF-8可以看作是大字符集，它包含了大部分文字的編碼。

使用UTF-8的一個好處是其他地區(qū)的用戶(如香港臺灣)無需安裝簡體中文支持就能正常觀看你的文字而不會出現(xiàn)亂碼。

gb2312是簡體中文的碼

gbk支持簡體中文及繁體中文

big5支持繁體中文

utf-8支持幾乎所有字符

首先分析亂碼的情況

2.查詢結果以亂碼返回

究竟在發(fā)生亂碼時是哪一種情況呢？

我們先在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 |

| /usr/local/mysql/share/mysql/charsets/ |

+————————–+—————————————-+

在查詢結果中可以看到mysql 數(shù)據(jù)庫系統(tǒng)中客戶端、數(shù)據(jù)庫連接、數(shù)據(jù)庫、文件系統(tǒng)、查詢結果、服務器、系統(tǒng)的字符集設置在這里，文件系統(tǒng)字符集是固定的，系統(tǒng)、服務器的字符集在安裝時確定，與亂碼問題無關。亂碼的問題與客戶端、數(shù)據(jù)庫連接、數(shù)據(jù)庫、查詢結果的字符集設置有關。

*注：客戶端是看訪問mysql 數(shù)據(jù)庫的方式，通過命令行訪問，命令行窗口就是客戶端，通過JDBC 等連接訪問，程序就是客戶端我們在向mysql 寫入中文數(shù)據(jù)時，在客戶端、數(shù)據(jù)庫連接、寫入數(shù)據(jù)庫時分別要進行編碼轉換。在執(zhí)行查詢時，在返回結果、數(shù)據(jù)庫連接、客戶端分別進行編碼轉換。

現(xiàn)在我們應該清楚，亂碼發(fā)生在數(shù)據(jù)庫、客戶端、查詢結果以及數(shù)據(jù)庫連接這其中一個或多個環(huán)節(jié)接下來我們來解決這個問題在登錄數(shù)據(jù)庫時，我們用mysql –default-character-set=字符集-u root -p 進行連接，這時我們再用show variables like '%char%';命令查看字符集設置情況，可以發(fā)現(xiàn)客戶端、數(shù)據(jù)庫連接、查詢結果的字符集已經(jīng)設置成登錄時選擇的字符集了

如果是已經(jīng)登錄了，可以使用set names 字符集;命令來實現(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ù)據(jù)庫的字符集可以修改mysql 的啟動配置來指定字符集，也可以在create database 時加上default character set 字符集來強制設置database 的字符集。

通過這樣的設置，整個數(shù)據(jù)寫入讀出流程中都統(tǒng)一了字符集，就不會出現(xiàn)亂碼了

為什么從命令行直接寫入中文不設置也不會出現(xiàn)亂碼？

可以明確的是從命令行下，客戶端、數(shù)據(jù)庫連接、查詢結果的字符集設置沒有變化，輸入的中文經(jīng)過一系列轉碼又轉回初始的字符集，我們查看到的當然不是亂碼，但這并不代表中文在數(shù)據(jù)庫里被正確作為中文字符存儲。

舉例來說，現(xiàn)在有一個utf8 編碼數(shù)據(jù)庫，客戶端連接使用GBK 編碼，connection 使用默認的ISO8859-1(也就是mysql 中的latin1)，我們在客戶端發(fā)送"中文"這個字符串，客戶端將發(fā)送一串GBK 格式的二進制碼給connection 層，connection 層以ISO8859-1 格式將這段二進制碼發(fā)送給數(shù)據(jù)庫，數(shù)據(jù)庫將這段編碼以utf8 格式存儲下來，我們將這個字段以utf8格式讀取出來，肯定是得到亂碼，也就是說中文數(shù)據(jù)在寫入數(shù)據(jù)庫時是以亂碼形式存儲的，在同一個客戶端進行查詢操作時，做了一套和寫入時相反的操作，錯誤的utf8 格式二進制碼又被轉換成正確的GBK 碼并正確顯示出來。

總結

以上是生活随笔為你收集整理的xp mysql字符集与乱码_mysql字符集（GBK、GB2312、UTF8）与中文乱码的原因及解决的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。