ThinkPHP 在 IIS 環境下中文參數亂碼終極解決方案

ThinkPHP 在 IIS 環境下中文參數亂碼終極解決方案

IIS + PHP 環境下，URL 傳遞中文參數（?id=中文）頻繁出現亂碼，根因在於瀏覽器編碼差異、IIS URL Rewrite 模塊編碼固化為 GBK、PHP 內部採用 UTF-8 多重編碼不一致。本文歸納兩類實戰有效方案。

現象復現

• 瀏覽器地址欄輸入 https://site.com/page?id=測試
• PHP $_GET['id'] 獲得亂碼（如 娴嬭瘯 或 %E6%B5%8B%E8%AF%95 雙重編碼）
• 360 瀏覽器（Chrome 內核）可能正常，IE/Edge 必現

方案一：前端 urlencode + 後端 urldecode（最通用）

核心原則：URL 標準僅允許 ASCII，中文必須百分號編碼後傳輸。

<!-- 模板/頁面生成鏈接時 -->
<a href="td.php?id=<?php echo urlencode('中文'); ?>">點擊</a>

<?php
// 接收頁
$id = urldecode($_GET['id']);
// 或 ThinkPHP 封裝
$id = urldecode(I('get.id'));
?>

• 適用於所有 Web Server（Apache/Nginx/IIS）
• 需業務代碼統一規範，避免漏編漏解

方案二：PHP 端編碼轉換修正（針對 IIS Rewrite/GBK 來源）

當無法控制前端（如第三方回調、舊系統跳轉、IIS Rewrite 直接將 GBK 編碼中文放入 URL）時，在入口文件或公共控制器統一轉碼：

<?php
// 入口文件 index.php 或 BaseController::_initialize()
if (!empty($_GET)) {
    foreach ($_GET as $key => $val) {
        if (is_string($val)) {
            // 嘗試從 GBK 轉 UTF-8
            $_GET[$key] = mb_convert_encoding($val, 'UTF-8', 'GBK');
            // 或 iconv
            // $_GET[$key] = iconv('GBK', 'UTF-8//IGNORE', $val);
        }
    }
}
// 同理處理 $_POST、$_REQUEST

適用場景：

• GBK 頁面跳轉到 UTF-8 頁面
• IIS URL Rewrite 重寫後的中文參數（Rewrite 固定按 GBK 解碼）
• 無法修改上游系統編碼時的兼容層

深度原理解析

最佳實踐清單

1. 統一規範：全站強制 UTF-8（頁面 <meta charset="utf-8">、PHP header('Content-Type: text/html; charset=utf-8')、資料庫 SET NAMES utf8mb4）。
2. 新建鏈接必編碼：模板輸出 URL 參數統一 urlencode()，封裝為模板函數 {:U('action', ['kw'=>$keyword])}。
3. 入口統一轉碼：在 index.php 最頂部加入方案二代碼，作為安全網。
4. 關閉 IIS Rewrite 中文處理：若不依賴 Rewrite 中文匹配，可在規則中避開中文或改用查詢字串傳遞。
5. 測試矩陣：IE/Edge/Chrome/360/手機瀏覽器各測一遍，確認無亂碼再上線。

避坑提醒

• header("Content-Type: text/html; charset=utf-8") 不解決 GET 參數亂碼，它只影響響應體編碼。
• iconv('GBK','UTF-8',$str) 遇到非法字節會報錯或截斷，建議加 //IGNORE 或用 mb_convert_encoding。
• POST 表單若 enctype="multipart/form-data" 且頁面 UTF-8，通常不亂碼；但 application/x-www-form-urlencoded 同樣受瀏覽器編碼影響，同理處理。

徹底解決 IIS 中文亂碼，關鍵在於「源頭編碼統一 + 傳輸強制編碼 + 入口兼容修補」三層防線。