用Perl通過dbi寫Mysql資料庫時,如果內容的編碼方式與系統的編碼方式不一致,資料庫中就會出現亂碼
結果方法如下:
在串連資料庫後,寫入資料前,設定串連參數
$dbh->do("SETNAMES 'GBK'");
原因說明來自下面這篇文章:
http://blog.csdn.net/class1/archive/2006/12/30/1469298.aspx
先說MySQL的字元集問題。Windows下可通過修改my.ini內的
- # CLIENT SECTION
- [mysql]
- default-character-set=utf8
- # SERVER SECTION
- [mysqld]
- default-character-set=utf8
這 兩個欄位來更改資料庫的預設字元集。第一個是用戶端預設的字元集,第二個是伺服器端預設的字元集。假設我們把兩個都設為utf8,然後在MySQL Command Line Client裡面輸入“show variebles like “character_set_%”;”,可看到如下字元:
character_set_client latin1
character_set_connection latin1
character_set_database utf8
character_set_results latin1
character_set_server utf8
character_set_system utf8
其 中的utf8隨著我們上面的設定而改動。此時,要是我們通過採用UTF-8的PHP程式從資料庫裡讀取資料,很有可能是一串“?????” 或者是其他亂碼。網上查了半天,解決辦法倒是簡單,在串連資料庫之後,讀取資料之前,先執行一項查詢“SET NAMES UTF8”,即在PHP裡為
- mysql_query("SET NAMES UTF8");
即可顯示正常(只要資料庫裡資訊的字元正常)。為什麼會這樣?這句查詢“SET NAMES UTF8”到底是什麼作用?
到MySQL 命令列輸入“SET NAMES UTF8;”,然後執行“show variebles like “character_set_%”;”,發現原來為latin1的那些變數“character_set_client”、 “character_set_connection”、“character_set_results”的值全部變為utf8了,原來是這3個變數在搗 蛋。查閱手冊,上面那句等於:
- SET character_set_client = utf8;
- SET character_set_results = utf8;
- SET character_set_connection = utf8;
看看這3個變數的作用:
資訊輸入路徑:client→connection→server;
資訊輸出路徑:server→connection→results。
換 句話說,每個路徑要經過3次改變字元集編碼。以出現亂碼的輸出為例,server裡utf8的資料,傳入connection轉為latin1,傳入 results轉為latin1,utf-8頁面又把results轉過來。如果兩種字元集不相容,比如latin1和utf8,轉化過程就為無法復原的, 破壞性的。所以就轉不回來了。
但這裡要聲明一點,“SET NAMES UTF8”作用只是臨時的,MySQL重啟後就恢複預設了。
接 下來就說到MySQL在伺服器上的配置問題了。豈不是我們每次對資料庫讀寫都得加上“SET NAMES UTF8”,以保證資料轉送的編碼一致?能不能通過配置MySQL來達到那三個變數預設就為我們要想的字元集?手冊上沒說,我在網上也沒找到答案。所以, 從伺服器配置的角度而言,是沒辦法省略掉那行代碼的。
總結:為了讓你的網頁能在更多的伺服器上正常地顯示,還是加上“SET NAMES UTF8”吧,即使你現在沒有加上這句也能正常訪問。