編程亂碼問題初步探索[2]

　　那麼set names是什麼呢？ set names實際上就是同時設置了character_set_clientcharacter_set_connectioncharacter_set_results這三個系統變量

　　例如set names gbk等同於

set @@character_set_client = gbk

set @@character_set_connection = gbk

set @@character_set_results = gbk

　　很多情況下這樣設置了之後就能把亂碼問題解決了但是還是不能完全避免出現亂碼的可能為什麼呢？

　　因為character_set_clientcharacter_set_connection這兩個變量僅用與保證與character_set_database編碼的一致而character_set_results則用與保證SELECT返回的結果與程序的編碼一致

　　例如你的數據庫(character_set_database)用的是utf的字符集那麼你就要保證character_set_clientcharacter_set_connection也是utf的字符集而你的程序也許采用的並不是utf比如你的程序用的是gbk那麼你若把character_set_results也設置為utf的話就會出現亂碼問題此時你應該把character_set_results設置為gbk這樣就能保證數據庫返回的結果與你的程序的編碼一致

　　下面我給出一段用於設置字符集的代碼(其中用到了一個我自己寫的db庫相信應該不影響閱讀)

<?

//假設我們的程序采用的是utf的字符集

$program_char = utf;

//先檢查mysql的版本號如果版本號大於我們才可以設置這些系統變量(mysql還沒有這些系統變量)

$version = current($db>fetch_one(SELECT VERSION()));

if (substr($version  ) > ) 

{

//取出當前數據庫的字符集

$sql = SELECT @@character_set_database;

$char = current($db>fetch_one($sql));

//將客戶端字符集(character_set_client)和
連接字符集(character_set_connection)設置為與數據庫字符集(character_set_database)一致

$db>query(SET @@character_set_client =   $char  );

$db>query(SET @@character_set_connection =   $char  );

//將SELECT查詢返回數據的字符集設置為與當前程序的字符集一致

$db>query(SET @@character_set_results =   $program_char  );

}

?>

　　到此應該就可以解決絕大多數我們遇到的亂碼問題了另外還必須強調的是有時候亂碼的出現有可能是以上幾種原因混合造成的

　　對於這樣的問題處理起來就比較的麻煩因為首先要保證你在數據庫中保存的數據的字符集與數據庫的字符集是一致的如果你在一個utf的數據庫中保存了GBK字符數據（如果你頁面的編碼與數據庫的編碼不一致那麼產生這個問題的可能性就很大）那麼假設以上的設置都正確結果還是會出現亂碼的問題不過這類問題一旦確定了產生的原因那麼就還是有辦法解決的比如剛才我舉的這個例子

　　我們如果能確保其他環節的設置都是正確的並且能夠確認是由於把gbk的數據存到了utf的數據庫中而造成的亂碼那麼我就可以把這些數據從數據庫中取出來之後再用iconv()轉換編碼也是可以的

　　總而言之我們應當盡量的保證數據庫中的數據是正確的那麼問題處理起來就相對簡單了

　　說了一大堆可能把你給弄迷糊了我將其總結為以下四點便於大家記憶

　　要保證數據庫中存的數據與數據庫編碼一致即數據編碼與character_set_database一致

　　要保證通訊的字符集與數據庫的字符集一致即character_set_client character_set_connection與character_set_database一致

　　要保證SELECT的返回與程序的編碼一致即character_set_results與程序編碼一致

　　要保證程序編碼與浏覽器編碼一致即程序編碼與<meta httpequiv=ContentType content=text/html; charset=？/>一致

[] []

From:http://tw.wingwit.com/Article/program/SQL/201311/16315.html