简要回答

粘贴一个有效的 JSON 值，测量其实际 UTF-8 字节长度，并查看 CBOR 和 MessagePack 的宽泛规划区间。JSON 文本的测量是精确的。紧凑格式的数字刻意采用区间形式，因为真实的编码大小取决于字段名、值类型、模式选择、库行为以及是否表示了等效信息。

此工具不估算 Protobuf。没有消息模式、字段编号、线类型、存在性规则和传递给真实编码器的值，无法负责任地从 JSON 文本推断 Protobuf 大小。

输入

输入你期望设备或服务产生的确切 JSON 表示，包括属性名、字符串值、数字、数组和空白字符。示例如下：

{"deviceId":"pump-042","temperature":21.6,"running":true}

解析器接受任何有效的 JSON 值，尽管对象是 IoT 最常见的载荷。空白字符计入 JSON 字节数，因为它是传输文本的一部分。非 ASCII 字符可能占用多个 UTF-8 字节，因此 JavaScript 字符数和线路字节数不可互换。

请勿粘贴生产环境密钥、个人数据、访问令牌或客户载荷。一个代表性的合成样本足以用于规划比较。

方法与规划区间

JSON 大小使用浏览器的 UTF-8 TextEncoder 测量：

输入字符串的 UTF-8 字节长度

如果解析失败，工具报告已测量的字节长度但停止格式比较，直到 JSON 语法被修正。

对于有效的 JSON，工具显示以下显式启发式区间：

  • **CBOR：**输入 JSON 字节长度的 45% 至 75%。
  • **MessagePack：**输入 JSON 字节长度的 50% 至 80%。

区间向上取整为整字节数。它们不是格式保证、基准测试结果或某种编码总是优于另一种的断言。短键名、重复结构、数值类型、模式感知编码、字符串表和压缩都可能大幅改变实际结果。使用实际生产库处理相同的逻辑消息来替换此区间。

示例分析

内置的水泵载荷为 57 个 UTF-8 字节。工具报告 CBOR 规划区间为 26–43 字节，MessagePack 规划区间为 29–46 字节。它不会编造 Protobuf 结果。

以每分钟一条消息计算，节省 20 字节即可每设备每天减少 28,800 载荷字节。在大规模设备群中这可能有意义，但与主题名、MQTT 头、TLS 和 TCP/IP 帧、无线头、确认、心跳、重传或计费增量相比可能仍然微不足道。反之，将消息频率从每秒一次改为每分钟一次所减少的流量远超从编码中削减几个字节。请优化系统边界，而非孤立地优化样本。

局限性与权衡

计算器不运行 CBOR 或 MessagePack 编码器。它不考虑规范编码、标签、扩展类型、整数宽度、浮点选择、模式、压缩字典、批处理、主题长度、MQTT 属性、传输帧、加密、分片或重传。它也不比较编码和解码的 CPU 时间、RAM、固件大小、可观测性、浏览器支持或调试二进制流量的成本。

语义等效性很重要。将具有可读字段名的 JSON 与一个移除了字段、改变了精度或依赖带外模式状态的二进制载荷进行比较，不是仅关于编码的比较。请将模式分布和演进纳入决策。

隐私与导出

JSON 输入仅在此浏览器中解析和测量。它被刻意排除在 URL、复制参数和导出参数块之外，使载荷内容不会泄露到浏览器历史、分享链接或 Referer 数据中。生成的结果仅包含字节计数和解释性区间。

复制生成 Markdown 结果。JSON、CSV 和 Markdown 文件由浏览器本地生成并下载。不上传任何载荷或结果到 IoT 01。

常见问题

为什么缩进会使载荷变大？

空格和换行在 JSON 中都是字节。在比较线路大小时请先压缩载荷，同时为测试和支持保留可读的固件数据。

应该选择哪种二进制格式？

仅看大小是不够的。需比较模式演进、实现可用性、CPU 和内存成本、可调试性、互操作性以及代表消息的实际编码字节数。

可以将中值用作容量数值吗？

仅限于早期场景并明确保留区间。采购和协议决策应使用真实编码器的输出和完整抓包数据。

相关指南

阅读设计设备消息契约以决定消息中应包含哪些字段、如何演进，以及编码在更广泛契约中的位置。