PHP連線資料庫時常見的編碼問題為何？

Question

PHP連線資料庫時常見的編碼問題為何？一個典型問題是資料庫連線未正確設定字元編碼，導致中文或特殊符號出現亂碼。例如使用 mysqli 或 PDO 時，若未在連線後立即執行 `SET NAMES utf8` 或對應的編碼設定，即使資料庫本身為 UTF8 編碼，PHP 傳輸資料時仍可能因編碼不一致而產生問題。此問題常見於本地環境與生產環境間的差異，開發者易忽略初始化設定，進而導致資料讀取或儲存時出現問號（??）或亂碼字元。

Answer 1

一、PHP連線資料庫時常見的編碼問題為何？

在現代Web開發中，PHP與資料庫（如MySQL）的互動極為頻繁。當涉及多語言內容（如中文、日文等）或特殊符號時，字元編碼（Character Encoding）成為影響資料正確儲存與顯示的核心因素之一。一個典型的問題是：即使資料庫本身設定為UTF8或utf8mb4編碼，若PHP在建立資料庫連線時未正確初始化字元集，仍會導致亂碼或問號（??）出現。

1. 基礎層面：什麼是編碼不一致？

• 資料庫伺服器使用utf8mb4編碼儲存資料
• 客戶端（PHP應用）以latin1或其他非UTF-8編碼發送查詢
• 結果：資料寫入時被錯誤解碼，讀取時無法還原原始內容
• 典型症狀：中文變為「???」、「文字」等亂碼

此類問題往往出現在開發環境與生產環境配置差異時，例如本地使用XAMPP預設latin1，而雲端資料庫為UTF8。

2. 技術深層剖析：三層編碼一致性模型

要徹底解決亂碼問題，必須確保以下三個層級的編碼一致：

層級	元件	建議設定
1	資料庫與資料表	CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci
2	資料庫連線	執行SET NAMES utf8mb4或驅動內建選項
3	PHP輸出入	頁面輸出Content-Type: text/html; charset=UTF-8

3. 實際案例分析：從現象到診斷

假設某系統儲存使用者留言包含表情符號（Emoji），但顯示時變成問號。排查流程如下：

1. 確認資料表結構：SHOW CREATE TABLE messages;
2. 檢查欄位是否為utf8mb4而非僅utf8（MySQL舊版utf8不支援4位元組Unicode）
3. 查看目前連線字元集：SELECT @@character_set_client, @@character_set_connection;
4. 驗證PHP是否在連線後執行SET NAMES utf8mb4
5. 檢視HTTP回應頭是否包含正確的Content-Type

4. 解決方案：針對不同資料庫驅動的實作方式

根據使用的擴展，設定方式有所不同：

4.1 使用 MySQLi 時的正確做法

$mysqli = new mysqli("localhost", "user", "password", "database");
if ($mysqli->connect_error) {
    die("Connection failed: " . $mysqli->connect_error);
}
// 必須立即設定字元集
$mysqli->set_charset("utf8mb4");
// 或執行 SQL：$mysqli->query("SET NAMES utf8mb4");

4.2 使用 PDO 時的推薦配置

$dsn = "mysql:host=localhost;dbname=database;charset=utf8mb4";
$options = [
    PDO::ATTR_ERRMODE => PDO::ERRMODE_EXCEPTION,
    PDO::ATTR_DEFAULT_FETCH_MODE => PDO::FETCH_ASSOC,
];
try {
    $pdo = new PDO($dsn, $username, $password, $options);
} catch (PDOException $e) {
    die("Connection failed: " . $e->getMessage());
}

PDO優勢在於可在DSN中直接指定charset，避免遺漏。

5. 高階議題：自動化與環境差異管理

在CI/CD流程中，應透過以下方式減少人為疏失：

graph TD A[開發環境] -->|統一docker-compose.yml| B(MySQL with utf8mb4) C[測試環境] -->|部署腳本自動執行| D[ALTER DATABASE ... CHARACTER SET] E[生產環境] -->|監控工具檢查| F[character_set_* 變數] G[PHP應用] -->|初始化階段| H[強制設定連線編碼]

6. 常見陷阱與最佳實踐

• 陷阱1：誤用utf8而非utf8mb4 — MySQL的utf8實際只支援3位元組，無法儲存Emoji
• 陷阱2：僅設定資料表編碼，忽略連線層
• 陷阱3：使用iconv或mb_convert_encoding事後補救，治標不治本
• 最佳實踐：所有環境採用相同字元集策略，並於CI流程加入編碼驗證測試