为何MongoDB采用base64格式存储二进制数据而不支持直接存储原始二进制？

首先澄清一个常见误区：

你调用BinData(subtype, base64_str)时传入的base64字符串仅作为客户端与驱动交互的统一输入格式，实际写入MongoDB磁盘的BSON文件中，存储的是解码后的原始二进制字节，不会产生base64编码带来的33%额外存储空间开销。

采用该格式存储二进制的核心原因 #

• 符合BSON协议的标准化规范：BSON作为JSON的二进制超集，明确规定字符串类型必须是合法的UTF-8编码序列，原始二进制中通常包含大量不可见字符、非法UTF-8字节，直接传入会破坏BSON的结构解析逻辑，导致整个文档无法正常读写。base64编码会把任意二进制转换成纯可打印ASCII字符，完全符合BSON字符串的格式要求。
• 跨环境兼容性：不同编程语言、MongoDB驱动、管理工具对原始字节数组的处理逻辑差异极大，比如早期的Mongo Shell基于JS运行时，对原生字节数组的操作支持非常有限，base64是跨所有语言、平台都通用的二进制转文本标准，用它作为BinData的统一入参，不需要处理字节序、数组边界这类底层兼容问题。
• 支持二进制类型标记：BinData的第一个参数subtype可以明确标记二进制的业务类型，比如subtype 0为通用二进制、subtype 4为标准UUID、subtype 5为MD5值，驱动可以根据subtype自动做类型转换，比如把UUID类型的BinData直接转成上层语言的原生UUID对象，不需要用户额外做解析处理。

不允许直接存储原始二进制的设计考量 #

• 避免BSON解析故障：如果允许用户直接传入原始二进制作为字段值，驱动无法区分该内容是普通字符串还是需要特殊标记的二进制类型，一旦原始二进制包含BSON的结构控制字符，会直接导致解析器报错，甚至破坏整个文档的存储结构，引发数据损坏。
• 降低上层业务的处理成本：没有BinData封装的原始二进制没有类型标识，上层应用拿到数据后无法判断该字节数组是普通文本的字节流，还是业务上的图片、文件等二进制资源，需要额外增加字段做标记，反而会增加开发成本。
• 提升传输层鲁棒性：MongoDB驱动和服务端之间的通信链路中，很多代理、中间件对原始二进制的处理存在缺陷，比如会自动截断特殊字符、转义控制字节，使用base64封装后的格式在传输过程中不会出现这类问题，大幅提升数据传输的可靠性。

内容的提问来源于stack exchange，提问作者Idesh