mysql 中文亂碼 解決方法集錦

第一個方法： 
MySQL 4.1 中文亂碼的問題 
最近要將 MySQL 4.0 升級到 MySQL 4.1 ，發現了中文亂碼的問題，希望以下見解對大家有用。 
1. MySQL 4.1 在文字上有很大改進，它有了 Character Set 與 Collat​​ion 的慨念。
2. 在MySQL 4.0 ，一般的程式都會將文字以拉丁文( latin) 來儲存，就算我們輸入中文字，結果仍是放在以拉丁文設置的文字欄裡頭，這對MySQL 4.0 與以MySQL 4.0為基楚的程式來說，並不會有問題。 
3. 可是 MySQL 4.1 的系統編碼是預設用 UTF-8 的，當要 restore MySQL 4.0 的 backup 檔到 MySQL 4.1 時，亂碼就出現了。原因在於 MySQL 4.1 將 latin 碼轉換過來，而後轉換是並不完全完美的，這導致了出現少量文字出現亂碼現象。 
解決PHP存取MySQL 4.1亂碼問題 
QUOTE: 
從MySQL 4.1開始引入的多語言支援確實很棒，而且一些功能已經超過了其他的資料庫系統。不過我在測試過程中發現使用適用於MySQL 4.1之前的PHP語句操作MySQL資料庫會造成亂碼，即使設定過了表字符集也是如此。我讀了一下新的MySQL線上手冊中第十章 "Character Set Support"後終於找到了解決方法並測試通過。 
MySQL 4.1的字元集支援(Character Set Support)有兩個面向：字元集(Character set)和排序方式(Collat​​ion)。對於字元集的支援細化到四個層次: 伺服器(server)，資料庫(database)，資料表(table)和連線(connection)。
查看系統的字元集和排序方式的設定可以透過下面的兩個指令： 
CODE: 
mysql> SHOW VARIABLES LIKE 'character_set_%'; 
+-------------- ------------+----------------------------+ 
| Variable_name | Value | 
+ --------------------------+---------------------- -----+ 
| character_set_client | latin1 | 
| character_set_connection | latin1 | 
| character_set_database | latin1 | 
| character_set_resulter_set_database | latin1 | 
| character_set_results | latin1 | system | utf8 | 
| character_sets_dir | /usr/share /mysql/charsets/ | 
+--------------------------+--------------- -------------+ 
7 rows in set (0.00 sec) 
mysql> SHOW VARIABLES LIKE 'collat​​ion_%'; 
+-------------- --------+-------------------+ 
| Variable_name | Value | 
+------------- ---------+-------------------+ 
| collat​​ion_connection | latin1_swedish_ci | 
| collat​​ion_database | latin1_swedish_ci | 
| collat​​ion_server | latin1_swedish_ci | 
+ ----------------------+-----------------+ 
3 rows in set (0.00 sec) 
上面列出的值就是系統的預設值。如果你奇怪系統怎麼預設是latin1的瑞典語排序方式,原因是MySQL由瑞典的T.c.X.DataKonsultAB公司(目前公司名稱為MySQL AB)開發，不用再多說了吧。 
當我們按照原來的方式透過PHP訪問MySQL資料庫時，就算設定了表格的預設字元集為utf8並且透過UTF-8編碼發送查詢，你會發現存入資料庫的仍然是亂碼。問題就出在這個connection連接層。解決方法是在發送查詢前執行一下下面這句： 
SET NAMES 'utf8'; 
它相當於下面的三句指令： 
CODE: 
SET character_set_client = utf8; 
SET character_v ; 
再試試看，正常了吧？ 
就是連接之後加個查詢 
CODE: 
$this->query(”SET NAMES ‘utf8＇”); 
看了手冊第10章覺得主要還是Character Sets的問題。 
character_set_client，character_set_results，character_set_connection三個運行變數是造成亂碼的關鍵。 mysql把客戶端提交的查詢由character_set_client轉換為character_set_connection 
，由於預設網頁提交的查詢是gb2312(表單頁meta裡可以看到)，而mysql預設將其當作utf8（可以查到此時的character_set_client＝f8 ），所以必然亂碼。同理，mysql返回的結果是已經轉換成character_set_results編碼的（與表的編碼無關），同樣默認是utf8，而網頁頁面把它當gb2312處理，所以必然有標題等由數據庫讀出的字段是亂碼而其他部門文字不亂碼的現象。
以上這個例子是utf8字元集，用此方法，設定為gbk，即可解決 
第三個方法： 
mysql 4.1亂碼終極解決方案 
請注意，本文只針對mysql 4.1，其它版本的mysql請看別的文章。 
mysql4.1是比較煩人，支援多語言的細化設置，再加上phpmyadmin2.6也比較笨，預設就是改不動的utf8，怎麼弄都亂碼。 
好了，廢話少說，我們來一步步解決這個問題： 
1.修改/etc/my.cnf文件，改成這樣： 
[mysqld] 
datadir=/var/lib/mysql 
socket=/var/ lib/mysql/mysql.sock 
default-character-set=utf8 
[mysql.server] 
user=mysql 
basedir=/var/lib 
[my pid-file=/var/run/mysqld/mysqld.pid 
注意：就是加入了一句default-character-set=utf8。
2./etc/init.d/mysqld restart 重新啟動mysql； 
3.開啟phpmyadmin，選擇lang為"Chines simplifies(zh-utf-8)",選擇"My​​SQL 連接校對"為"utf8_general_ci "點「顯示MySQL 的運作資訊」--“變數”，可以看到： 
character set client utf8 utf8 
character set connection utf8 utf8 
character set databasebase utf8 utf8 f8 
character set system utf8 utf8 
collat​​ion connection utf8_general_ci utf8_general_ci 
collat​​ion database utf8_general_ci utf8_general_ci 
collat​​ion server utf8_general_ci utf8_general_ci？ 
有人要問，為什麼要改成utf8？改成GB2312不行嗎？
解釋如下： 
我也不想改成utf8，只是phpmyadmin2.6在mysql4.1的時候只會用utf8，連其他頁的charset也都是utf8，改成gb2312一定會亂碼，我們只能湊phpmyadmin了。 
只有在mysql3.23的時候，phpmyadmin才會多一個gb2312的頁charset，這時候是正常的。
3.將以前的mysql3的庫文件導入mysql4.1的庫 
有兩種情況： 
一是從phpmyadmin上導入，這時候你要注意的是在選擇庫文件的頁面左下腳有個“文件的字元集：”，預設是utf8，要改成gb2312，否則導進去亂碼； 
二是在linux下導入，這時候你需要先在庫文件的頭部加一行: 
SET NAMES 'gb2312'; 注意最後也是;號，別漏了。 
接著執行mysql -u使用者名稱 -p密碼 xxx.sql > 函式庫名稱 
匯入完成以後再用phpmyadmin開啟看，裡面的文字就是正確的。
4.從mysql4.1裡導出庫文件 
一.用phpmyadmin導出 
導出倒是問題不大，如果phpmyadmin的瀏覽頁裡顯示的中文是正常的，那麼導出肯定也是正常的 
二.在linux上導出
如果用mysqldump導出出現了亂碼也沒有關係，可以運行iconv來轉換一下 
iconv -c -f UTF-8 -t GB2312 庫檔名> 新的gb2312的庫檔名 
綜上所述，你要注意： 
1。盡量在需要匯入的函式庫檔案的開頭加入SET NAMES 'gb2312';告訴mysql你要匯入的是一個gb2312的檔案； 
2。也許你需要這個： 
SET NAMES 'utf8'; 
在登陸到mysql後用，把character的一些預設參數改到utf8上，有時可以減少一些困擾，不過也不是必須的。 
在mysql上使用: 
SHOW VARIABLES LIKE 'character_set_%'; 
用來查看目前的狀態。 
3.如果出現亂碼也不要怕，一是你要注意留存原有的備份，二是用iconv來進行轉換。 
在正常使用前請注意做導入導出的測試，確保萬無一失。
下面再說明一下,網上很多朋友說Mysql4.1的只能升,不能降. 這是不正確的. 同樣使用mysqldump 導出數據庫時加一個--compatible 的參數.也千萬不能忘了--default -character-set=這個設定字元集的參數. 
示範: mysqldump -uroot -pPassword --compatible=mysql40 --default-character-set=gb2312 discuz>d:discuz.sql 
ok 這樣導出的檔案,就可以在Mysql4.0.X和Mysql.3.2.X版本中使用了. 
Linux下Mysql 5 中文亂碼的徹底解決及應用的一些注意事項 
一. 自從mysql4.1開始，mysql對中文的支持問題是比較煩人的，怎麼弄都亂碼，如今mysql5 據說是mysql的新紀元，但從官方下載安裝的mysql5仍存在亂碼現象，這裡就是針對此現像做的討論： 
建議最好是下載mysql的源碼進行編譯，這是由於官方編譯的mysql的預設支援編碼是latin字元集，所以中文字元在資料庫裡查看的時候看到的是亂碼。編譯MySQL時使用withcharset=編碼，可以方便地把mysql編譯成該編碼形式，這樣MySQL就會直接支援中文查找和排序，-- with-extra-charsets參數指定其它可用的字元集。 
下載並解壓縮原始碼包，開啟INSTALL-SOURCE，這裡介紹了linux下方詳細的安裝方法，所以大家所要注意的只是下面的configure指令： 
groupadd mysql 
useradd -g mysql mysql 
./configure --with-charset=gbk --with-collat​​ion=gbk_chinese_ci --with-extra-charsets=gb2312,big5,utf8,binary,ascii --prefix=/usr/local/myll 
make 
make install cp support-files/my-medium.cnf /etc/my.cnf 
cd /usr/local/mysql 
bin/mysql_install_db --user=mysql 
chown -R root 。 . 
bin/mysqld_safe --user=mysql & 
bin/mysql 
mysql> show variables; 
你可以看到全域的字元集參數全是gbk，gb2312字集應該包含在gbk裡，所以不討論。 
進行和平常mysql4.0一樣的php操作，你會發現仍然出現中文亂碼現象。 
這裡要說明的是：從mysql 4.1開始，必需在mysql資料庫連接後對應用的字元集做出說明，否則非英文字母的文字存取都無法解釋變成?號。
解決方法就是要適應新版mysql的要求： 
在連接mysql資料庫後執行set character set 字元集，該指令在最新版本的mysql 5如果預設字集和儲存相符可以免設： 
set character set gbk; 
在php裡應該是這麼寫:mysql_query("set character set gbk"); 
指令大小寫均可 
phpwind和discuz是廣泛應用的國產php論壇，大量的朋友在應用它，了解了以上步驟，你也可以對論壇原始碼進行很小的修改，安全地把資料庫升級到mysql5： 
找到include/db_mysql.php，修改function connect(...){.....} 
在選擇資料庫mysql_select_db($dbname) ;後面加上一句mysql_query('set character set gbk');記憶體。 
二. 文件的導入導出：如果存入非gbk字符，這時候你需要先在導入文件的頭部加一行: SET NAMES '字符集'; 並註意最後也是;號，別漏了。
檔案匯入和匯出執行 
mysql -u使用者名稱-p密碼資料庫名稱 
mysqldump -u使用者名稱-p密碼資料庫名稱>data.sql 
如果用mysqldump匯出資料出現了亂碼也沒有關係，可以執行iconv來轉換一下： 
iconv -c -f utf8 -t gbk 庫檔名>新的gbk的庫檔名 
綜上所述，你要注意： 
1。盡量在需要匯入的函式庫檔案的開頭加入set names 'gbk';告訴mysql你要匯入的是一個gbk的檔案； 
2。在mysql上使用 show variables;或show variables like 'character_set_%'; 用來查看目前的字集狀態。 
3。如果出現亂碼也不要怕，其一是你要注意留存原有的備份，其二是用iconv來進行轉換。 
#PHP連線問題： 
由於MySQL 4.1版本開始密碼的hash演算法改變，所以連接資料庫時可能會出現Client does not support authentication protocol問題 
這個問題在mysql 5中不存在，mysql 555不需要以下的設定。
可以透過一下兩種方法來解決資料庫使用者密碼不符問題： 
其一: mysql> SET PASSWORD FOR 'some_user'@'some_host' = OLD_PASSWORD('newpwd'); 
其二: mysql> Update mysql.user SET Password = OLD_PASSWORD('newpwd') Where Host = 'some_host' AND User = 'some_user' 
PHP輸出的其它亂碼問題： 
如果將mysql編譯為預設編碼gbk的話，又導入會造成非gbk資料直接顯示為亂碼例如部份utf8儲存的字符，如果你大部份資料是utf8字集，當然得把mysql編譯成預設編碼utf8才適合。
Mysql 4.1.x出來以後，引入了collat​​ion (校勘)的概念，終於有辦法讓mysql同時支援多種編碼的資料庫了，所以PHP要用以下SQL語句來建立utf-8編碼的資料庫： 
Create DATABASE `mytest` DEFAULT CHARACTER SET utf8 COLLATE utf8_general_ci; 
但是僅僅是將資料庫的校勘改為utf-8是不夠的，還必須在連接了mysql資料庫之後用這個語句來設定：set names 'utf8';才能在php程式裡得到正確編碼的字符，並將其顯示在web頁面中。
mysql_query("set names 'utf8'",$connection); 
下面再說明一下,網上很多朋友說Mysql4.1的只能升,不能降. 這是不正確的. 同樣使用mysqldump 導出數據庫時加一個--compatible 的參數。也千萬不能忘了--default-character-set=這個設定字元集的參數。
示範: mysqldump -uroot -pPassword --compatible=mysql40 --default-character-set=gb2312 discuz>d:discuz.sql 
ok 這樣導出的檔案,就可以在Mysql4.0.X和Mysql.3.2.Mysql.3.2.Mysql.3.2.Mysql.3.2. X版中使用了. 
下面要寫的是一篇非常無聊的東西，充斥了大量各式各樣的編碼、轉換、客戶端、伺服器端、連接…呃，我自己都不願意去看它，但想一想，寫下來還是有點意義的，原因有四： 
MySQL 4.1 對多語言的支援有了很大變化(這導致了問題的出現​​)； 
儘管大部分的地方(包括個人使用和主機提供者)，MySQL 3 仍然占主導地位；但MySQL 4.1 是MySQL 官方建議的資料庫，已經有主機供應商開始提供並將會越來越多； 
許多PHP 程式以MySQL 作為預設的資料庫管理軟體，但它們一般不區分MySQL 4.1 與4.1 以下版本的區別，籠統地稱為「 MySQL 3.xx.xx 以上版本」就滿足安裝需求了； 
因為latin1 在許多地方(下邊會詳細描述具體是哪些地方) 作為默認的字符集，成功的蒙蔽了許多PHP 程序的開發者和用戶，掩蓋了在中文等語言環境下會出現的問題； 
簡單的說，MySQL 自身的變化和使用MySQL 的PHP 程式對此忽略，導致了問題的出現​​和復雜化，而由於大部分用戶使用的是英文，使這種問題不被重視。這裡提到的 PHP 程序，主要就 WordPress 而言。 
MySQL 4.1 字元集支援的原理MySQL 4.1 對於字元集的指定可以細化到一台機器上安裝的 MySQL，其中的一個資料庫，其中的一張表，其中的一欄，應該用什麼字元集。但是，傳統的 Web 程式在建立資料庫和資料表時並沒有使用那麼複雜的配置，它們使用的是預設的配置，那麼，預設的配置從何而來呢？
編譯MySQL 時，指定了一個預設的字元集，這個字元集是latin1； 
安裝MySQL 時，可以在設定檔(my.ini) 中指定一個預設的字元集，如果沒指定，這個值繼承自編譯時指定的； 
啟動mysqld 時，可以在命令列參數中指定一個預設的字元集，如果沒指定，這個值繼承自設定檔中的； 
此時character_set_server 被設定為這個預設的字元集； 
當建立一個新的資料庫時，除非明確指定，這個資料庫的字元集被缺省設定為character_set_server； 
當選定了一個資料庫時，character_set_database 被設定為這個資料庫預設的字元集； 
在這個資料庫裡建立一張表時，表預設的字元集被設定為character_set_database，也就是這個資料庫預設的字元集； 
當在表內設定一欄時，除非明確指定，否則此欄缺省的字符集就是表格預設的字元集； 
這個字元集就是資料庫中實際儲存資料所採用的字元集，mysqldump 出來的內容就是這個字元集下的； 
簡單的總結一下，如果什麼地方都不修改，那麼所有的資料庫的所有表的所有欄位的都用latin1 存儲，不過我們如果安裝MySQL，一般都會選擇多語言支持，也就是說，安裝程序會自動在配置文件中把default_character_set 設置為UTF-8，這保證了預設情況下，所有的資料庫的所有表格的所有欄位的都用UTF-8 儲存。 
當一個 PHP 程式與 MySQL 建立連線後，這個程式傳送給 MySQL 的資料所採用的是什麼字元集？ MySQL 無從得知(它最多只能猜測)，所以MySQL 4.1 要求客戶端必須指定這個字元集，也就是character_set_client，MySQL 的怪異之處在於，得到的這個字元集並不會立即轉換為儲存在資料庫中的那個字元集，而是先轉換為character_set_connection 變數指定的一個字元集；這個connection 層究竟有什麼用我不大明白，但轉換為character_set_connection 的這個字元集之後，還要轉換為資料庫預設的字元集，也就是說要經過兩次轉換；當這個資料被輸出時，又要由資料庫預設的字元集轉換為character_set_results 指定的字元集。 
一個典型的環境典型的環境以我自己的電腦上安裝的 MySQL 4.1 為例，我自己的電腦上安裝著 Apache 2，PHP 5 和 WordPress 1.5.1.3，MySQL 設定檔中指定了 default_character_set 為 utf8。於是問題出現了： 
WordPress 依照預設情況安裝，所以所有的表都用UTF-8 儲存資料； 
WordPress 預設採用的瀏覽字元集是UTF-8 (Options->Reading 中設定)，因此所有WP 頁面的meta 中會說明charset 是utf-8； 
所以瀏覽器會以utf-8 方式顯示所有的WP 頁面；這樣一來Write 的所有Post，和Comment 都會以UTF-8 格式從瀏覽器發送給Apache，再由Apache 交給PHP； 
所以WP 從所有的表單中得到的資料都是utf-8 編碼的；WP 不加轉換的直接把這些資料傳送給MySQL； 
MySQL 預設設定的character_set_client 和character_set_connection 都是latin1，此時怪異的事情發生了，實際上是utf-8 格式的數據，被「當作latin1」轉換成…居然還是轉換成latin1，然後再由這個latin1轉換成utf-8，這麼兩次轉換，有一部分utf-8 的字元就遺失了，變成??，最後輸出的時候character_set_results 預設是latin1，也就輸出為奇怪的東西了。
最神奇的還不是這個，如果WordPress 中設定以GB2312 格式閱讀，那麼WP 發送給MySQL 的GB2312 編碼的數據，被「當作latin1」轉換後，存進資料庫的是一種奇怪的格式(真的是奇怪的格式，mysqldump 出來就能發現，無論當作utf-8 還是當作gb2312 來讀都是亂碼)，但如果這種格式以latin1 輸出出來，居然又能變回GB2312！ 
這會導致什麼現象呢？ WP 如果使用 MySQL 4.1 資料庫，把編碼改用 GB2312 就正常了，可惜，這種正常只是貌似正常。
如何解決問題如果你已經不耐煩了(幾乎是肯定的)，google 一下，會發現絕大部分的解答是，query 之前先執行一下：SET NAMES 'utf8'，沒錯，這是解決方案，但本文的目的是說明，這為什麼是解決方案。 
要確保結果正確，必須確保資料表採用的格式是正確的，也就是說，至少能夠存放所有的漢字，那麼我們只有兩種選擇，gbk 或 utf-8，下面討論 utf-8 的情況。 
因為設定檔設定的 default_character_set 是 utf8，資料表預設採用的就是 utf-8 建立的。這也應該是所有採用 MySQL 4.1 的主機提供者應該採用的配置。所以我們要保證的只是客戶端與 MySQL 互動之間指定編碼的正確。 
這只有兩種可能，客戶端以 gb2312 格式傳送數據，或以 utf-8 格式傳送資料。
如果以gb2312 格式傳送: 
SET character_set_client='gb2312' 
SET character_set_connection='utf8' 或 
SET character_set_connection='gb2312 或 
SET character_set_connection='gb2312儲存入資料庫的是正確的內容。 
怎麼保證取出的是正確的內容呢？考慮到絕大部分客戶端 (包括 WP)，發送資料的編碼也就是它所希望收到資料的編碼，所以: 
SET character_set_results='gb2312' 
可以保證取出給瀏覽器顯示的格式就是 gb2312。
如果是第二種情況，客戶端以utf-8 格式傳送(WP 的預設情況)，可以採用下述配置: 
SET character_set_client='utf8' 
SET character_set_connection='utf8' 
_character
這個配置就等價於SET NAMES 'utf8'。
WP 應該作什麼修改還是那句話，客戶端要發給資料庫什麼編碼的數據，資料庫是不可能確切知道的，只能讓客戶端自己說明白，所以，WP 是必鬚髮送正確的SET.. . 給MySQL 的。怎麼發送最適合呢？台灣的pLog 同事給了一些建議： 
首先，測試伺服器是否>= 4.1，編譯時是否加入了UTF-8 支援；是則繼續 
然後測試資料庫以何種格式儲存($dbEncoding)； 
SET NAMES $ dbEncoding 
對於第二點，WP 的情況是不同的，按照上面的典型配置，只要用WP，肯定資料庫是用UTF-8 儲存的，所以要根據使用者設定的以GB2312 還是UTF-8 瀏覽來判斷( bloginfo('charset'))，但這個值是要連接資料庫以後才能得到的，所以效率最高的方式是連接資料庫之後，根據這個配置設定一次SET NAMES，而不必每次查詢之前都設定一遍。
我的修改方式是這樣的，在wp_includes/wp-db.php 中增加: 
function set_charset($charset) 
{ 
// check mysql version first. 
{ 
// check mysql version first. 
$serverVersion = my_$server_
$version = explode('.', $serverVersion); 
if ($version[0] // check if utf8 support was compiled in 
$result = mysql_queAC("SH was compilut SH 
$result = mysql_queAC("SH '", 
$this->dbh); 
if (mysql_num_rows($result) if ($charset == 'utf-8' || $charset == 'UTF-8') 
$charset = 'utf8'; 
@mysql_query("SET NAMES '$charset'", $this->dbh); 
} 
在wp-settings.php 的require (ABSPATH . WPINC . '/vars.php') ; 後加： 
$wpdb->set_charset(get_bloginfo('charset')); 🎜🎜1. MySQL 4.1 在文字上有很大改進，它有了Character Set 與Collat​​ion 的慨念。 🎜2. 在MySQL 4.0 ，一般的程式都會將文字以拉丁文( latin) 來儲存，就算我們輸入中文字，結果仍是放在以拉丁文設定的文字欄裡頭，這對MySQL 4.0 與以MySQL 4.0 為基楚的程式來說，並不會有問題。 
3. 可是 MySQL 4.1 的系統編碼是預設用 UTF-8 的，當要 restore MySQL 4.0 的 backup 檔到 MySQL 4.1 時，亂碼就出現了。原因在於 MySQL 4.1 將 latin 碼轉換過來，而後轉換是並不完全完美的，這導致了出現少量文字出現亂碼現象。 
4. 解決這亂碼問題並不難。首先，在 MySQL 4.0 備份時，先將所有文字列變成 binary 類型，然後進行正常備份。第二步，可在 MySQL 4.1 中將剛才的備份 restore。最後，將較早前所變更到 binay 類型的文字欄，再次復原到文字類型。這樣中文編碼的問題就應該可以完全解決。 
5. 將文字欄變更到 binay 類型時，必需設定 binary 欄的長度大過或等於 (>=) 文字欄的長度，否則資料會失去。 
6. 另外，經過這樣升級的 MySQL 資料庫，在 MySQL 4.1 裡將會正常運作，就算是怎樣 backup 與 restore 都不會再有亂碼問題。
作者: MySQL 發布日期: 2005-12-14 
mysql4.1是比較煩人，支援多語言的細化設置，再加上phpmyadmin2.6也比較笨，預設就是改不動的utf8，怎麼弄都亂碼。
好了，廢話少說，我們來一步步解決這個問題： 
1.修改/etc/my.cnf文件，改成這樣： 
[mysqld] 
datadir=/var/lib/mysql 
socket=/var /lib/mysql/mysql.sock 
default-character-set=utf8 
[mysql.server] 
user=mysql 
basedir=/var/lib 
[mysqld_safe] 
basedir=/var/lib 
[mysqld_safe] 

pid-file=/var/run/mysqld/mysqld.pid 
注意：就是加入了一句default-character-set=utf8。
2./etc/init.d/mysqld restart 重新啟動mysql； 
3.開啟phpmyadmin，選擇lang為"Chines simplifies(zh-utf-8)",選擇"My​​SQL 連接校對"為"utf8_general_ci "點「顯示MySQL 的運作資訊」--“變數”，可以看到： 
character set client utf8 utf8 
character set connection utf8 utf8 
character set databasebase utf8 utf8 f8 
character set system utf8 utf8 
collat​​ion connection utf8_general_ci utf8_general_ci 
collat​​ion database utf8_general_ci utf8_general_ci 
collat​​ion server utf8_general_ci utf8_general_ci？ 
有人要問，為什麼要改成utf8？改成GB2312不行嗎？
解釋如下： 
我也不想改成utf8，只是phpmyadmin2.6在mysql4.1的時候只會用utf8，連其他頁的charset也都是utf8，改成gb2312一定會亂碼，我們只能湊phpmyadmin了。 
只有在mysql3.23的時候，phpmyadmin才會多一個gb2312的頁charset，這時候是正常的。
3.將以前的mysql3的庫文件導入mysql4.1的庫 
有兩種情況： 
一是從phpmyadmin上導入，這時候你要注意的是在選擇庫文件的頁面左下腳有個“文件的字元集：”，預設是utf8，要改成gb2312，否則導進去亂碼； 
二是在linux下導入，這時候你需要先在庫文件的頭部加一行: 
SET NAMES 'gb2312'; 注意最後也是;號，別漏了。 
接著執行mysql -u使用者名稱 -p密碼 xxx.sql > 函式庫名稱 
匯入完成以後再用phpmyadmin開啟看，裡面的文字就是正確的。
4.從mysql4.1裡導出庫文件 
一.用phpmyadmin導出 
導出倒是問題不大，如果phpmyadmin的瀏覽頁裡顯示的中文是正常的，那麼導出肯定也是正常的 
二.在linux上導出
如果用mysqldump導出出現了亂碼也沒有關係，可以運行iconv來轉換一下 
iconv -c -f UTF-8 -t GB2312 庫檔名> 新的gb2312的庫檔名 
綜上所述，你要注意： 
1。盡量在需要匯入的函式庫檔案的開頭加入SET NAMES 'gb2312';告訴mysql你要匯入的是一個gb2312的檔案； 
2。也許你需要這個： 
SET NAMES 'utf8'; 
在登陸到mysql後用，把character的一些預設參數改到utf8上，有時可以減少一些困擾，不過也不是必須的。 
在mysql上使用: 
SHOW VARIABLES LIKE 'character_set_%'; 
用來查看目前的狀態。 
3.如果出現亂碼也不要怕，一是你要注意留存原有的備份，二是用iconv來進行轉換。 
在正常使用前請注意做導入導出的測試，確保萬無一失。 


我升級了MYSQL到4.1.2，phpmyadmin用的是2.6.2。資料表裡面有中文的欄位中文都變成了亂碼，匯出資料也是亂碼。我用以前的2.5.7沒有問題，想問一下，應該在phpmyadmin的那個檔案裡改哪個設定一下才能顯示出來的是正常的中文字？
和字元相關的變數中這幾個和sql很有關係： 
character_set_client 
character_set_connection 
character_set_results 
此外就是資料庫中對對應的欄位設定的欄位 set，如果沒有對格設定，則是缺省是tabletable也沒有指定則缺省使用database的。
上面3個變數的作用是這樣的，client表示客戶端發送過來的字元集，results表示發送到客戶端的字元集（這兩個分開是因為發送過來和發送過去的不一定是同一個客戶端） ，connection則在客戶端和資料庫起一個連線作用。
具體是這樣：例如我在mysql命令列設定client為gbk，connection為utf8，results為gbk，資料庫為big5， 
當我傳送一個insert語句的時候，這個語句作為gbk程式碼，先轉為utf8程式碼（ connection），再轉為big5（database）插入資料庫。 
而執行一個select語句的時候，從資料庫得到的結果則相反的過程，由big5轉為utf8，再轉為gbk，你得到gbk的結果。 
因此最主要的是讓client和results和你使用的客戶端一致。例如你的網頁是utf8編碼，你就要設定這兩個為utf8。 
而在mysql指令列的時候，我用的是2000，需要設定為gbk 
而我們用的set names XXX，其實就是同時設定這3個變數為XXX。 
在這樣的情況下，我們可以把一個資料庫中的不同表格或不同欄位設為不同的字元集，只要上面3個設定正確，就可以在資料庫中同時使用不同的字元集。
注意要確保你的資料庫中的字元已經使用了正確的字元集，例如如果一開始你設定錯誤，插入資料後，本身資料的編碼就是不正確的，然後即使設定改回來，也不可能得到正確的顯示了。
還有一個是編碼互相之間的相容性，如果一個字元在gbk中有，在utf8中沒有，那麼在gbk－》utf8－》gbk的過程中，它就變成了「？」 
再說一下具體解決的辦法。
首先要指定你的升級後的database及table及field的character set，一般來說我們用gb2312或utf8的，如果不同時使用多種編碼，只要指定database就可以，可以在建庫的sql語句加上對應的character set，在phpMyAdmin裡也可以修改。 
接著是導入舊資料。首先要確定自己的資料檔案的編碼。如果用phpMyAdmin導入，在介面上有文件編碼的選項，一定要跟資料檔的編碼一致。 
如果從mysql的命令列導入，就要自己設定上面說到的3個變量，set names xxx。 
使用其它的客戶端程式一樣要注意。 
這樣就可以讓舊資料轉入新資料庫後的編碼才是正確的，如果這一步錯了，後面不可能得到正確的顯示。 
接著是自己的程序，連線後就可以執行一次set names xxx，依照你的網頁編碼而定。 
這樣基本上就可以保證編碼正確了。 
你很有可能是導入的資料編碼已經不對了。

MYSQL資料庫預設語言為瑞典語, 現有一GB2312字元的資料庫. 
結構OK. 為什麼內容是亂碼? 不重裝資料庫有辦法解決碼? 
從MySQL 4.1開始引入的多語言支援確實很棒，而且一些特性已經超過了其他的資料庫系統。不過我在測試過程中發現使用適用於MySQL 4.1之前的PHP語句操作MySQL資料庫會造成亂碼，即使設定過了表字符集也是如此。我讀了一下新的MySQL線上手冊中第十章 "Character Set Support"後終於找到了解決方法並測試通過。 
MySQL 4.1的字元集支援(Character Set Support)有兩個面向：字元集(Character set)和排序方式(Collat​​ion)。對於字元集的支援細化到四個層次: 伺服器(server)，資料庫(database)，資料表(table)和連線(connection)。
查看系統的字元集和排序方式的設定可以透過下面的兩個指令： 

mysql> SHOW VARIABLES LIKE 'character_set_%'; 
+---------------- ----------+----------------------------+ 
| Variable_name | Value | 
+-- ------------------------+------------------------- ---+ 
| character_set_client | latin1 | 
| character_set_connection | latin1 | 
| character_set_database | latin1 | 
| character_set_resulter_set_database | latin1 | 
| character_set_results | latin1 | system | utf8 | 
| character_sets_dir | /usr/share/mysql /charsets/ | 
+--------------------------+---------------------- ------+ 
7 rows in set (0.00 sec) 
mysql> SHOW VARIABLES LIKE 'collat​​ion_%'; 
+--------------------- -+-------------------+ 
| Variable_name | Value | 
+-------------------- --+-------------------+ 
| collat​​ion_connection | latin1_swedish_ci | 
| collat​​ion_database | latin1_swedish_ci | 
| collat​​ion_server | latin1_swedish_ci | 
+-------+-------+------- ---------------+-------------------+ 
3 rows in set (0.00 sec) 

上面列出的值就是系統的預設值。 (很奇怪系統怎麼預設是latin1的瑞典語排序方式)... 
當我們按照原來的方式透過PHP訪問MySQL資料庫時，就算設定了表格的預設字元集為utf8並且透過UTF-8編碼發送查詢，你會發現存入資料庫的還是亂碼。問題就出在這個connection連接層。解決方法是在發送查詢前執行一下下面這句： 
SET NAMES 'utf8'; 
它相當於下面的三句指令： 
SET character_set_client = utf8; 
SET character_set_results = utf8;試試看，正常了吧？ ^_^ Enjoy! 
具體講 
在你的查詢前加一行： 
mysql_query("SET NAMES 'gb2312';",$this->con); 
mysql_query("SET NAMES 'gb2312';",$this->con); 
真應該把手冊看一遍. 
和字符相關的仔細真應該把手冊看一遍。變數中這幾個和sql很有關係： 
character_set_client 
character_set_connection 
character_set_results 
此外就是資料庫中對對應欄位設定的charact set，如果沒有對欄位設定，缺省是table的charact set，也沒有指定省使用database的。
上面3個變數的作用是這樣的，client表示客戶端發送過來的字元集，results表示發送到客戶端的字元集（這兩個分開是因為發送過來和發送過去的不一定是同一個客戶端） ，connection則在客戶端和資料庫起一個連線作用。
具體是這樣：例如我在mysql命令列設定client為gbk，connection為utf8，results為gbk，資料庫為big5， 
當我傳送一個insert語句的時候，這個語句作為gbk程式碼，先轉為utf8程式碼（ connection），再轉為big5（database）插入資料庫。 
而執行一個select語句的時候，從資料庫得到的結果則相反的過程，由big5轉為utf8，再轉為gbk，你得到gbk的結果。 
因此最主要的是讓client和results和你使用的客戶端一致。例如你的網頁是utf8編碼，你就要設定這兩個為utf8。 
而在mysql指令列的時候，我用的是2000，需要設定為gbk 
而我們用的set names XXX，其實就是同時設定這3個變數為XXX。 
在這樣的情況下，我們可以把一個資料庫中的不同表格或不同欄位設為不同的字元集，只要上面3個設定正確，就可以在資料庫中同時使用不同的字元集。
注意要確保你的資料庫中的字元已經使用了正確的字元集，例如如果一開始你設定錯誤，插入資料後，本身資料的編碼就是不正確的，然後即使設定改回來，也不可能得到正確的顯示了。
還有一個是編碼互相之間的相容性，如果一個字元在gbk中有，在utf8中沒有，那麼在gbk－》utf8－》gbk的過程中，它就變成了「？」 
再說一下具體解決的辦法。
首先要指定你的升級後的database及table及field的character set，一般來說我們用gb2312或utf8的，如果不同時使用多種編碼，只要指定database就可以，可以在建庫的sql語句加上對應的character set，在phpMyAdmin裡也可以修改。 
接著是導入舊資料。首先要確定自己的資料檔案的編碼。如果用phpMyAdmin導入，在介面上有文件編碼的選項，一定要跟資料檔的編碼一致。 
如果從mysql的命令列導入，就要自己設定上面說到的3個變量，set names xxx。 
使用其它的客戶端程式一樣要注意。 
這樣就可以讓舊資料轉入新資料庫後的編碼才是正確的，如果這一步錯了，後面不可能得到正確的顯示。 
接著是自己的程序，連線後就可以執行一次set names xxx，依照你的網頁編碼而定。
----------------------------------------- 
mysql 導入亂碼問題- - 
mysql從4.1使用mysqldump匯出資料並在4.0匯入的時候會出現sql語句錯誤，而且所有資料變成亂碼。使用下面的參數就可以解決 
mysqldump -uxunai -p --compatible=mysql40 --default-character-set=latin1 xunai>xunai.sql 
mysql -uroot -p fmx

 以上就是mysql 中文亂碼 解決方法集錦的內容，更多相關內容請關注PHP中文網（www.php.cn）！