mysql 4.1以上版本中文亂碼解決方法集錦

時間 2021-08-13

標籤 php mysql linux web 算法 sql 數據庫瀏覽器安全服務器欄目 MySQL 简体版

原文原文鏈接

第一個方法：

MySQL 4.1 中文亂碼的問題

最近要將 MySQL 4.0 升級到 MySQL 4.1 ，發現了中文亂碼的問題，但願如下看法對你們有用。

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

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)和排序方式(Collation)。對於字符集的支持細化到四個層次: 服務器(server)，數據庫(database)，數據表(table)和鏈接(connection)。

查看系統的字符集和排序方式的設定能夠經過下面的兩條命令：

CODE:

mysql> SHOW VARIABLES LIKE 'character_set_%';

上面列出的值就是系統的默認值。若是你奇怪系統怎麼默認是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_set_results = utf8;
SET character_set_connection = utf8;
再試試看，正常了吧？

就是鏈接以後加個查詢

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＝utf8），因此必然亂碼。同理，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

[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 從新啓動mysql；
3.打開phpmyadmin，選擇lang爲"Chines simplifies(zh-utf-8)",選擇"MySQL 鏈接校對"爲"utf8_general_ci "點「顯示 MySQL 的運行信息」--「變量」，能夠看到：
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了。
有人要問，爲何都要改爲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-collation=gbk_chinese_ci --with-extra-charsets=gb2312,big5,utf8,binary,ascii --prefix=/usr/local/mysql
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 .
chown -R mysql var
chgrp -R mysql .
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 5不須要如下的設置。

能夠經過一下兩種方法解決數據庫用戶密碼不符問題：

其一: 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出來之後，引入了collation (校勘)的概念，終於有辦法讓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.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'

都是能夠的，都可以保證數據在編碼轉換中不出現丟失，也就是保證存儲入數據庫的是正確的內容。

怎麼保證取出的是正確的內容呢？考慮到絕大部分客戶端 (包括 WP)，發送數據的編碼也就是它所但願收到數據的編碼，因此:

SET character_set_results='gb2312'

能夠保證取出給瀏覽器顯示的格式就是 gb2312。

若是是第二種狀況，客戶端以 utf-8 格式發送 (WP 的默認狀況)，能夠採用下述配置:

SET character_set_client='utf8'
SET character_set_connection='utf8'
SET character_set_results='utf8'

這個配置就等價於 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.
$serverVersion = mysql_get_server_info($this->dbh);
$version = explode('.', $serverVersion);
if ($version[0] < 4) return;

// check if utf8 support was compiled in
$result = mysql_query("SHOW CHARACTER SET like 'utf8'",
$this->dbh);
if (mysql_num_rows($result) < = 0) return;

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 與 Collation 的慨念。

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]
err-log=/var/log/mysqld.log
pid-file=/var/run/mysqld/mysqld.pid

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

最後加一句： [url]www.quicklinux.org[/url]原創文章，轉載請註明出處。呵呵
郵件： [email]support@quicklinux.org[/email]
做者: MySQL 發佈日期: 2005-12-14
我升級了MYSQL到4.1.2，phpmyadmin用的是2.6.2。數據表裏面有中文的字段中文都變成了亂碼，導出數據也是亂碼。我用之前的2.5.7沒有問題，想問一下，應該在phpmyadmin的那個文件裏改哪一個設置一下才能顯示出來的是正常的中文字？

和字符相關的變量中這幾個和sql頗有關係：
character_set_client
character_set_connection
character_set_results
此外就是數據庫中對相應字段設置的charact set，若是沒有對字段設置，缺省是table的charact set，table也沒有指定則缺省使用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"後終於找到了解決方法並測試經過。

查看系統的字符集和排序方式的設定能夠經過下面的兩條命令：

上面列出的值就是系統的默認值。(很奇怪系統怎麼默認是latin1的瑞典語排序方式)...

當咱們按照原來的方式經過PHP存取MySQL數據庫時，就算設置了表的默認字符集爲utf8而且經過UTF-8編碼發送查詢，你會發現存入數據庫的仍然是亂碼。問題就出在這個connection鏈接層上。解決方法是在發送查詢前執行一下下面這句：

SET NAMES 'utf8';

它至關於下面的三句指令：
SET character_set_client = utf8;
SET character_set_results = utf8;
SET character_set_connection = utf8;

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

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

真應該把手冊仔細看一遍.
和字符相關的變量中這幾個和sql頗有關係：
character_set_client
character_set_connection
character_set_results
此外就是數據庫中對相應字段設置的charact set，若是沒有對字段設置，缺省是table的charact set，table也沒有指定則缺省使用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 < fmx3.sql -f --default-character-set=latin1