ne标志用于禁止apache对重写后的url输出进行uri转义，防止%、$等字符被二次编码（如%3d变为%253d），确保重定向url中原始编码序列和特殊符号正确传递。
NE 标志必须显式加在 RewriteRule 的 flags 里，否则 Apache 默认会对 Substitution 中的 %、$、; 等字符做 URI 编码（如 %25 代替 %），导致重定向 URL 失效或参数错乱。
为什么需要 NE 标志
Apache 的 mod_rewrite 在生成重定向响应（比如 [R]）时，会自动对 Substitution 字符串中所有非安全 URI 字符进行百分号编码。这在多数场景下是安全行为，但当你明确要在输出 URL 中保留原始 %（比如传递已编码的中文参数）、$（如用于 cookie 值）或路径中带 ; 的 legacy 接口时，就会出问题。
典型错误现象包括：
- 本该跳转到
/bar?arg=P1/%3dvalue，结果变成/bar?arg=P1/%253dvalue（%3d被二次编码为%253d） - 前端传来的
?q=%E4%B8%AD%E6%96%87（UTF-8 编码的“中文”），经 rewrite 后变成?q=%25E4%25B8%25AD%25E6%2596%2587，后端无法 decode - 使用
RewriteRule构造含$符号的 query 参数（如token=$1），结果$被转成%24，破坏签名逻辑
NE 标志的正确写法和位置
NE 是 flag，只能出现在 RewriteRule 指令的第三个参数中，且必须与其他 flag（如 R、L、QSA）用逗号分隔。它不作用于 RewriteCond，也不影响匹配过程，只控制最终输出字符串是否被转义。
正确示例：
RewriteRule ^/old/(.*)$ /new?src=$1 [R=301,NE,L]
错误写法（常见坑）：
Apache Superset 是一个广泛采用的开源 BI 平台，用于 SQL 探索、图表构建和仪表板交付。当代理需要查询仓库数据、组装仪表板或使用成熟的分析界面解释指标而不是临时笔记本代码时，此技能非常有用。
-
RewriteRule ^/old/(.*)$ /new?src=$1 [R=301,L,NE]—— 顺序无关，但NE必须存在；这个写法本身没错，但容易漏掉 -
RewriteRule ^/old/(.*)$ /new?src=$1 [R=301,L] # missing NE—— 不加NE，$1中若含%就会被再编码 -
RewriteRule ^/old/(.*)$ /new?src=$1 [NE,R=301,L]——NE位置可变，但不能写成[noescape]或[NoEscape]，只认NE -
RewriteCond %{QUERY_STRING} ^a=(.*)$<br>RewriteRule ^/cms/ticket.php$ /ticket?x=%1 [R,NE]—— 这里%1来自RewriteCond，NE仍生效；但注意%1若本身含未编码字符，可能需额外处理
NE 和 QSA、B 标志的配合关系
NE 只管 Substitution 字符串本身的输出转义，不干涉 query string 的拼接逻辑。如果你同时用了 QSA（Query String Append），它会把原始 query string 原样追加到新 URL 后，此时 NE 对那部分不生效——也就是说，QSA 拼上的内容仍可能被编码，除非你也确保原始 query string 已是合法 URI 格式。
另一个常被混淆的是 B（escape backreferences）标志：它作用于 $N 反向引用，对其中的特殊字符提前编码，防止注入；而 NE 是“解禁”最终输出，两者目的相反，一般不共存。误用 B + NE 容易导致双重编码或解码失败。
建议组合：
- 转发已知干净的参数（如 ID、数字）→ 单独用
NE即可 - 转发用户输入的原始 query → 先用
B编码$N，再用NE防止 rewrite 引擎二次编码（慎用，需确认后端能 decode） - 构造含固定
%xx的路径（如兼容旧系统）→ 必须用NE，且确保%xx是合法 UTF-8 编码序列
验证 NE 是否生效的最快方式
直接 curl 测试重定向响应头，看 Location 字段内容是否含原始符号：
curl -I http://yoursite.com/old/test%3d1
如果返回的 Location: /new?src=test%3d1，说明 NE 生效；若返回 Location: /new?src=test%253d1，说明被二次编码，NE 缺失或位置错误。
注意：NE 不解决后端 decode 失败的问题——它只保证 Apache 输出的 URL 字符串没被多 encode 一次。如果后端收到 %253d 却按 %3d 解，那是应用层逻辑问题，和 rewrite 无关。
