Base64 详解：编码，不是加密

Base64 究竟是什么

Base64 把二进制字节映射到 64 个可打印 ASCII 字符（A–Z、a–z、0–9、+、/）再加上 = 填充，这样任意二进制内容就能在只处理文本的系统里传输，比如邮件、JSON 和 URL。它是一种表示形式，就像把数字十写成 "10" 而不是一串划痕。

编码不是加密

要记住的就是这句话：任何人都能在几秒内把 Base64 还原回去。 任何在线工具、任何开发者、任何偶然看到的人都能解码。在机密前面加一句「已编码」，对你的安全性毫无帮助。如果你需要保密，就用带密钥的真正加密；如果你需要防篡改，就用签名或哈希。

标准版与 URL 安全版

普通 Base64 会用到 +、/ 和 =，而这些字符在 URL 里有含义。URL 安全版把 + 换成 -、把 / 换成 _，并去掉末尾的 = 填充。JWT 就是例子，它的三段都用 Base64 URL 编码。这就是 JWT 里从来不会出现字面量 + 的原因。

UTF-8 那个坑

一个经典 bug：用假定 Latin-1 的工具去编码 中文，得到的字符串解码回来是乱码。正确的工具会先把字符串转成 UTF-8 字节（TextEncoder），再从 UTF-8 字节解码（TextDecoder）。ToolsKit 的 Base64 工具在两个方向上都这么做，所以中文、emoji 和带重音的文本都能原样往返。

你会在哪里遇到它

• JWT 的 header 段和 payload 段。
• 在 HTML 和 CSS 里以 data: URI 形式内嵌的小图片和字体。
• 以 MIME 形式存在的邮件附件。
• 把二进制数据存进只支持文本的列或缓存。

试一次往返

把 5Lit5paH 粘进 ToolsKit 的 Base64 解码器，它按 UTF-8 读出来就是中文。然后编码你自己的一段文本，再解码回来，确认得到的和最初一字不差。如果有同事哪天说「我们 Base64 一下就安全了」，你现在有更好的说法可以回他。