1. MySQL 4.1 在文字上有很大改進(jìn)，它有了 Character Set 與 Collation 的慨念。

2. 在 MySQL 4.0 ，一般的程式都會(huì)將文字以拉丁文 ( latin) 來(lái)儲(chǔ)存，就算我們輸入中文字，結(jié)果仍是放在以拉丁文設(shè)置的文字欄里頭，這對(duì) MySQL 4.0 與以 MySQL 4.0 為基楚的程式來(lái)說(shuō)，并不會(huì)有問(wèn)題。

3. 可是 MySQL 4.1 的系統(tǒng)編碼是預(yù)設(shè)用 UTF-8 的，當(dāng)要 restore MySQL 4.0 的 backup 檔到 MySQL 4.1 時(shí)，亂碼就出現(xiàn)了。原因在于 MySQL 4.1 將 latin 碼轉(zhuǎn)換過(guò)來(lái)，而后轉(zhuǎn)換是并不完全完美的，這導(dǎo)致了出現(xiàn)少量文字出現(xiàn)亂碼現(xiàn)象。

4. 要解決這亂碼問(wèn)題并不難。首先，在 MySQL 4.0 備份時(shí)，先將所有文字欄變成 binary 類(lèi)型，然后進(jìn)行正常備份。第二步，可在 MySQL 4.1 里將剛才的備份 restore。最后，將較早前所變更到 binay 類(lèi)型的文字欄，再次復(fù)原到文字類(lèi)型。這樣中文編碼的問(wèn)題就應(yīng)該可以完全解決。

5. 將文字欄變更到 binay 類(lèi)型時(shí)，必需設(shè)定 binary 欄的長(zhǎng)度大過(guò)或等于 (>=) 文字欄的長(zhǎng)度，否則資料會(huì)失去。

6. 另外，經(jīng)這樣升級(jí)的 MySQL 數(shù)據(jù)庫(kù)，在 MySQL 4.1 里將會(huì)正常工作，就算是怎樣 backup 與 restore 都不會(huì)再有亂碼問(wèn)題。
作者: MySQL 發(fā)布日期: 2005-12-14
mysql4.1是比較煩人，支持多語(yǔ)言的細(xì)化設(shè)置，再加上phpmyadmin2.6也比較笨，默認(rèn)就是改不動(dòng)的utf8，怎么弄都亂碼。
好了，廢話少說(shuō)，我們來(lái)一步步解決這個(gè)問(wèn)題：
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]
err-log=/var/log/mysqld.log
pid-file=/var/run/mysqld/mysqld.pid

注意：就是加入了一句default-character-set=utf8。

2./etc/init.d/mysqld restart 重新啟動(dòng)mysql；
3.打開(kāi)phpmyadmin，選擇lang為"Chines simplifies(zh-utf-8)",選擇"MySQL 連接校對(duì)"為"utf8_general_ci "點(diǎn)“顯示 MySQL 的運(yùn)行信息”--“變量”，可以看到：
character set client utf8 utf8
character set connection utf8 utf8
character set database utf8 utf8
character set results utf8 utf8
character set server utf8 utf8
character set system utf8 utf8
collation connection utf8_general_ci utf8_general_ci
collation database utf8_general_ci utf8_general_ci
collation server utf8_general_ci utf8_general_ci
從這里可以看到character全部變成utf8了。
有人要問(wèn)，為什么都要改成utf8呢？改成GB2312不行嗎？
解釋如下：
我也不想改成utf8，只是phpmyadmin2.6在mysql4.1的時(shí)候只會(huì)用utf8，連其他頁(yè)面的charset也都是utf8，改成gb2312一定會(huì)亂碼，我們只能湊phpmyadmin了。
只有在mysql3.23的時(shí)候，phpmyadmin才會(huì)多一個(gè)gb2312的頁(yè)面charset，這時(shí)候是正常的。
3.將以前的mysql3的庫(kù)文件導(dǎo)入mysql4.1的庫(kù)
有兩種情況：
一是從phpmyadmin上導(dǎo)入，這時(shí)候你要注意的是在選擇庫(kù)文件的頁(yè)面左下腳有個(gè)“文件的字符集：”，默認(rèn)是utf8，要改成gb2312，否則導(dǎo)進(jìn)去亂碼；
二是在linux下導(dǎo)入，這時(shí)候你需要先在庫(kù)文件的頭部加一行:
SET NAMES 'gb2312'; 注意最后也是;號(hào)，別漏了。
然后執(zhí)行mysql -u用戶(hù)名 -p密碼 xxx.sql > 庫(kù)名
導(dǎo)入完成以后再用phpmyadmin打開(kāi)看，里面的中文字就是正確的。
4.從mysql4.1里導(dǎo)出庫(kù)文件
一.用phpmyadmin導(dǎo)出
導(dǎo)出倒是問(wèn)題不大，如果phpmyadmin的瀏覽頁(yè)面里顯示的中文是正常的，那么導(dǎo)出肯定也是正常的
二.在linux上導(dǎo)出
如果用mysqldump導(dǎo)出出現(xiàn)了亂碼也沒(méi)有關(guān)系，可以運(yùn)行iconv來(lái)轉(zhuǎn)換一下
iconv -c -f UTF-8 -t GB2312 庫(kù)文件名 > 新的gb2312的庫(kù)文件名

