Base64 vs 二进制编码的选择

← 返回博客

Base64 vs 二进制编码的选择

· 5 分钟阅读

二进制传输的优势

直接传输原始二进制数据（不进行 Base64 编码）的最大优势是效率：没有 33% 的体积开销，没有编码/解码的计算成本，接收方可以直接使用接收到的字节。在带宽敏感或延迟敏感的应用中（如视频流、实时游戏、大型文件传输），二进制传输是明显更优的选择。

现代 Web 协议已经很好地支持二进制数据传输。WebSocket 支持二进制帧（Binary Frame），HTTP/2 本身就是二进制协议，HTTP 的 multipart/form-data 格式允许直接上传二进制文件，gRPC 使用 Protocol Buffers 实现高效的二进制序列化。

Base64 的适用场景

尽管二进制传输更高效，但 Base64 在以下场景中仍然是必要的或更合适的：传输层只支持文本（如电子邮件 SMTP 的 7 位 ASCII 限制）；数据需要嵌入文本格式的文档（如 JSON、XML、YAML、HTML）；需要确保数据在各种文本处理系统中不被修改（某些系统会修改特定字节序列）；数据需要在 URL 或 HTTP 头部中传输。

一个关键判断标准是：你的传输通道和存储系统是否"二进制安全"（binary-safe）？如果是（如现代数据库的 BLOB 列、S3 对象存储、WebSocket 二进制帧），则应优先使用二进制。如果不确定或明确只支持文本，则使用 Base64。

在 JSON API 中的选择

JSON 是基于文本的格式，不能直接包含二进制数据。当 JSON API 需要传输二进制内容（如图片、PDF 文件）时，有几个选项：（1）Base64 字符串：最简单，兼容性最好，但体积增加 33%；（2）数据 URL（data URI）：与 Base64 类似，额外包含 MIME 类型信息；（3）分离上传：先通过 multipart/form-data 上传文件，获取文件 URL，再在 JSON 中引用该 URL，保持 JSON 紧凑。

Google 的 API 设计指南推荐的做法是：对于小型二进制数据（小于 10KB），可以使用 Base64 字符串内联在 JSON 中；对于大型二进制数据，应使用单独的媒体上传端点，返回资源 URI 供后续引用。这个准则已被许多知名 API（如 Google Cloud Vision、Twilio）采用。

在数据库中存储二进制数据

主流数据库提供了专用的二进制数据类型，通常比 Base64 字符串更高效。PostgreSQL 的 BYTEA 类型可以直接存储原始二进制，查询时自动以十六进制转义格式显示。MySQL 的 BLOB 系列类型同样直接存储二进制，不需要 Base64 转换。MongoDB 的 Binary 类型（BSON BinData）也是原生二进制存储。

有时开发者会将 Base64 字符串存入 TEXT 或 VARCHAR 列，而非使用 BLOB/BYTEA。这不推荐，原因是：（1）体积增大 33%；（2）缺少二进制数据的语义信息，难以优化；（3）ORM 可能无法正确处理比较和索引。如果出于可读性或跨数据库兼容性考虑，可以使用 Base64，但应该有充分的理由。

WebSocket：二进制 vs 文本帧

WebSocket 协议支持两种帧类型：文本帧（UTF-8 文本）和二进制帧（原始字节）。如果你的 WebSocket 应用需要传输图片或音频，应该使用二进制帧而非将数据 Base64 编码后放入文本帧。二进制帧没有编码开销，而且大多数 WebSocket 库都很好地支持二进制帧处理。

// 使用 WebSocket 二进制帧传输图片（浏览器）
// Using WebSocket binary frames to transmit images (browser)
const ws = new WebSocket('wss://example.com/ws');
ws.binaryType = 'arraybuffer'; // 或 'blob'

// 发送二进制数据 / Send binary data
const imageBuffer = await fetch('/image.png').then(r => r.arrayBuffer());
ws.send(imageBuffer); // 直接发送，无需 Base64

// 接收二进制数据 / Receive binary data
ws.onmessage = (event) => {
  if (event.data instanceof ArrayBuffer) {
    const blob = new Blob([event.data], { type: 'image/png' });
    const url = URL.createObjectURL(blob);
    document.querySelector('img').src = url;
  }
};

Protocol Buffers 与 JSON+Base64 的对比

Protocol Buffers（protobuf）是 Google 开发的二进制序列化格式，与 JSON+Base64 相比有显著优势：体积更小（通常是 JSON 的 20–80%，远小于 JSON+Base64）；解析速度更快（5–10倍）；强类型定义，减少错误；内置对二进制字段（bytes 类型）的支持。

在需要高性能二进制数据传输的场景中（如微服务间通信、高频 API 调用），protobuf 通常是比 JSON+Base64 更好的选择。但如果可读性、调试便利性或与不支持 protobuf 的系统互操作更重要，JSON+Base64 仍然是合理的选择。

决策框架总结

选择二进制还是 Base64 的简明决策框架：如果传输层或存储层只支持文本，必须使用 Base64；如果数据需要嵌入 JSON/XML/YAML，使用 Base64；如果数据量大（>10KB）且性能重要，优先考虑二进制（multipart 上传、BLOB 存储、二进制 WebSocket 帧）；如果数据量小（<10KB）且方便性优先，Base64 是可接受的选择。

立即尝试在线工具，无需安装，免费使用。

打开工具 →