第 4 课
URL 与 Data URI 中的 Base64
标准与 URL-safe 变体，以及 `data:` 协议用法。
在 URL、查询串以及与 Cookie 相关的通道里，+ 与 / 常常被错误解释；末尾的 = 填充 也容易在拼接逻辑里被破坏。为了解决这些问题，就出现了 URL 友好型（常称 Base64URL） 字母表与子集用法。
本节区分 MIME/Base64, RFC 4648 的 URL-safe, 以及 data: 资源内联的常见实践。
标准字母表 vs URL-safe 字母表
传统 Base64 用 62 → '+'、63 → '/'。
常见的 URL-safe 方案会：
- 把
+'改成'-' - 把
/'改成'_' - 在 所遵循的标准允许时，省略末尾
=（例如 JWT 的 JWS 片段通常不带填充）
编码端和解码端的字母表必须一致。若在路径里直接塞进仍含 +// 的 MIME Base64却没做百分号编码，就会出现“间歇性坏的链接”。反过来，把一个本该用 Base64URL 的令牌拿去当 PEM MIME 解码，也一定会失败。
仍然可能需要百分号编码
即便换成 -/_，在 严格的 URL 解析场景（不同框架的参数解析、模板引擎、手工字符串拼接）里仍可能因为其它边界而出问题。应尽量使用 URLSearchParams、服务端 URL 组装库等结构化 API，而不是在裸字符串外面硬套分隔符。
与 JWT 的心智自检
JWT 的头/载荷部分是 UTF-8 的 JSON 字节 → Base64URL（常用无填充）。如果你看到的是大量 +//，多半是 MIME/PEM 风格，不要混在同一套解码流程里想当然。
data: URI
在 HTML/CSS 中内联非常小的二进制：
data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAA...
结构要点：
| 片段 | 含义 |
|---|---|
| MIME 类型提示 | 帮助浏览器解释字节语义 |
;base64, | 标记后面是经过 Base64 的字节载荷 |
| 载荷本体 | 往往很长的一段连续 ASCII |
优点：原型阶段少一次 HTTP，小图标更省事。
缺点：
- 体积约为原始字节的 ~4/3，源码膨胀明显；
- CSP、邮件客户端、某些爬虫环境可能限制；
- 与打包拆图、CDN 缓存等工程策略相悖。
正式上线里，哈希静态资源 + CDN 往往更稳妥——并不是因为 Base64 “错了”，而是因为 缓存、体积与工作流程综合来看更划算。
超大的 data:
极大的 data: 会拖累编辑器与大 DOM。Web 平台里对大文件更常见的是 Blob + object URL 或分块下载，而不是把整个文件 Base64 进页面。
要点小结
URL 场景同时考验 字符集是否“路径/查询友好” 与 填充是否稳定。按 规范选择变体（JWT、PEM、MIME 各不相同），并统一走 库函数 做转换——避免随手 replace 几个字符却忘了边界字节的错误。