MySQL 4.1 字符集支持的原理(轉)

MySQL 4.1 字符集支持的原理(轉)[@more@]下面要寫的是一篇非常無聊的東西，充斥了大量各式各樣的編碼、轉換、客戶端、服務器端、連接……呃，我自己都不愿意去看它，但想一想，寫下來還是有點意義的，原因有四：

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'));
Posted in : Server-Side Author : jjgod