綜上所述，你要注意：
1。盡量在需要導(dǎo)入的庫(kù)文件的開(kāi)頭加入SET NAMES 'gb2312';告訴mysql你要導(dǎo)入的是一個(gè)gb2312的文件；
2。可能你需要這個(gè)：
SET NAMES 'utf8';
在登陸到mysql后用，把character的一些默認(rèn)參數(shù)改到utf8上，有時(shí)可以減少一些困擾，不過(guò)也不是必須的。
在mysql上使用:
SHOW VARIABLES LIKE 'character_set_%';
用來(lái)查看當(dāng)前的狀態(tài)。
3.如果出現(xiàn)亂碼也不要怕，一是你要注意留存原有的備份，二是用iconv來(lái)進(jìn)行轉(zhuǎn)化。
在正常使用之前注意做導(dǎo)入導(dǎo)出的測(cè)試，確保萬(wàn)無(wú)一失。

最后加一句：www.quicklinux.org原創(chuàng)文章，轉(zhuǎn)載請(qǐng)注明出處。呵呵
郵件：support@quicklinux.org
作者: MySQL 發(fā)布日期: 2005-12-14
我升級(jí)了MYSQL到4.1.2，phpmyadmin用的是2.6.2。數(shù)據(jù)表里面有中文的字段中文都變成了亂碼，導(dǎo)出數(shù)據(jù)也是亂碼。我用以前的2.5.7沒(méi)有問(wèn)題，想問(wèn)一下，應(yīng)該在phpmyadmin的那個(gè)文件里改哪個(gè)設(shè)置一下才能顯示出來(lái)的是正常的中文字？

和字符相關(guān)的變量中這幾個(gè)和sql很有關(guān)系：
character_set_client
character_set_connection
character_set_results
此外就是數(shù)據(jù)庫(kù)中對(duì)相應(yīng)字段設(shè)置的charact set，如果沒(méi)有對(duì)字段設(shè)置，缺省是table的charact set，table也沒(méi)有指定則缺省使用database的。
上面3個(gè)變量的作用是這樣的，client表示客戶(hù)端發(fā)送過(guò)來(lái)的字符集，results表示發(fā)送到客戶(hù)端的字符集（這兩個(gè)分開(kāi)是因?yàn)榘l(fā)送過(guò)來(lái)和發(fā)送過(guò)去的不一定是同一個(gè)客戶(hù)端），connection則在客戶(hù)端和數(shù)據(jù)庫(kù)起一個(gè)連接作用。
具體是這樣：比如我在mysql命令行設(shè)置client為gbk，connection為utf8，results為gbk，數(shù)據(jù)庫(kù)為big5，
當(dāng)我發(fā)送一個(gè)insert語(yǔ)句的時(shí)候，這個(gè)語(yǔ)句作為gbk代碼，先轉(zhuǎn)為utf8代碼（connection），再轉(zhuǎn)為big5（database）插入數(shù)據(jù)庫(kù)。
而運(yùn)行一個(gè)select語(yǔ)句的時(shí)候，從數(shù)據(jù)庫(kù)得到的結(jié)果則相反的過(guò)程，由big5轉(zhuǎn)為utf8，再轉(zhuǎn)為gbk，你得到gbk的結(jié)果。
因此最主要的是讓client和results和你使用的客戶(hù)端一致。比如你的網(wǎng)頁(yè)是utf8編碼，你就要設(shè)置這兩個(gè)為utf8。
而在mysql命令行的時(shí)候，我用的是2000，需要設(shè)置為gbk
而我們用的set names XXX，實(shí)際上就是同時(shí)設(shè)置這3個(gè)變量為XXX。
在這樣的情況下，我們可以把一個(gè)數(shù)據(jù)庫(kù)中的不同表或不同字段設(shè)為不同的字符集，只要上面3個(gè)設(shè)置正確，就可以在數(shù)據(jù)庫(kù)中同時(shí)使用不同的字符集。
注意要保證你的數(shù)據(jù)庫(kù)中的字符已經(jīng)使用了正確的字符集，比如如果一開(kāi)始你設(shè)置錯(cuò)誤，插入數(shù)據(jù)后，本身數(shù)據(jù)的編碼就是不正確的，然后即使設(shè)置改回來(lái)，也不可能得到正確的顯示了。
還有一個(gè)是編碼互相之間的兼容性，如果一個(gè)字符在gbk中有，在utf8中沒(méi)有，那么在gbk－》utf8－》gbk的過(guò)程中，它就變成了“？”
再說(shuō)一下具體解決的辦法。
首先要指定你的升級(jí)后的database及table及field的character set，一般來(lái)說(shuō)我們用gb2312或者utf8的，如果不同時(shí)使用多種編碼，只要指定database就可以，可以在建庫(kù)的sql語(yǔ)句加上相應(yīng)的character set，在phpMyAdmin里也可以修改。
然后是導(dǎo)入舊數(shù)據(jù)。首先要確定自己的數(shù)據(jù)文件的編碼。如果用phpMyAdmin導(dǎo)入，在界面上有文件編碼的選項(xiàng)，一定要和數(shù)據(jù)文件的編碼一致。
如果從mysql的命令行導(dǎo)入，就要自己設(shè)置上面說(shuō)到的3個(gè)變量，set names xxx。
使用其它的客戶(hù)端程序一樣要注意。
這樣就可以讓舊數(shù)據(jù)轉(zhuǎn)入新數(shù)據(jù)庫(kù)后的編碼才是正確的，如果這一步錯(cuò)了，后面不可能得到正確的顯示。
然后是自己的程序，在連接后就可以執(zhí)行一次set names xxx，根據(jù)你的網(wǎng)頁(yè)編碼而定。
這樣基本就可以保證編碼正確了。
你很有可能是導(dǎo)入的數(shù)據(jù)編碼已經(jīng)不對(duì)了。
轉(zhuǎn)自：http://www.zhaodaola.org/blog/p/mysql-luanma.php


