什么是 URL 编码

URL（URI）是一套 简短的文本定位规则。为了在解析时有稳定、可预测的边界，标准规定了一批 保留字符（例如 ?、#、/、&）：它们在整条 URI 中承担「语法」角色而非随意数据。百分号编码（percent-encoding） 就是最常用的办法——用形如 %20 的序列在字符流中表示原始字节。

现代实践中，通用语法多参考 RFC 3986；具体方案（scheme）还可能补充自己的约定。人们常说「URL 编码」，但更准确的说法是：对若干字节做百分号转义，并不是发明一套全新的「URL 字母表」。

保留字与未保留字

在未保留场景中，下面这些字符常被允许以字面形式出现：

A–Z  a–z  0–9  -  _  .  ~

保留字符则往往承担 语法功能，例如分段、标记查询起点、分隔参数等：

: / ? # [ ] @ ! $ & ' ( ) * + , ; =

某个保留字是否「必须编码」取决于你正在编辑 URI 的 哪个部件（方案、authority、路径、查询、片段）。学习者只需抓住原则：当它应当被理解为数据而非标点时，就应当编码，以免被解析器误读。

非 ASCII 为何会变成一串 %HH

历史上 URL 以 US-ASCII 为常态。超出 ASCII 的字符（café、北京、😀）通常先转为 UTF-8 字节序列，再将需要转义的字节写成 %HH。

空格 → 常以 %20 表示
「é」(U+00E9，UTF-8 两字节) → %C3%A9

解码器在遇到 % 时读取十六进制字节，恢复原字节序列，再按约定（常为 UTF-8）还原 Unicode 字符串。

编码不是加密

百分号编码只改变 表示形式，不提供保密性，任何人都可以解码。把它当成 传输与解析层面的转义，类似 HTML 转义——而不是安全防护手段。

https://example.com/search?q=café
具体工具链里可能表现为 q=caf%C3%A9（UTF-8 字节被转义）

典型需要编码的场景

• 空格出现在路径或查询值中而被误拆。
• & 本应属于参数取值（例如 Tom & Jerry），却被当成下一参数的分隔。
• /、? 等作为 标识符内容出现时，会与路径或查询起始符冲突。
• 国际化域名走 IDNA Punycode（另一套转换），与路径/查询中的 % 转义同属「让文本安全进 URL」，但层次不同。

理解「哪里有结构分界、从哪里开始是纯数据」，是正确处理 URI 的起点；后续课时会把 %XX 的细则与常用 API 补齐。