使用场景：
1、设备没有直接上报JSON的能力，需要进行透传数据。
① 16进制数组——>二进制——>【16进制数组】（这个就是我们官网文档的示例，脚本里直接解析就行）
② xxx——>二进制——>【16进制数组】——>xxx（最后转回xxx要在脚本里面第一步就处理好，然后对原始数据xxx再做解析）（注：xxx可为任意数据格式）
2、压缩数据，节省消息流量。
①特殊场景下，节省消息流量，例如正常的JSON格式上报需要两条数据上报，透传仅需一条。
●消息长度在512 Bytes以内的，视为一条消息。
●一条消息超出512 Bytes的部分计算为新的一条或多条消息。
②MQTT单个发布消息最大长度256kb（此值为官方口径，实际测试超过此值并未不能上报，但大于此大小不能保证）
此场景透传可以压缩数据大小进而完成单次数据上报。
常见问题示例：客户控制台脚本界面说测试可以，但实际设备上报确解析不正确。
详解：是因为控制台脚本那里直接输入的是16进制数据，然而客户脚本就是按照文档示例16进制数组进行解析的，但是设备上报的string（这一点可以根据日志服务消息内容判断，如果他设备上报的是byte数组，那控制台日志应该是【Hex】类型下看到原始数据，如果在【Text(utf-8)】下看到了原始数据，那肯定是string上报），脚本里面string——>二进制——>16进制数组，这种肯定解析不出来，正确的应该是string——>二进制——>16进制数组——>string。
运行结果
模拟输入
模拟类型:设备上报数据
//二进制数据以0X开头的十六进制输入
此时要转成正常解析，两种解决方案：
①设备端把string转换成byte数组进行上报（16进制数组——>二进制——>【16进制数组】）
②在平台的脚本解析里面用脚本进行转换（string——>二进制——>【16进制数组】——>string）
这里选择哪种视情况而定，如果设备端有转换能力，建议在设备端转，比较简便，如果没有能力就选择第二种。
