为什么Base64仅被用于编码二进制数据？

关于二进制数据被中间系统损坏的原因及对应场景 #

三层及以下的网络转发设备（路由器、交换机）确实仅根据IP、端口等头部信息转发数据，不会解析负载内容，正常不会篡改二进制数据。问题主要出在链路中存在的七层处理系统，这类系统会主动解析上层负载内容执行对应逻辑，可能误改二进制数据，常见实例包括：

• 早期SMTP邮件协议原生仅支持7位ASCII文本传输，二进制数据的8位字节会被直接截断丢弃，这也是Base64最早大规模应用的场景
• 老旧的代理、网关设备会默认将传输内容按文本编码解析，遇到ASCII可打印范围外的二进制字节时，会主动替换为乱码占位符或者直接过滤
• 内网WAF、入侵检测等安全设备会扫描传输内容的特征，无法识别的二进制序列可能被误判为恶意流量直接拦截
• 部分HTTP 1.0的老旧实现没有明确的二进制负载处理规则，中间代理可能错误修改负载的换行符、编码，导致二进制数据损坏

关于Base64仅用于二进制数据的疑问 #

这个误解本质是搞反了Base64的使用前提：仅当传输/存储场景不支持直接传递二进制数据时，才需要用Base64转码，而非所有二进制数据都必须做Base64编码：

• Base64的字符集全部属于ASCII可打印范围，兼容性最高，几乎所有历史系统都不会篡改这类字符，但转码会带来33%的体积膨胀和额外的编解码开销，非必要不会使用
• 普通文本内容（HTML、JS、CSS）本身就是字符序列，传输时会明确指定UTF-8等编码格式，现在的HTTP协议对文本负载有完善的标准支持，中间设备遵循规范处理就不会篡改内容，完全不需要用Base64增加冗余开销
• 二进制数据也不是必须用Base64：比如直接下载图片、视频时，HTTP会通过Content-Type明确指定二进制类型，同时用Content-Length标注负载长度，中间设备不需要解析二进制内容直接转发即可，无需转码。只有当需要把二进制数据嵌入文本格式（比如图片嵌入HTML、二进制数据嵌入JSON响应）时，才需要用Base64将二进制转换为文本格式，避免破坏原文本的结构规则。

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