Nginx rewrite匹配中文路径乱码的本质是URI字节来源与解码视角不一致：浏览器发送UTF-8编码的%xx路径，Nginx默认URL解码后若被误作Latin-1处理（如显示测试），或文件系统中目录名为GBK字节而非UTF-8，均导致匹配失败；须统一使用ls -b验证字节、convmv转码文件名、设置系统LANG为UTF-8，并用$request_uri与$uri日志对比定位解码失真点。
Linux 下 Nginx 的 rewrite 指令匹配含中文的路径时出现乱码，本质不是 rewrite 本身出错，而是请求 URI 在进入匹配逻辑前已被错误解码或原始字节不合法——关键在“字节来源”和“Nginx 解码视角”是否对齐。
确认请求 URI 的原始编码是否为 UTF-8
浏览器对中文路径（如 /测试/）自动做 UTF-8 百分号编码，变成 /%E6%B5%8B%E8%AF%95/。Nginx 默认会对其 URL-decode，但解码后字节若被当作 Latin-1 处理，就会显示为乱码（如 测试）。
- 用
curl -v "http://localhost/%E6%B5%8B%E8%AF%95/"测试，确保发送的是标准 UTF-8 编码，而非直接传入未编码的中文（curl "http://localhost/测试/"不可靠，依赖终端编码） - 在 Nginx 日志中启用
$request_uri（原始请求行）和$uri（解码后路径），对比二者差异，判断是否在 decode 阶段已失真
避免 rewrite 中隐式重编码或误判
rewrite 是基于 $uri（已解码路径）进行正则匹配的。如果文件系统里实际是 GBK 字节命名，而 Nginx 把 %E6%B5%8B 当作 UTF-8 解码成字节序列后去匹配 GBK 文件名，必然失败或错配。
Zynq Linux Hardware Debug
下载
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
- 不要在 rewrite 规则里对
$args或$query_string做set或rewrite操作，防止二次 encode/decode 破坏 UTF-8 字节完整性 - 若需匹配中文路径做跳转，优先用
location = /%E6%B5%8B%E8%AF%95/这类精确匹配（未解码形式），或确保所有环节统一 UTF-8：文件名、系统 locale、Nginx 配置 - 调试时可在 rewrite 后加
return 200 "$uri → $request_uri";，观察实际传入的字节内容
统一底层环境与文件名编码
Nginx 不转码、不猜测，它只是按字节逐字匹配。路径能否命中，取决于磁盘上文件夹名的字节序列是否与解码后的 $uri 完全一致。
- 运行
ls -b查看目录名原始字节：显示\346\226\207\344\273\266是 UTF-8；若出现\243\306类似非 UTF-8 八进制，则大概率是 GBK，需转换 - 已有 GBK 文件名？用
convmv -f gbk -t utf-8 -r --notest /path/to/dir批量转为 UTF-8 - 确保系统 locale 为 UTF-8：
echo $LANG应输出类似zh_CN.UTF-8或en_US.UTF-8；否则在/etc/profile中设置export LANG=en_US.UTF-8并重载
配置层面加固 UTF-8 视角
仅加 charset utf-8; 不足以解决 rewrite 匹配问题，但它能影响响应头和浏览器解析逻辑，间接帮助定位问题。
- 在
http或server块中添加：charset utf-8; - 若开启
autoindex，必须配套charset_types text/html;或显式add_header Content-Type "text/html; charset=utf-8";，否则浏览器可能用错误编码渲染目录页，掩盖真实匹配结果 - 禁用可能干扰的模块行为：检查是否有第三方模块（如某些安全模块）对 URI 做预处理；关闭
underscores_in_headers on;等无关但易混淆的配置
