在 nginx 的 rewrite 指令中处理特殊字符的 url 编码，核心策略是利用正则表达式捕获未解码的原始路径，并通过替换规则中的转义序列还原或转换这些字符。nginx 默认会对 uri 进行解码，导致 %2f（斜杠）等字符变为普通字符，从而破坏路径结构。通过匹配 (.*) 并配合 $1 反向引用，可以保留原始输入；若需将已解码的特殊字符重新编码，则需在替换字符串中使用特定的十六进制转义格式，如 %252f 来代表字面量的 %2f。
如何捕获包含 %2F 的原始 URI 路径
当 URL 中包含被编码的斜杠 %2F 时，Nginx 内部会将其实体化为路径分隔符，导致正则匹配失效。要解决这个问题，必须使用 ~ 修饰符启用正则匹配，并直接捕获整个 $uri 变量。由于 $uri 已经是解码后的状态，直接匹配 %2F 是无效的。正确的做法是匹配解码后的实际字符，或者在更上游的 location 块中拦截。但在 rewrite 阶段，我们通常假设需要处理的是“看起来像编码但已被解析”的情况，或者我们需要将某些特定字符重新编码。对于 %2F，最稳妥的方式是在 location 层面使用 if 或 map，但若必须在 rewrite 中处理，通常是指处理那些未被 Nginx 自动解码的字符，或者我们需要对解码后的内容进行二次编码。这里演示一个常见场景：用户传入 /path/%2Fsub，Nginx 将其视为 /path/sub。如果我们希望将其重写为 /new/path%2Fsub（即保留编码），我们需要知道原始输入。然而，rewrite 无法直接获取原始请求行。因此，标准做法是使用 $request_uri 变量，它保留了原始的、未解码的 URI。通过正则捕获 $request_uri，我们可以精确地提取包含 %2F 的部分。
server {
listen 80;
server_name example.com;
location / {
# 捕获原始 URI 中包含 %2F 的路径
rewrite ^(/.*%2F.*)$ /processed$1 last;
}
}
上述配置中，$request_uri 包含了完整的查询字符串前的原始 URI。正则 (/.*%2F.*) 会匹配任何包含 %2F 的路径。替换部分 /processed$1 将原始编码后的路径附加到 /processed 之后。这样，下游应用服务器就能接收到包含 %2F 的完整字符串，而不是被 Nginx 分解后的路径。注意，last 标志会触发新的请求循环，Nginx 会再次解析这个新 URI，此时 %2F 仍会被解码，除非下游应用自行处理。如果目的是让 Nginx 转发时保持编码，通常需要在代理层设置 proxy_pass 时使用 $request_uri 而非 $uri。
如何将解码后的特殊字符重新编码为 %XX 格式
有时我们需要将 URL 中某些已解码的特殊字符（如空格、中文或特定符号）重新编码，以便符合后端 API 的要求。Nginx 的 rewrite 指令本身不支持动态编码函数，但可以通过替换规则中的硬编码转义或利用 map 模块结合 return 来实现。对于简单的字符映射，可以直接在替换字符串中使用 %XX 格式。例如，将路径中的空格（在 $uri 中可能表现为 %20 或实际空格）转换为 %20。如果 $uri 中已经是解码后的空格，我们可以尝试匹配空格并替换为 %20。然而，Nginx 的正则引擎在处理 $uri 时，空格通常已经被转换为 %20 或保持为空格，取决于编译选项。更可靠的方法是使用 map 模块预处理，或者在 rewrite 中使用 break 和 return 组合。这里展示一种在 rewrite 中手动构建编码字符串的技巧：通过捕获各个部分并插入固定的编码序列。
server {
listen 80;
server_name example.com;
location /api/ {
# 假设我们要将路径中的 ' ' (空格) 重新编码为 %20
# 注意：在大多数 Nginx 配置中，$uri 里的空格已经是 %20
# 此例演示如何将特定字符 'a' 替换为编码形式 '%61'
rewrite ^/api/(.*)/(.*)$ /api/$1/%61$2 break;
}
}
在这个例子中，我们将路径中间的 / 分隔的两个部分捕获，并在第二部分前插入 %61（即字符 'a' 的 URL 编码）。这证明了可以在替换字符串中直接使用 %XX 序列，Nginx 会将其作为字面量传递给后续处理。如果需要编码多个字符，可以重复此模式。需要注意的是，%XX 在替换字符串中被解释为 URL 编码，因此在最终发出的请求中，这些字符会被正确编码。如果使用 last 标志，Nginx 会重新解析 URI，可能导致双重编码，因此建议使用 break 以停止当前重写循环并继续执行后续配置。
基于 $request_uri 与 $uri 差异的具体问题
在 Nginx 配置中，$request_uri 和 $uri 的关键区别在于前者保留原始请求的编码状态，而后者是经过 Nginx 内部解码后的标准化路径。当处理包含特殊字符的 URL 时，选择错误的变量会导致数据丢失或路径错误。例如，请求 /test/a%2Fb，$request_uri 的值为 /test/a%2Fb，而 $uri 的值为 /test/a/b。如果在 rewrite 中使用 $uri 并试图匹配 %2F，将无法命中，因为该字符已被转换为 /。反之，如果使用 $request_uri，则可以准确捕获 %2F。这一差异决定了在处理需要保留原始编码的 URL 时，必须优先使用 $request_uri。此外，$request_uri 包含查询字符串，而 $uri 不包含，这在构建重定向目标时也需要特别注意，通常需要手动拼接 $query_string。
