Base64 与 URL 编码指南

Base64 的用途和边界

Base64 常用于把二进制或 UTF-8 文本表示成 ASCII 字符串，例如调试 Authorization 头、处理小片段配置、查看简单编码内容。它不是加密，任何人都可以解码。把敏感密钥做 Base64 并不会提高安全性，只是改变了表示形式。

处理中文和 Emoji 时，应先把文本按 UTF-8 转成字节，再进行 Base64 编码。解码时也要按 UTF-8 还原。如果工具按旧的单字节方式处理，就可能出现乱码。URL-safe Base64 会把部分字符替换为更适合 URL 的形式，并可能省略 padding，解码时要注意自动补齐。

URL 编码的用途

URL 编码用于把中文、Emoji、空格、斜杠、问号、等号、井号等字符安全放进 URL 片段或查询参数中。开发中常见的问题是把完整 URL 和单个参数值混在一起编码。通常参数值应使用组件级编码，而不是把整个地址无脑处理。

解码时要小心非法百分号转义。比如孤立的百分号、长度不完整的转义片段，都可能导致解码失败。好的工具应该显示错误，而不是吞掉异常或悄悄改写输入。

中文、Emoji 和复制注意

中文和 Emoji 都需要明确字符编码。现代浏览器通常按 UTF-8 处理，这也是网页和接口最常见的选择。复制编码结果时，要确认是否需要保留换行、是否要使用 URL-safe Base64、是否需要 padding，以及结果是给人阅读还是给程序消费。

不要把编码结果当作安全保护。Base64 和 URL 编码都不能隐藏真实内容。调试 token、私有 URL、带签名参数的地址或包含用户信息的文本时，应避免把内容发给无关人员或公开贴到 issue、论坛和聊天群。

推荐使用方式

需要把文本转成 Base64 时，先确认输入是普通文本还是已经编码过的内容，再选择标准 Base64 或 URL-safe 模式。处理 URL 时，优先明确是在编码完整文本、单个查询参数，还是解码一个已有片段。结果异常时，不要反复叠加编码，先回到原始文本重新处理。