ThinkPHP分页跳转乱码快速处理完整方案-ThinkPHP-PHP中文网

根本原因是iis将斜杠风格url中的中文当作路径解析并按gbk解码，导致php收到损坏数据；须修改page.class.php：将占位符替换改为直接替换，并用u(action_name).'?'.http_build_query($this->parameter)强制使用标准query string格式，同时前端传参前必须用encodeuricomponent()编码。

thinkphp分页跳转乱码快速处理完整方案

ThinkPHP 3.2 分页中文参数在 IIS 上乱码的根本原因

不是编码设置错了，也不是数据库或页面 charset 不对——是 IIS 对 URL 路径中 / 后面的查询参数解析方式和 Apache 不同。ThinkPHP 默认用 U() 生成带斜杠风格的 URL（如 /search/index/page/2/k/北京），IIS 会把中文部分当作路径而非 query string 处理，直接按系统默认编码（通常是 GBK）解码，再传给 PHP 时就已损坏。

Page.class.php 的两处关键修改（ThinkPHP 3.2.x）

必须改 ThinkPHP/Library/Think/Page.class.php 中的 show() 方法（通常在第 82 行附近）：

把 return str_replace(urlencode('[PAGE]'), $page, $this->url); 改成 return str_replace('[PAGE]', $page, $this->url); —— 避免双重编码导致 [PAGE] 占位符被误转义
把 $this->url = U(ACTION_NAME, $this->parameter); 改成：
```
$this->url = U(ACTION_NAME) . '?' . http_build_query($this->parameter);
```
—— 强制走 ?k=北京&page=2 这种标准 query string 形式，绕过 IIS 路径解析缺陷

前端传参前必须 rawurlencode()，不能只靠 U()

即使后端改了分页类，如果搜索表单提交的是未编码的中文，$_GET 仍可能收不到完整值。尤其在 Nginx 或某些 CGI 模式下，空格、加号、斜杠会被提前截断或转义。

PHP

编写健壮的PHP代码，规避类型转换陷阱、数组怪癖及常见安全漏洞。

下载

表单提交前，JS 中对每个中文参数值调用 encodeURIComponent()（等价于 PHP 的 rawurlencode()）
例如：location.href = '/search/index?' + 'k=' + encodeURIComponent('北京朝阳') + '&page=1';
绝对不要依赖浏览器自动编码，也不要对整个 query string 再套一次 encodeURIComponent()，否则 & 和 = 会被破坏

为什么不用 urldecode() 在控制器里补救？

因为乱码发生在 PHP 接收到 $_GET 之前——IIS 已把“北京”转成 %C1%F1%BE%A9（GBK 编码字节），而 PHP 默认按 UTF-8 解析这些字节，结果就是 ±д。此时 urldecode() 或 iconv('gbk', 'utf-8', $_GET['k']) 都无效，因为原始 UTF-8 字节早已丢失。

真正可靠的路径只有一条：从源头堵住，强制所有分页链接走 ? 查询字符串，并确保每个参数值在拼接 URL 前就用 rawurlencode() 安全编码。任何试图在控制器里“修复”乱码的操作，都是在处理已经损坏的数据。