ThinkPHP处理中文需分场景精准转码：URL参数用rawurlencode编码、请求体用mb_convert_encoding按检测编码转换、数据库设utf8mb4并统一UTF-8响应，任一环节缺失均导致乱码。
ThinkPHP 中处理中文符号字符的编码转换，核心不是“能不能转”，而是“在哪转、怎么转、转完怎么用”。直接在 URL 里塞中文会触发 400 错误或被服务器截断；不加处理地传进数据库或模板，又容易乱码。关键在于分清场景：URL 参数传递、HTTP 请求接收、数据库写入、模板输出——每个环节的编码责任不同，不能只靠一个 urlencode 打天下。
URL 中文参数必须做安全编码，urlencode 或 rawurlencode 是底线
ThinkPHP 的 url() 函数本身不自动编码参数值，遇到中文会原样拼接，导致 URL 非法。浏览器可能自动 encode，但行为不可控，Nginx/Apache 也可能拒绝解析。
-
urlencode()把空格转成+，斜杠/和问号?不编码，适合 query string 场景，但要注意后端必须用urldecode()还原 -
rawurlencode()更严格，空格也转成%20，且对所有非字母数字字符统一按%XX编码，兼容性更好，推荐用于 ThinkPHP 路由参数 - 别用
base64url_encode()替代——它不是标准 URL 编码，且 ThinkPHP 路由层不会自动识别并解码，你得手动在控制器里调base64url_decode()，徒增出错点
示例：
$url = url('index/detail', ['title' => rawurlencode('用户反馈：含特殊符号！')]);
接收 GET/POST 中文时，mb_convert_encoding 比 iconv 更稳
用户从 GBK 页面提交表单，或前端 JS 用 encodeURIComponent 发送 UTF-8 字符串，后端收到的原始字节流编码不确定。ThinkPHP 默认以 UTF-8 解析请求体，但若原始数据是 GBK，就会变成乱码字节串，后续任何 decode 都救不回来。
立即学习“PHP免费学习笔记（深入）”；
- 先用
mb_detect_encoding($str, ['UTF-8', 'GBK', 'BIG5'], true)猜原始编码（注意第三个参数true表示 strict 检测） - 再用
mb_convert_encoding($str, 'UTF-8', $detected)统一转为 UTF-8 存储或使用 - 避免直接用
iconv('GBK', 'UTF-8', $str)——遇到非法字节会警告甚至失败，而mb_convert_encoding对损坏数据更宽容 - ThinkPHP 的
input()函数返回值默认不做编码转换，必须自己包一层
示例：
$title = input('get.title');<br>$title = mb_convert_encoding($title, 'UTF-8', mb_detect_encoding($title, ['UTF-8', 'GBK'], true) ?: 'UTF-8');
数据库和模板输出必须保持 UTF-8 一致性，否则转码全白搭
哪怕 URL 和请求参数都正确编码了，如果数据库连接用的是 SET NAMES 'gbk'，或者 HTML 响应头没声明 charset=utf-8，中文照样显示为 。
- MySQL 连接后立刻执行
Db::execute("SET NAMES 'utf8mb4'")（注意是utf8mb4，不是utf8） - 模板中确保有
<meta charset="utf-8">，且 PHP 输出前没被 header 覆盖 - ThinkPHP 的
view输出默认走 UTF-8，但若你在控制器里用了echo或print输出中文，要确认脚本文件本身保存为 UTF-8 无 BOM - 不要在模型 save 前手动
iconv('GBK', 'UTF-8', $data)——如果数据库连接已设对，TP 会自动处理；手动转反而可能重复转码
特殊符号（如 emoji、破折号、全角标点）需额外留意 utf8mb4 支持
普通中文汉字在 UTF-8 下占 3 字节，但 emoji 和部分 Unicode 符号（如 ?、——、「」）需要 4 字节。MySQL 默认 utf8 只支持最多 3 字节，存进去会被截断或报错。
- 数据库表字段必须用
utf8mb4字符集，排序规则选utf8mb4_unicode_ci或utf8mb4_0900_as_cs - 连接配置里
'charset' => 'utf8mb4'必须显式指定，不能依赖SET NAMES - ThinkPHP 的
config/database.php中，dsn后追加;charset=utf8mb4更可靠 - 用
mb_strlen($str, 'UTF-8')判断长度，别用strlen()——后者按字节算，emoji 会算成 4，导致截断逻辑出错
真正麻烦的从来不是“怎么转”，而是“谁该负责哪一段”——URL 编码是前端或路由层的事，请求体解码是控制器的事，数据库存储是连接配置的事，模板渲染是响应头和文件编码的事。漏掉任一环，前面所有转码都可能失效。
