關於轉換或者公升級以後出現亂碼情況的說明
看到不少使用者反映轉換完以後是亂碼的情況
,出現這種現象的主要原因是這類使用者使用的都是
mysql4.1
以上的版本
.下面作乙個說明
,希望出現這個問題的朋友都能耐心的把這個文件看完
!!!原理
注意：本文件只對
mysql 4.1
及以上的資料庫版本有效，之前的
mysql
版本，由於沒有提供對字符集的完整支援，因此也不存在此類問題。
mysql 4.1
開始，對多語言的支援有了很大變化
(這導致了問題的出現
)。儘管大部分的地方
(包括個人使用和主機提供商)，
mysql 3
、4.0
仍然佔主導地位；但
mysql 4.1
是mysql
官方推薦的資料庫，已經有主機提供商開始提供並將會越來越多；因為
latin1
在許多地方
(下邊會詳細描述具體是哪些地方
) 作為預設的字符集，成功的蒙蔽了許多
php
程式的開發者和使用者，掩蓋了在中文等語言環境下會出現的問題。
mysql 4.1
對於字符集的指定可以細化到一台機器上安裝的
mysql
，其中的乙個資料庫，其中的一張表，其中的一欄，應該用什麼字符集。但是，傳統的
web
程式在建立資料庫和資料表時並沒有使用那麼複雜的配置，它們用的是預設的配置，那麼，預設的配置從何而來呢？
編譯mysql
時，指定了乙個預設的字符集，這個字符集是
latin1；安裝
mysql
時，可以在配置檔案
(my.ini)
中指定乙個預設的的字符集，如果沒指定，這個值繼承自編譯時指定的；
啟動mysqld
時，可以在命令列引數中指定乙個預設的的字符集，如果沒指定，這個值繼承自配置檔案中的；
此時character_set_server
被設定為這個預設的字符集；
當建立乙個新的資料庫時，除非明確指定，這個資料庫的字符集被預設設定為
character_set_server
；當選定了乙個資料庫時，
character_set_database
被設定為這個資料庫預設的字符集；
在這個資料庫裡建立一張表時，表預設的字符集被設定為
character_set_database
，也就是這個資料庫預設的字符集；
當在表內設定一欄時，除非明確指定，否則此欄預設的字符集就是表預設的字符集；
這個字符集就是資料庫中實際儲存資料採用的字符集，
mysqldump
出來的內容就是這個字符集下的；
想要進行「正確
」的儲存和得到「正確
」的結果，最方便的是在所有
query
開始之前執行一下：
set names 'gbk';
其中gbk
是資料庫字符集。
常見問題解決方案
我的資料使用
latin1
或其他編碼儲存中文資訊，但
phpmyadmin
中中文為亂碼
這問題是由於新版本的
phpmyadmin
都是強制使用正確的字符集進行資料庫連線和顯示的，因此如果儲存內碼和實際內碼不一致，
phpmyadmin
是無法識別的。對於簡體中文，
phpmyadmin
可識別gbk/utf8
；正體中文，可識別
big5/utf8
。如果你確定想使用這種
「不正確
」的字符集（事實上通常在
mysql 4.1
之前大家都是用
「不正確
」的字符集儲存資料的）儲存中文論壇資料，那麼請使用
phpmyadmin 2.5.x
的老版本，他會使用最老和最普通的方式連線資料庫，這樣便可以正常管理。
我的論壇原來使用
discuz! 4.0.0 rc
版本+mysql 4.1
沒有問題，但公升級到正式版後就有了亂碼
瀏覽這問題前請您先看一下上乙個問題的解答，您的情況和上面的情況差不多。
rc版本使用
「最老和最普通的方式
」連線資料庫，因此你如果使用
「不正確
」的字符集儲存，事實上是沒有問題的，但
discuz! 4.0.0
正式版使用了與
phpmyadmin
新版本相同的「正確
」的資料庫字符集，因此導致原來
「不正確
」的儲存和「正確
」的連線產生衝突，進而發生亂碼。
解決此類問題，有如下兩種方案：
更改儲存字符集
主要的思想就是把資料庫的字符集有
latin1
改為gbk
，big5,
或者utf8;
以下操作必須擁有主機許可權。假設當前操作的資料庫名為：
database
匯出首先需要把資料導為
mysql4.0
的格式，具體的命令如下：
mysqldump -uroot -p --default-character-set=latin1 --set-charset=gbk --skip-opt databse > test.sql
--default-characte-set
以前資料庫的字符集，這個一般情況下都是
latin1
的，--set-charset
匯出的資料的字符集，這個可以設定為
gbk，
utf8,
或者big5
匯入首先使用下面語句新建乙個
gbk字符集的資料庫（
test
）create database `test` default character set gbk collate gbk_chinese_ci;
然後把剛才匯出的資料匯入到當前的資料庫中就
ok了。
mysql -uroot -p --default-character-set=gbk -f test
通過以上的匯出和匯入就把資料庫的字符集改為正確的儲存方式了。
總結：這種方案比較麻煩，但相對以後則一直都是使用
mysql「正確」
的方式進行儲存和資料連線，並且新版本
phpmyadmin
不會亂碼。
更改連線方式
discuz! 4.0.0
對於discuz! 4.0.0
正式版，您可以找到
./include/db_mysql.class.php
，將mysql_query("set names '".str_replace('-', '', $globals['charset'])."'");
前面加上
「//」
，即將其注釋掉
discuz! 4.0.0+
對於discuz! 4.0.0
以後的版本，已經支援在
config.inc.php
中使用單獨的
$dbcharset
來設定資料庫字符集，因此可根據您的實際情況選擇留空（與
$charset
的設定相同），或指定為特定的資料庫字符集（如
latin1
）總結：折衷方案。資料使用
「不正確
」的內碼儲存，但顯示和使用能夠正常，
phpmyadmin
新版本亂碼，老版本可用。備份和恢復時候需要特別注意字符集問題。
應當如何公升級
mysql 4.0
的資料到
mysql 4.1+
中如果資料檔案中有中文資訊，那麼將
mysql 4.0
的資料檔案，直接拷貝到
mysql 4.1
中就是不可以的，即便在
my.ini
中設定了
default-character-set
為正確的字符集。雖然貌似沒有問題，但
mysql 4.1
的字符集有一處非常惱人的地方，以
gbk為例，原本
mysql 4.0
資料中varchar,char
等長度都會變為原來的一半，這樣儲存中文容量不變，而英文的儲存容量就少了一半。這是直接拷貝資料檔案帶來的最大問題。
所以，公升級的根本，如果想使用「正確
」的字符集，還是先用
mysqldump
匯出成檔案，然後匯入。
至於如果原來用的
latin1
，現在在
mysql 4.1
中還想繼續
「錯誤的」使用
latin1
，那麼只需把
default-character-set
設定為latin1
，並且在論壇中更改連線方式即可，這樣的情況是可以直接拷貝資料檔案的。
解決mysql資料庫亂碼問題
1,檢視資料庫編碼 命令 show variables like character set 2，修改已設定編碼 如對character set database修改編碼 命令 set character set database utf8 3,現象 用jdbc將中文字段插入mysql資料庫中，然後...
解決MySql資料庫的亂碼問題
問題的起源是安裝資料庫時時候沒有注意，最好的辦法是在安裝時把資料庫的編碼方式修改設定為utf 8的編碼方式，而最初的我採用預設一直 下一步 到底。一切問題就從此開始了 很多人勸我再裝一次！原因是安裝時修改編碼方式為utf 8則不會遇到後面的亂碼問題了！經過我的嘗試和總結解決該問題的方法如下 保證屢試...
解決mysql資料庫建立亂碼問題
mysql 中建立資料庫如果不指定字符集，一般中文會亂碼，資料庫中中文會顯示成？create table p user id int primary key auto increment,name varchar 10 char 2 若建立資料庫，並且執行 insert into p user na...