URL 编码

两种编码，两个任务 Base64 和 URL 编码都会把「不安全」的字符替换成安全字符。这种表面相似，正是它们经常被搞混的原因——要么该用一种却用了两种，要么干脆用错了。 一句话版本： Base64 让二进制数据能通过只支持文本的通道 百分号编码 让文本能安全地放进 URL 各自到底做了什么 Base64 用 64 个字符的字母表（A–Z a–z 0–9 + /，末尾用 = 补齐）重写字节。每 3 个字节变成 4 个字符，体积因此增加约 33%。 Man → TWFu Hello → SGVsbG8= 百分号编码把在 URL 里不安全的字符替换成 % 加两位十六进制数（对应 UTF-8 字节）。 a b → a%20b 书签管理 → %E4%B9%A6%E7%AD%BE%E7%AE%A1%E7%90%86 a&b → a%26b 关键区别 Base64 百分号编码 目的 让二进制穿过文本通道 让文本安全地待在 URL 里 字符集 固定的 64 个字符 任意字节，写成 %XX 体积变化 +33% 变化很大 谁能还原 任何人 任何人 提供安全性 否 否 常见位置 JSON 字段、data URI、邮件附件、JWT 查询参数、路径片段 什么时候用 Base64 把小块图片以 data URI 内嵌进 CSS 或 HTML 在 JSON 里传文件、缩略图或签名 通过 MIME 发邮件附件 构造 Authorization: Basic 请求头 JWT 的 header 与 payload 段 需要双向转换时，直接用 Base64 编解码工具，不用装任何东西。 ...

一个典型的坏链接 你拼了一个搜索链接，英文下一切正常，用户一输入中文就崩： https://example.com/search?q=书签管理 & page=2 服务器收到的 q 是 书签管理 ，还多了一个叫 page 的参数——本该属于查询值的 & 被当成了分隔符。#、=、?、+ 和空格也有同样的问题。 解决办法是百分号编码（URL 编码）：把不安全字符替换成 % 加两个十六进制数字，表示它的 UTF-8 字节。 书签管理 → %E4%B9%A6%E7%AD%BE%E7%AE%A1%E7%90%86 & → %26 空格 → %20 哪些字符是安全的 RFC 3986 把字符分成"未保留"和"保留"两类，只有未保留字符可以原样出现： 类别 字符 说明 未保留 A–Z a–z 0–9 - _ . ~ 任何位置都安全 保留（结构类） : / ? # [ ] @ 在 URL 中有结构含义 保留（子分隔符） ! $ & ' ( ) * + , ; = 在查询串中有含义 其他 空格、"、<、>、%、{}、中文… 必须编码 保留字符不是"不能用"，而是"有含义"。关键问题永远是：这个 & 是想表达结构，还是想表达数据？如果是数据，就编码它。 ...