PHP存取 Mysql 資料亂碼終極解決方案

      對PHP和Mysql 的研究並不深入，以下是我的一些個人心得，說的可能不是很明白，但確實是很管用的東西。
      我的Discuz版本是UTF－8的，但是開啟phpmyadmin顯示的是 整理欄目：gbk_chinese_ci ，而且查看資料顯示完全正常，沒有亂碼，這個表示，實際 discuz在存取資料庫用的是 gbk編碼，但頁面顯示確實UTF-8編碼阿，怎麼沒有亂碼呢？難道Discuz做了編碼轉換。

      最近在公司開發一個網站，由於用到了 cakephp架構 ，預設編碼為UTF-8，而且我的電腦是Ubuntu，通常用的都是UTF-8編碼，所寫的程式頁面也都是UTF-8編碼的檔案，自然想到用UTF-8編碼的資料庫，這個問題可把我苦大了。
      按照一般網上的說法是建立資料庫表的時候加上  DEFAULT CHARSET UTF8 ，建立的表的整理欄目在phpmyadmin裡面顯示的 是 utf8_general_ci ，在執行sql 語句是加上“set names utf8”，這樣就會正常了，插入的資料在頁面裡面顯示完全正常，我的頁面是 設定了UTF-8編碼的 ，<meta http-equiv="content-type" content="text/html; charset=UTF-8" /> ，按理說應該沒有什麼問題的，但是在Phpmyadmin裡面顯示的確是亂碼，而且如果我在phpmyadmin裡面修改了一個資料，在phpmyadmin裡面顯示就是正常了，但是到頁面顯示卻亂碼了，於是我想參考一下discuz的做法在phpmyadmin裡面強行把表和所有的char,varchar 和 text 欄位改為gbk_chinese_ci ，修改後，phpmyadmin 裡面正常了，但是到頁面顯示確是亂碼了，公司原來的資料庫是 ms-sql server 2000 的現在要匯入到 mysql5，原來的 兩個漢字在匯入到 char(10)的時候 竟然報錯說是字元太長了，怎麼可能呢？一個字元按照UTF16也就4個位元組 最多才到8個位元組阿怎麼回事阿？網上有人說是由於編碼不當可能會把UTF8的編碼經過兩次轉換 變成一個漢字6個位元組儲存，具體是怎麼回事我也不清楚，不過後來經過多次實驗終於明白了原來Mysql存取編碼和查詢編碼並不一致，需要手動指定，也可以在 mysql 的設定檔裡指定編碼網上有人的解決辦法是：

      PHP源檔案使用的是UTF-8編碼 mysql 儲存用的是GBK編碼

     set character_set_client = utf8;  

     指明也即php程式發往資料庫的SQL語句使用的是UTF8編碼，如insert；

     set character_set_connection = GBK; 

     指明資料庫收到SQL語句之後應當將其從character_set_client轉碼為    

    utf8格式進行操作，如insert。（若沒有這一句，插入的資料將變成問號）

    set character_set_results = utf8;  

    指明資料庫查詢完畢之後應當以何種編碼返回給調用端，如select。

    現在終極解決辦法，php 檔案為UTF-8時的做法：在所有執行mysql_query函數做資料庫插入刪除查詢之前 執行下面三個命令：

    mysql_query('set character_set_client = utf8');

    mysql_query('set character_set_connection = GBK');

    mysql_query('set character_set_results = utf8');

    而不是以前的 set names utf8命令建立資料庫和建立表之時指定編碼為gbk ，指定 整理為：

     gbk_chinese_ci;

    CREATE DATABASE `test` DEFAULT CHARACTER SET gbk COLLATE gbk_chinese_ci;

    這樣你的網站永遠 都不會有亂碼問題了而且如果有一個欄位是 username char(20),這樣就可以插入20個漢字，而不是20/2或者 20/3之類如果插入的是20個漢字， select length(username)查看 會返回 40 ，也就是說，mysql 實際是用40個字元儲存的但是我們不用去管他實際的儲存，你想要限制多少就直接是指定char()多少就可以了，漢字和英文同樣對待。

本文來自CSDN部落格，轉載請標明出處：http://blog.csdn.net/microji/archive/2009/01/11/3753647.aspx