什么是 Base64 编码？简明英语指南（以及为什么它不是加密）
您已经看到过：一长串字母和数字，可能以一个或两个等号结尾，位于 JWT、电子邮件源或图像标签中。这就是 Base64，它是计算中最常见的编码之一，令人惊讶的是，有数量惊人的开发人员每天都在使用这种编码，但他们不知道它实际上做了什么，或者更糟糕的是，相信它做了一些实际上没有做的事情。本指南用简单的英语解释了 Base64：它是什么、它为何存在、您将在哪里遇到它，以及导致真正安全事件的一个危险的误解。
Base64 实际上是什么
Base64 是一种表示二进制数据（任何字节）的方法，仅使用 64 个可打印文本字符：26 个大写字母、26 个小写字母、10 个数字和两个符号，即加号 (+) 和斜杠 (/)。等号 (=) 用作末尾的填充。这就是整个字母表，也是名字的由来。 Base64 输出中的每个字符都是安全的、可打印的字符，没有控制代码或不明确的空格，这正是重点。
它存在的原因是历史性的并且仍然具有现实意义。互联网的核心协议、SMTP 电子邮件、HTTP 标头等都是为纯文本设计的。向它们提供原始二进制数据（例如图像或加密的 blob），某些字节值会被误解为控制字符并损坏数据。 Base64 通过将二进制转换为文本子集来解决这个问题，该子集在任何基于文本的通道中都完好无损。它是二进制世界和文本世界之间的翻译器。
简要说明它是如何工作的
该算法一次接受您的输入三个字节。三个字节为 24 位，它分为四组，每组 6 位，每个 6 位组映射到 64 个字符之一。因此，每 3 个字节的输入正好变成 4 个输出字符。当您的输入不是 3 字节的干净倍数时，Base64 会用等号填充输出，如果最后一组有 2 个字节，则一个 =，如果只有 1 个字节，则两个 ==，因此结果始终是 4 个字符的倍数。这就是那些尾随等号的含义：它们告诉解码器最终组中有多少实际字节。
这种 3 比 4 的比例有一个直接的后果：Base64 输出比原始数据大约 33%。 1 MB 图像编码后大约为 1.37 MB。这种大小开销是您为文本安全所付出的代价，这就是为什么 Base64 非常适合小型事物，但对于大型事物来说却是一个糟糕的选择。
你将在哪里遇见 Base64
只要您知道查看，Base64 就无处不在。数据 URL 直接在 HTML 或 CSS 中嵌入文件，即 data:image/png;base64,...您有时会在图像标签或背景样式中看到，让小图标随页面加载，而不是作为单独的请求。电子邮件附件采用 Base64 编码，因此二进制文件可以在基于文本的邮件传输中保存下来；您发送的每个附件都以这种方式传输，这就是原始电子邮件文件比其携带的文件大的原因。
JSON Web 令牌 (JWT) 将其标头和负载编码为 URL 安全的 Base64 变体。 HTTP 基本身份验证在标头中以 Base64 形式发送您的用户名和密码。接受 JSON 主体内文件上传的 API 对文件进行 Base64 编码，因为 JSON 是文本，无法保存原始字节。 PEM 文件、SSL 证书、SSH 密钥是封装在 BEGIN 和 END 标头行之间的 Base64 编码二进制文件。相同的简单编码是所有这些的基础。
危险的神话：Base64 不是加密
这是需要理解的最重要的事情，因为错误会导致真正的安全漏洞。 Base64 提供零安全性。这不是加密。任何拥有编码字符串的人都可以在任何浏览器控制台中以一行方式立即对其进行解码，无需密钥。字符串 c2VjcmV0 在大约一秒钟内解码为“秘密”。
危险来自于 Base64 的外观。 Base64 字符串看起来是杂乱且随机的，在视觉上类似于加密数据，这会让人误以为它受到了保护。这会导致真正的事件：开发人员将带有 Base64 编码的数据库凭据的配置文件提交给版本控制，并相信编码隐藏了它们，但事实并非如此。 API 会记录授权标头，而审阅者“无法读取”Base64 密码，因此它以有效的纯文本形式保存在日志中，直到有人在五秒内对其进行解码。将 API 密钥以 Base64 形式存储在数据库中看起来不透明，但实际上并不能提供任何保护。
URL 安全 Base64 (Base64url)
标准 Base64 使用 + 和 /，但两者在 URL 中都有特殊含义，+ 可以表示查询字符串中的空格，而 / 分隔路径段。因此，名为 Base64url 的 URL 安全变体将 + 替换为 -（减号），将 / 替换为 _（下划线），并且通常会删除 = 填充，否则需要在 URL 中进行百分比编码。这是 JWT、OAuth 令牌和 URL 安全 cookie 使用的变体。如果您曾经将 JWT 段输入严格的标准 Base64 解码器并收到错误或垃圾，这通常是原因：您需要首先将 URL 安全字符转换回来并恢复填充。
Unicode 陷阱
对非英语文本进行 Base64 编码的开发人员遇到了一个微妙的错误。经典的浏览器函数 btoa() 假定每个字符都是一个字节，它会在重音字母、表情符号或任何非拉丁脚本上中断。解决方法是首先将文本编码为 UTF-8，然后对生成的字节进行 Base64 编码，否则“café”或“こんにちは”会损坏。一个好的编码器可以为您处理这个 UTF-8 步骤，因此重音文本和表情符号可以干净地往返。
何时使用，何时避免
当您需要通过纯文本通道移动小型二进制数据时，请使用 Base64：微小的内联图标、令牌、JSON 有效负载内的小文件、您正在调试的凭据。对于性能敏感路径中的大型二进制文件，请避免使用它，33% 的大小损失和单独缓存的损失使真实文件或分段上传成为更好的选择。切勿将其用作安全层。保持其在其车道、表示和传输中，Base64 是一种可靠的通用工具。