URL 编码和 Base64 是一回事吗
一句话结论
不是。URL 编码只转义"在当前 URL 语境下不安全的字符"（空格变 %20，中文变 %E4%B8%AD），安全字符原样保留；Base64 是把任意二进制整体重新编码成纯文本，体积增加 33%。前者保证 URL 结构合法，后者保证二进制能塞进文本通道。
核心区别对照
| 目的 | URL 编码（百分号编码） | Base64 |
|---|---|---|
| 处理方式 | 只替换不安全字符，其余原样 | 整段重新编码，输出全是新字符 |
| 空格结果 | %20 | IA==（作为整串编码的一部分） |
| 可逆性 | 完全可逆 | 完全可逆 |
| 体积影响 | 仅被转义的字符膨胀 | 整体 +33% |
| 是否混淆内容 | 否，英文基本能读懂 | 是，肉眼不可读 |
| 典型场景 | 拼接查询参数、表单提交、分享链接 | Data URL、邮件附件、接口传文件 |
URL 编码（百分号编码）
规则很简单：字母数字和 - _ . ~ 保持原样，其余字节写成 % 加两位十六进制。空格变 %20，中文"中"的 UTF-8 是三个字节 E4 B8 AD，就变成 %E4%B8%AD。注意 query 参数和 path 部分的规则略有不同（空格在 query 里也可写成 +），用错会出现诡异的解码结果。
Base64
Base64 是把整段二进制按 6 bit 一组重新映射成可打印字符，与 URL 语境无关，也不管你原本是文本还是图片。它常用于 Data URL（data:image/png;base64,…）和在 JSON 里塞二进制。要注意标准 Base64 含 + 和 /，放进 URL 前必须换成 URL-safe 变体或再做一次 URL 编码。
怎么选
- 拼接 URL 查询参数、处理中文和空格 → URL 编码
- 在文本协议里携带图片 / 文件 → Base64
- 把 Base64 结果放进 URL → Base64 后再做一次 URL 编码，或直接用 URL-safe 变体
相关工具
常见问题
为什么有时候空格变成 + 有时候是 %20
在 query 字符串（? 后面）里，application/x-www-form-urlencoded 规则允许空格写成 +；在 path 部分必须写成 %20。混用会导致解码出错。
Base64 能直接放 URL 吗
标准 Base64 不能，因为 + 和 / 在 URL 里有特殊含义。要么换成 - 和 _ 的 URL-safe 变体并去掉补位等号，要么再套一层 URL 编码。
两者能组合使用吗
经常。典型流程是：文件 → Base64 → URL 编码 → 放进链接。顺序不能反，否则会得到错误结果。