Base64 文本转原始二进制转换器
将 Base64 文本转换为原始二进制，剥离 ASCII 编码开销以恢复原始的 8 位字节流。
格式比较与技术规格
| 规格 | BASE64 | BIN |
|---|---|---|
| MIME 类型 | text/plain | application/octet-stream |
| 类型 | radix-64 ASCII encoding | raw binary byte stream |
| 压缩 | none (33% size expansion over raw binary) | none |
| 标准规范 | IETF RFC 4648 | Raw Binary Byte Stream Specification |
| 魔数文件头 (Magic Bytes) | A-Z a-z 0-9 + / = (Base64 character set) | Raw arbitrary binary bytes |
格式概述与应用
Base64 文本使用一组安全的 64 个可打印 ASCII 字符，以便在电子邮件或 JSON 负载等纯文本通信通道安全地表示二进制数据。但是，系统无法执行或处理格式化为 Base64 的文本，直到它返回其本地字节结构。软件开发人员经常在从配置文件、API 响应或网页应用程序资源中提取嵌入式图像、字体或编译的可执行负载时执行此转换。 从 Base64 转回原始二进制需要反转编码期间使用的数学运算。Base64 文本的每四个字符代表底层二进制数据的刚好三个字节。此过程剥离了格式化字符，并恢复了操作系统、硬件设备和原生二进制解析器所需的精确 1 和 0 序列。
技术规格与编解码器解析
Base64 文本由 text/plain MIME 类型标识，依赖于 radix-64 ASCII 编码且没有压缩，导致比原始文件体积扩大 33%。原始二进制使用 application/octet-stream MIME 类型来交付未格式化的字节流。两种格式都不使用压缩算法，这意味着转换是完全无损的。Base64 缺乏魔数字节头，因为它只是一种文本表示，但生成的原始二进制文件通常会在解码字节流的最开头显示标准文件签名，例如 ZIP 档案的"PK"或 Windows 可执行文件的"MZ"。
操作系统与浏览器兼容性
Windows、macOS 和 Linux 等操作系统通过系统调用和命令行实用程序原生处理原始二进制文件。现代网页浏览器使用 Fetch API 和 TypedArrays 处理二进制数据，允许开发人员在将字节写入 Blob 对象之前，直接在 JavaScript 中使用 atob 函数解码 Base64 字符串。只要应用了正确的文件扩展名和权限，iOS 和 Android 上的移动操作系统就可以通过原生应用程序沙箱高效读取二进制文件。
💡 实用信息
在开始解码过程之前，请务必验证您的 Base64 文本字符串不包含不需要的空白或换行符，因为杂散字符可能会破坏输出字节序列。
格式比较与技术规格
由于 33% 的大小开销，10 兆字节的原始二进制文件在编码为 Base64 文本时会扩展到大约 13.3 兆字节。在 5 Gbps 光纤连接上传输较小的原始二进制文件大约需要 0.02 秒，在快速 5G 连接上大约需要 0.2 秒，在标准 4G 移动网络上接近 2 秒。
常见问题
如何将 Base64 文本转换为原始二进制而不损失质量？
因为 Base64 只是二进制数据的文本包装器且不使用压缩，所以将其解码回原始二进制是完全无损的。在没有任何底层数据降级的情况下，每个原始字节都通过数学方法恢复了。
Base64 文本与原始二进制有什么区别？
Base64 文本是使用可打印 ASCII 字符的数据的安全、纯文本表示，它使文件大小膨胀了 33%。原始二进制是计算机和硬件直接执行或渲染的 8 位字节的本地、未格式化流。