Nginx 如何在 URL 重写时处理包含特殊中文字符的路径防止编码乱码

Nginx 中中文路径 rewrite 的关键是始终在 UTF-8 字节层面处理，因 Nginx 已自动解码 URI，正则应直接匹配解码后的 UTF-8 字节，配置文件须存为 UTF-8 无 BOM，PCRE 需支持 UTF-8，rewrite 后避免二次编码，调试须用 curl 和 debug 日志验证。

在 Nginx 中对含中文路径做 rewrite，关键不是“解码再重写”，而是让整个流程始终在 UTF-8 字节层面一致处理——Nginx 不会自动把 `%E6%B5%8B` 转成“测”再匹配，它只按原始字节（已解码后的 UTF-8 字节序列）进行正则匹配。乱码本质是字节错位，不是显示问题。

确保 rewrite 匹配的是已解码的 UTF-8 字节

Nginx 在执行 rewrite 前，已对请求 URI 做了一次标准 URL 解码（即把 %E6%B5%8B 变成对应 UTF-8 字节）。所以你的正则应直接面向这些字节写，而不是写编码后的字符串。

1. ✅ 正确示例（匹配中文“测试”）：

   rewrite ^/测试/(.*)$ /api/v1/$1 break;

   这要求配置文件本身用 UTF-8 编码保存，且终端、编辑器不插入 BOM 或混用 GBK

2. ❌ 错误写法：

   rewrite ^/%E6%B5%8B%E8%AF%95/(.*)$ ... —— Nginx 此时收到的已是解码后字节，不会再去匹配百分号编码串

规避 PCRE 版本与 UTF-8 支持风险

旧版 PCRE（

1. 检查 PCRE 是否支持 UTF-8：

   nginx -V 2>&1 | grep -o 'PCRE.*UTF-8'，应输出类似 PCRE library version: 8.45 2024-01-27 (UTF-8)

2. 若不支持，升级 Nginx 或使用 utf8 修饰符（Nginx ≥ 1.11.8）：

   rewrite ^/([^/]+)$ /index.php?path=$1 break; # 加 utf8 保证捕获完整汉字

   写为：rewrite ^/([^/]+)$ /index.php?path=$1 break; utf8;

避免 rewrite 后二次编码导致下游出错

rewrite 后跳转或 proxy_pass 时，Nginx 默认会对新 URI 再次编码（尤其含空格、括号等），可能把“测试.html”变成“%E6%B5%8B%E8%AF%95.html”，而有些后端又重复解码，引发双重解码错误。

1. 用 last 替代 redirect 或 permanent，避免 301/302 跳转触发浏览器再次编码
2. proxy 场景下，禁用自动编码：

   proxy_pass_request_headers off;

   并显式设置：

   proxy_set_header X-Original-URI $request_uri;

   让后端自己决定如何解析原始请求行

调试与验证方法

不要靠浏览器地址栏输中文来测试——它依赖客户端编码逻辑不可控。必须用已知编码的 curl 验证。

1. 用 curl -v "http://host/%E6%B5%8B%E8%AF%95/file.txt" 发送标准 UTF-8 编码请求
2. 开启 Nginx debug 日志：

   error_log /var/log/nginx/debug.log debug;

   查看 http uri: 行，确认解码后字节是否为你预期的 UTF-8 序列（如 uri: "/测试/file.txt"）

3. 配合 log_format 记录原始和解码后值：

   log_format debug '$request_uri → $uri';