一個(gè)站有可能經(jīng)歷gb2312(gbk,big5)到utf8的轉(zhuǎn)換過程，其中會(huì)遇到很多的問題。站點(diǎn)太龐大了怎么辦呢，只能一步步來了。要是能在極少改動(dòng)前端代碼的情況下，先完成數(shù)據(jù)的轉(zhuǎn)換將會(huì)使整件事情容易得多。經(jīng)過幾天測試終于發(fā)現(xiàn)，Mysql以utf8存儲gbk輸出是可以實(shí)現(xiàn)的。mysql4.1后都有個(gè)特性，可以指定當(dāng)前客戶端連接所使用的字符集，mysql默認(rèn)都是latin1，或由mysql server端配置的字符集進(jìn)行連接校對。我使用utf8_general_ci來創(chuàng)建字段。
DB:
SQL代碼:
復(fù)制代碼代碼如下:
Create TABLE `table` (
`id` INT( 10 ) NOT NULL ,
`name` VARCHAR( 50 ) CHARACTER SET utf8 COLLATE utf8_general_ci NOT NULL ,
INDEX ( `g_id` )
) ENGINE = innodb CHARACTER SET utf8 COLLATE utf8_general_ci;
PHP:
存儲操作指定使用utf8字符集進(jìn)行連接校對，讀取操作指定使用gbk字符集進(jìn)行連接校對。
PHP代碼:
復(fù)制代碼代碼如下:
<?php
// Select DB And Set Link Use UTF8
function _select_db_utf()
{
mysql_select_db($this->db_name, $this->db_link);
// init character
mysql_query("SET NAMES utf8", $this->db_link);
mysql_query("SET CHARACTER SET utf8", $this->db_link);
mysql_query("SET COLLATION_CONNECTION='utf8_general_ci'", $this->db_link);
return true;
}
// Select DB And Set Link Use GBK
function _select_db_gb()
{
mysql_select_db($this->db_name, $this->db_link);
// init character
mysql_query("SET NAMES gbk", $this->db_link);
mysql_query("SET CHARACTER SET gbk", $this->db_link);
mysql_query("SET COLLATION_CONNECTION='gbk_chinese_ci'", $this->db_link);
return true;
}
?>
需要注意幾點(diǎn)：
1. mysql必須把gbk,gb2312,utf8等字符集編譯進(jìn)去。
2. 入庫的數(shù)據(jù)內(nèi)容必須保證是最正確的UTF8編碼。
3. 存儲和讀取操作要指定正確的字符集進(jìn)行連接校對。
要是前端代碼操作數(shù)據(jù)入庫不能以UTF8進(jìn)行，則需要對字符進(jìn)行轉(zhuǎn)碼了。（例如用AJAX提交的數(shù)據(jù)便是正確的UTF8,這時(shí)是不用轉(zhuǎn)換的。）
因?yàn)閙b_string是PHP所支持字符最全的，而iconv比它稍差一點(diǎn)，mb_string并不能完全支持一些特殊字符的轉(zhuǎn)碼，所以目前為止都沒有完美的轉(zhuǎn)碼方法。
再次對mb_string和iconv進(jìn)行比較：
mb_string:
1. 所支持字符最全
2. 內(nèi)容自動(dòng)識別編碼，不需要確定原來字符的編碼，但是執(zhí)行效率比iconv差太多
3. $content = mb_convert_encoding($content, "UTF-8", "GBK,GB2312,BIG5");（順序不同效果也有差異）
iconv:
1. 所支持字符不全
2. 需要確定原來字符的編碼，但在確定編碼的情況下執(zhí)行效率比mb_convert_encoding高
3. $content = iconv("GBK", "UTF-8", $content);
