为什么IoT尤其是LPWAN场景中常使用Base64编码传输payload数据？

你观察到的现象确实是行业普遍实践，看似牺牲带宽的选择背后，是LPWAN场景下的实际需求优先级远高于Base64带来的约33%体积增幅，核心优势如下：

• 规避二进制传输兼容性问题
  多数LPWAN的网关、中继、上行转发接口默认仅支持可打印ASCII字符传输，会对0x00-0x1F、0x7F这类控制字符做截断、转义甚至直接丢弃。实际应用中几乎不会直接对JSON做Base64编码，通用做法是先把原始业务数据序列化成高压缩比的二进制格式（比如自定义二进制结构体、Protobuf、CBOR），这一步的体积就比明文JSON小60%~90%，再通过Base64转换成标准可打印字符集，最终总payload体积仍然远小于明文JSON。
• 降低低功耗设备的开发成本
  LPWAN设备的MCU通常算力、内存极其有限，很多设备没有完整的JSON序列化/反序列化库，自定义二进制结构体的序列化仅需简单内存拷贝，代码量仅为JSON处理的1/10，内存占用可控制在几十字节以内。Base64编码算法实现非常轻量，无复杂依赖，整体开发成本远低于直接处理JSON。
• 统一多链路传输格式
  多数IoT设备会同时支持多传输通道（比如除LPWAN外，还会用BLE、串口、短信做调试或备用传输），这些通道大多也要求可打印ASCII字符传输，Base64编码后的payload无需修改即可在所有通道间透传，无需为不同通道做单独格式适配，大幅降低上层应用开发复杂度。
• 避免解析异常
  多数IoT平台的上行数据解析链路会用换行、逗号、引号等字符做分隔符，若payload直接包含这类特殊字符很容易导致解析错误，甚至出现注入类问题。Base64的字符集不包含上述特殊分隔符，无需额外转义处理，解析稳定性更高。

注：Base64的体积增幅是相对于原始二进制数据而言，而非相对于明文JSON，多数场景下编码后的最终体积仍然远小于直接传输JSON的体积。

内容的提问来源于stack exchange，提问作者Don T Spamme