MYSQL數(shù)據(jù)庫(kù)默認(rèn)語(yǔ)言為瑞典語(yǔ), 現(xiàn)有一GB2312字符的數(shù)據(jù)庫(kù).
結(jié)構(gòu)OK. 為什么內(nèi)容是亂碼? 不重裝數(shù)據(jù)庫(kù)有辦法解決碼?

從MySQL 4.1開(kāi)始引入的多語(yǔ)言支持確實(shí)很棒，而且一些特性已經(jīng)超過(guò)了其他的數(shù)據(jù)庫(kù)系統(tǒng)。不過(guò)我在測(cè)試過(guò)程中發(fā)現(xiàn)使用適用于MySQL 4.1之前的PHP語(yǔ)句操作MySQL數(shù)據(jù)庫(kù)會(huì)造成亂碼，即使是設(shè)置過(guò)了表字符集也是如此。我讀了一下新的MySQL在線手冊(cè)中第十章"Character Set Support"后終于找到了解決方法并測(cè)試通過(guò)。

MySQL 4.1的字符集支持(Character Set Support)有兩個(gè)方面：字符集(Character set)和排序方式(Collation)。對(duì)于字符集的支持細(xì)化到四個(gè)層次: 服務(wù)器(server)，數(shù)據(jù)庫(kù)(database)，數(shù)據(jù)表(table)和連接(connection)。

查看系統(tǒng)的字符集和排序方式的設(shè)定可以通過(guò)下面的兩條命令：


mysql> SHOW VARIABLES LIKE 'character_set_%';
+--------------------------+----------------------------+
| Variable_name | Value |
+--------------------------+----------------------------+
| character_set_client | latin1 |
| character_set_connection | latin1 |
| character_set_database | latin1 |
| character_set_results | latin1 |
| character_set_server | latin1 |
| character_set_system | utf8 |
| character_sets_dir | /usr/share/mysql/charsets/ |
+--------------------------+----------------------------+
7 rows in set (0.00 sec)

mysql> SHOW VARIABLES LIKE 'collation_%';
+----------------------+-------------------+
| Variable_name | Value |
+----------------------+-------------------+
| collation_connection | latin1_swedish_ci |
| collation_database | latin1_swedish_ci |
| collation_server | latin1_swedish_ci |
+----------------------+-------------------+
3 rows in set (0.00 sec)


上面列出的值就是系統(tǒng)的默認(rèn)值。(很奇怪系統(tǒng)怎么默認(rèn)是latin1的瑞典語(yǔ)排序方式)...

當(dāng)我們按照原來(lái)的方式通過(guò)PHP存取MySQL數(shù)據(jù)庫(kù)時(shí)，就算設(shè)置了表的默認(rèn)字符集為utf8并且通過(guò)UTF-8編碼發(fā)送查詢(xún)，你會(huì)發(fā)現(xiàn)存入數(shù)據(jù)庫(kù)的仍然是亂碼。問(wèn)題就出在這個(gè)connection連接層上。解決方法是在發(fā)送查詢(xún)前執(zhí)行一下下面這句：

SET NAMES 'utf8';

它相當(dāng)于下面的三句指令：
SET character_set_client = utf8;
SET character_set_results = utf8;
SET character_set_connection = utf8;

再試試看，正常了吧？^_^ Enjoy!

具體講
在你的查詢(xún)前加一行：
                        mysql_query("SET NAMES 'gb2312';",$this->con);

真應(yīng)該把手冊(cè)仔細(xì)看一遍.

最新評(píng)論