PHP 與 MySQL 開發中亂碼產生原因與徹底解決方案

Web 開發中亂碼問題核心在於三處編碼設置不一致：文件編碼、頁面聲明編碼、數據庫連接編碼。本文系統梳理常見場景與解決方案。

三大編碼關鍵點

1. 文件編碼：源碼文件（.php/.html）保存時的編碼格式。Zend Studio 等 IDE 不會自動識別，需手動配置，誤用編碼保存是常見禍首。
2. 頁面聲明編碼：HTML <meta http-equiv="Content-Type" content="text/html; charset=XXX"> 告訴瀏覽器解碼方式，中文站常用 GB2312/UTF-8。
3. 數據庫連接編碼：PHP 與 MySQL 通訊時的編碼，非數據庫存儲編碼。MySQL 默認 latin1，不同編碼傳輸會被轉換。

常見錯誤場景與解決

場景一：數據庫 UTF-8，頁面 GB2312（最常見）

查詢前執行：

mysql_query("SET NAMES GBK"); // GBK 為 GB2312 超集

頁面為 UTF-8 時：

mysql_query("SET NAMES UTF8"); // 注意：MySQL 中寫 UTF8 而非 UTF-8

若頁面編碼與數據庫內部編碼一致，可省略此步驟。

深層原理： SET NAMES 實際設置 character_set_client，告知服務器客戶端發送數據的編碼，而非使用 my.ini 中的默認值（[client] default-character-set、[mysqld] default-character-set）。

場景二：文件編碼與頁面聲明不一致

少見於開發階段（DW 會顯示亂碼），多發於：

• 發布後用錯誤編碼打開修改再保存
• FTP 工具（如 CuteFTP）編碼配置錯誤導致在線編輯轉碼錯誤

場景三：服務器全局編碼覆蓋頁面聲明

現象： 頁面聲明 GB2312，IE 仍識別為 UTF-8，手動切換後正常。

原因： Apache httpd.conf 設置 AddDefaultCharset UTF-8，HTTP Header 優先級高於 Meta 標籤。

解決：

1. 請管理員在虛擬主機配置添加 AddDefaultCharset GB2312
2. 或在項目根目錄 .htaccess 添加 AddDefaultCharset GB2312

最佳實踐建議

1. 統一使用 UTF-8：文件保存、頁面聲明、數據庫連接、數據庫表字符集全鏈路 UTF-8
2. IDE 配置固化：強制項目編碼為 UTF-8，禁用自動識別
3. 數據庫連接封裝：在 DB 連接類構造函數中自動執行 SET NAMES UTF8
4. HTTP Header 兜底：PHP 入口文件首行 header("Content-Type: text/html; charset=UTF-8");