好多次更換mysql主機商時,都要造成mysql資料的亂碼,因為網站開發曆史經曆了多個mysql版本,而且是在我剛剛學php時一點點做的,因為底層的東西很混亂,當時就沒有也不知道如何處理字串,今天決定好好的研究下它。mysql5提供了以下幾個設定字元集的系統變數:character_set_client 用戶端字元集character_set_connection 用戶端與伺服器端串連採用的字元集character_set_results SELECT查詢返回資料的字元集character_set_database 資料庫採用的字元集亂碼問題一般是由於以上幾個變數設定錯誤照成的,所以只要理解這幾個變數,就可以與告別亂碼了。使用上述變數,要理解這個核心思想: character_set_client,character_set_connection這兩個變數保證要與 character_set_database編碼的一致,而 character_set_results則保證與SELECT返回的結果與程式的編碼一致。我們可以在程式中使用 set names來同時設定character_set_client, character_set_connection, character_set_results這三個系統變數。
例如 set names 'utf8' 等同於 :
set @@character_set_client = 'utf8'
set @@character_set_connection = 'utf8'
set @@character_set_results = 'utf8'一般情況下,當資料庫與資料庫表的字元集為utf8,我們再在程式裡設定set names 'utf8'命令,這樣就能保證無亂碼了,但是,這裡還要注意character_set_results變數的值,character_set_results的字元值是用來顯示返回給使用者的編碼的。
例 如,你的資料庫(character_set_database)用的是utf8的字元集,那麼你就要保證 character_set_client,character_set_connection也是utf8的字元集。而你的程式也許採用的並不是 utf8,比如你的程式用的是gbk,那麼你若把character_set_results也設定為utf8的話就會出現亂碼問題。此時你應該把 character_set_results設定為gbk。這樣就能保證資料庫返回的結果與你的程式的編碼一致。
以下摘自網路的一程式段:
<?php
//假設我們的程式採用的是utf8的字元集
$program_char = 'utf8';
//先檢查mysql的版本號碼,如果版本號碼大於4我們才可以設定這些系統變數(mysql4還沒有這些系統變數)
$version = current($db->fetch_one('SELECT VERSION()'));
if (substr($version, 0, 1) > 4){
//取出當前資料庫的字元集
$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 . '"');
}
?>
1、要保證資料庫中存的資料與資料庫編碼一致,即資料編碼與character_set_database一致;
2、要保證通訊的字元集與資料庫的字元集一致,即character_set_client, character_set_connection與character_set_database一致;
3、要保證SELECT的返回與程式的編碼一致,即character_set_results與程式編碼一致;
4、要保證程式編碼與瀏覽器編碼一致,即程式編碼與<meta http-equiv="Content-Type" content="text/html; charset=?"/>一致。
本文來自CSDN部落格,轉載請標明出處:http://blog.csdn.net/piperzero/archive/2009/03/07/3964554.aspx