乙個站有可能經歷gb2312(gbk,big5)到utf8的轉換過程，其中會遇到很多的問題。站點太龐大了怎麼辦呢，只能一步步來了。要是能在極少改動前端**的情況下，先完成資料的轉換將會使整件事情容易得多。經過幾天測試終於發現，mysql以utf8儲存gbk輸出是可以實現的。mysql4.1後都有個特性，可以指定當前客戶端連線所使用的字符集，mysql預設都是latin1，或由mysql server端配置的字符集進行連線校對。我使用utf8_general_ci來建立字段。
db:
sql**:
複製** **如下:
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字符集進行連線校對，讀取操作指定使用gbk字符集進行連線校對。
php**:
複製** **如下:
<?php
// select db and set link use utf8
function _selespobjct_db_utf()
// select db and set link use &程式設計客棧nbsp;gbk
function _select_db_gb()
?>
需要注意幾點：
1. mysql必須把gbk,gb2312,utf8等字符集編譯進去。
2. 入庫的資料內容必須保證是最正確的utf8編碼。
3. 儲存和讀取操作要指定正確的字符集進行連線校對。
要是前端**運算元據入庫不能以utf8進行，則需要對字元進行轉碼了。（例如用ajax提交的資料便是正確的utf8,這時是不用轉換的。）
因為mb_string是php所支援字元最全的，而iconv比它稍差一點，mb_string並不能完全支援一些特殊字元的轉碼，所以目前為止都沒有完美的轉碼方法。
再次對mb_string和iconv進行比較：
mb_string:
1. 所支援字元最全
2. 內容自動識別編碼，不需要確定原來字元的編碼，但是執行效率比iconv差太多
3. $content = mb_convert_encoding($content, "utf-8", "gbk,gb2312,big5");（順序不同效果也有差異）
iconv:
1. 所支援字元不全
2. 需要確定原來字元的編碼，但在確定編碼的情況下執行效率比mb_convert_encoding高
3. $content = iconv("gbk", "utf-8", $content);
本文標題: mysql以utf8儲存gbk輸出的實現方法提供
本文位址:
gbk 轉換 utf 8問題
問題一 檔案已經另存為了utf 8碼，但關閉後重新開啟就自動變成了ansi編碼 答 原因是該檔案中沒有包含任何中文字元，如果該檔案有包含中文字元，將檔案另存為utf 8編碼後，中文字元會以3個位元組的寬度來儲存 要看16進製制 這樣，在第二次開啟檔案時，編輯器會自動將檔案識別為utf 8編碼。請仔細...
UTF 8和GBK的區別
utf 8和gbk的區別 2009年06月09日 星期二 下午 02 00 gbk是國家標準gb2312基礎上擴容後相容gb2312的標準。gbk的文字編碼是用雙位元組來表示的，即不論中 英文本元均使用雙位元組來表示，為了區分中文，將其最高位都設定成1。gbk包含全部中文字元，是國家編碼，通用性比u...
GBK與UTF 8的區別
gbk的文字編碼是雙位元組來表示的，即不論中 英文本元均使用雙位元組來表示，只不過為區分中文，將其最高位都定成1。至於utf 8編碼則是用以解決國際上字元的一種多位元組編碼，它對英文使用8位 即乙個位元組 中文使用24位 三個位元組 來編碼。對於英文本元較多的論壇則用utf 8節省空間。gbk包含全...