YamlBox

网络和编码 · 5 分钟阅读

Base64 解码和编码：用于传输，而不是安全

Base64 的存在是为了通过只接受文本的通道移动二进制数据。它将每三个字节映射为四个可打印字符，这就是为什么编码输出大约比输入大三分之一，也是为什么 Base64 解码是完全可逆的——没有密钥，因为 Base64 是编码，而不是加密。任何人都可以解码您编码的任何内容，任何其他暗示的工具都是在骗您。

已更新

字母表和填充

标准字母表为`A–Z`、`a–z`、`0–9`、`+`和`/`，当输入长度不是三的倍数时，用`=`填充最后一组。该填充不是装饰性的：它告诉解码器最后一组承载了多少字节。剥离它在 URL 中很常见，并且有效，因为解码器会推断长度，但严格的实现将拒绝未填充的形式。

                "YamlBox"  →  WWFtbEJveA==
"YamlBo"   →  WWFtbEJv

base64url：最​​终以令牌形式出现的变体

URL 将 `+`、`/` 和 `=` 视为重要的，因此 base64url 变体将它们替换为 `-` 和 `_`，并且通常完全省略填充。每个 JSON 网络令牌都使用这个字母表，这就是为什么将 JWT 有效负载粘贴到严格的 Base64 解码器中可能无法识别看起来非常普通的字符。如果一个字符串解码为接近但不太可读的内容，那么您通常与答案相差一个字母表。

你在实践中遇到的地方

  • 数据 URI — 将小图像和字体直接嵌入 CSS 或 HTML 中，如 `data:image/png;base64,…`。
  • JSON Web Tokens — 这三个段中的每一个都经过 base64url 编码。
  • HTTP 基本身份验证 — `Authorization: Basic` 携带 `user:password` 的 base64，这就是它必须始终通过 TLS 传输的原因。
  • 电子邮件附件 — 自 20 世纪 80 年代以来，MIME 一直使用 base64 作为二进制部分。
  • 无法接受二进制的 API — 图像有效负载和放入纯文本字段中的密钥。

为什么Base64解码输出看起来像垃圾

典型的失败是 Unicode。 JavaScript 的较旧的 `btoa` 和 `atob` 对每个字符一个字节进行操作，因此包含 `é`、`₹` 或任何表情符号的字符串要么抛出或产生 mojibake。解决方法是首先对 UTF-8 字节进行编码 - 在浏览器中为 `TextEncoder`，在 Node 中为 `Buffer.from(str, "utf8")`，然后对这些字节进行 Base64 编码。如果解码返回看似合理但错误的字符，最可能的原因是编码器根本没有将文本转换为 UTF-8 字节。

Base64 不提供机密性或完整性。对待编码的秘密就像对待原始秘密一样，因为这就是它的本质。

为什么要本地解码

基本身份验证标头、令牌和数据 URI 都会解码为凭据或私有数据，因此将它们粘贴到服务器端解码器中是一种披露。 YamlBox Base64 编码器/解码器在正确完成 UTF-8 处理的页面中工作，支持标准和 URL 安全字母表，并且可以离线运行。

Base64 编码器/解码器 — 常见问题

Base64 是否加密？

不。它是一种没有密钥的可逆编码，因此任何人都可以对其进行解码。它的存在是为了让二进制数据可以通过纯文本通道传输——而不是为了保护数据。使用 TLS 和真正的加密（例如 AES-GCM）来保证机密性。

Base64 输出大多少？

恰好大了三分之一，再加上一点填充，因为三个字节变成了四个字符。这种开销就是为什么 base64 用于内联小型资产而避免用于大型资产。

为什么 Base64 解码会返回奇怪的字符？

通常是编码不匹配：编码前原始文本未转换为UTF-8字节，或者您正在使用标准解码器解码base64url数据。检查`-`和`_`字符，并确认源编码器使用UTF-8。

这篇文章中提到的工具

URL 编码器/解码器 对 URL 进行百分比编码并正确解码查询字符串。 JWT 解码器 无需离开浏览器即可检查 JWT 标头、有效负载和过期时间。 JSON 格式化程序 漂亮打印、缩小并验证 JSON 以及准确的错误位置。 cURL 来获取 将 cURL 命令转换为 fetch、axios 或 node-fetch 代码。

浏览 19 工具的完整列表

更多文章可供阅读

所有19帖子→