摘要：在前端开发与安全测试中，我们常看到 URL 参数被自动转换成 % 开头的乱码。很多人误以为这是某种安全加密或 XSS 防御机制，但事实并非如此。

本文将从 RFC 标准出发，解析 URL 编码的底层逻辑、触发时机以及它与 Web 安全的真实关系。

1. 现象还原

在进行 Web 安全测试（如 XSS 注入）时，我们尝试在 URL 参数中输入 HTML 标签：

http://localhost:8080/api?name=<b>test</b>

然而，当我们查看网络请求（Network）或地址栏时，发现它变成了：

http://localhost:8080/api?name=%3Cb%3Etest%3C%2Fb%3E

初学者容易产生两个误区：

1. 误区一：这是浏览器在帮我拦截 XSS 攻击。

2. 误区二：后端收到的就是乱码，需要手动写代码解码。

真相是：这只是 HTTP 协议为了“交通合规”做的标准动作，与安全防御毫无关系。

2. 为什么要编码？（RFC 3986 标准）

URL（统一资源定位符）的设计初衷是只能通过 ASCII 字符集在互联网上传输。为了避免歧义和保证传输安全，IETF 在 RFC 3986 标准中将字符分为了三类：

2.1 绝对安全的字符（Unreserved）

不需要编码，走到哪里都是原样。

• 包含：A-Z a-z 0-9 以及 - _ . ~

• 注意：很多开发者不知道波浪号 ~ 其实是不需要编码的。

const param = "A&B"; // 参数值里带了 &


// ❌ 错误做法
const url1 = "http://api.com?q=" + encodeURI(param);
// 结果: ...?q=A&B  -> 后端解析为 q="A", 剩下的 B 成了无效部分


// ✅ 正确做法
const url2 = "http://api.com?q=" + encodeURIComponent(param);
// 结果: ...?q=A%26B -> 后端正确解析为 q="A&B"