JSON、Text 与 HEX

三件事分别是什么

「编辑格式」决定编辑器如何处理输入；「发送方式」决定当前文本交给网络层的形式；订阅的「消息格式」决定收到后怎么展示。三者不能互相替代。

JSON 编辑与校验

选择 JSON 后，编辑器提供语法高亮与合法性状态。「格式化」会对合法 JSON 重新缩进；无效 JSON 会阻止发布。编辑器失焦时也会尝试格式化合法内容。

{ "device": "demo-01", "temperature": 24.6 }

JSON 字符串要使用双引号，末尾不要保留多余逗号。只是想发送任意文本时改选 Text。

Text 录入

Text 适合普通字符串、日志片段或设备约定的文本命令。原文使用 UTF-8；字符数和字节数可能不同。

当前 HEX 的准确含义

当前「发送方式 HEX」不是十六进制文本解析器。 它将编辑器中的文本转换为 UTF-8 字节数组，展示这些字节的十六进制预览后发送。

因此，输入 48 65 不会发送 0x48 0x65 两个原始字节。当前 UI 没有通用原始 HEX 输入解析入口；需要任意二进制载荷时不能照文本解析器的方式操作。

预览较长时会截断，旁边的「复制完整 HEX」可复制全部字节表示。截断的是展示，不是发送载荷。

接收格式与原始内容

订阅选 JSON 时，小载荷可以自动缩进；超过格式化上限会跳过自动处理。订阅选 Hex 时使用接收字节展示，不代表原消息本来就是十六进制字符串。

排查前导字节、非 UTF-8 数据或 BOM 时，打开消息详情，使用原始内容复制入口。不要从缩进后的 JSON 推断发送端空格和换行完全一致。

先做一组可核对测试

订阅独立测试主题，依次发送 Hello 和 中，比较原文与 HEX 模式的接收字节数。确认行为后再调试业务载荷。

Text 订阅的接收效果

Hex 订阅的接收效果