![将未知的十六进制/二进制表示逆向为十进制](https://linux22.com/image/1599738/%E5%B0%86%E6%9C%AA%E7%9F%A5%E7%9A%84%E5%8D%81%E5%85%AD%E8%BF%9B%E5%88%B6%2F%E4%BA%8C%E8%BF%9B%E5%88%B6%E8%A1%A8%E7%A4%BA%E9%80%86%E5%90%91%E4%B8%BA%E5%8D%81%E8%BF%9B%E5%88%B6.png)
我正在解码一个通过网络数据包输出位置数据的设备。假设我们想解码海拔。海拔数据包为 4 个字节。因此十六进制信息为。
0x05 0x79 = 5.945313(meters)
通过测试,我确定前 2 个字节是逗号之前的所有内容。谜团在于十六进制值“79”是如何变成 945313 的。
然后我制作了自己的数据包,其中只更改了提到的 2 个字节并制作了一个表格:
0x01 = 0.007813
0x02 = 0.015625
0x03 = 0.023438
0x04 = 0.03125
0x05 = 0.039063
0x06 = 0.046875
0x07 = 0.054688
0x08 = 0.0625
0x09 = 0.070313
0x0a = 0.078125
0x0b = 0.085938
0x0c = 0.09375
0x0d = 0.101563
0x0e = 0.109375
0x0f = 0.117188
0x10 = 0.125
0x20 = 0.25
0x30 = 0.376
0x40 = 0.5
0x50 = 0.625
0x60 = 0.75
0x70 = 0.875
0x80 = NaN
例如做出0x79 gives = 70 + 09 = 0.875 + 0.070313 = 0.945313
正确的决定。
但是,如果不做这个表,如何计算值呢?这其中一定有某种规律,但我看不出来。有什么想法吗?
答案1
小数部分似乎以 1⁄128 的形式存储,没有比这更复杂的了。
altitude = firstbyte + (secondbyte / 128)
请注意,所有内容都是以 ~0.007813 的步长线性增加的(1/0.007813 ≈ 128),并且0x40
(64) 正好是 0.5,而0x80
(128) 是 NaN,因为 128⁄128 = 1.0,这对于小数部分来说没有意义。(当然,从技术上讲,您仍然可以解码 0x0580 并获得与 0x0600 相同的结果,但我认为仅接受规范格式的数据是一种很好的做法。)