你如何解读这句话?
你如何解读这句话?
校验和
这是在将标头中的低 8 位添加到校验和时要使零的值。
有了这个协议描述:
协议
由头(1字节)+数据长度(1字节)+组成 命令数据(13字节)+校验和(1字节)+连接ID(1 字节)。
(我逐字复制了这个协议描述,所以我不知道为什么有 1 个字节
(复数)。但我可以告诉你它只是一个字节)
这里是该协议的一些示例 TCP 数据包:
HE:DL:------------Command Data -------------:CS:ID
02:0d:be:ef:03:06:00:19:d3:02:00:00:60:00:00:ed:01
02:0d:be:ef:03:06:00:cd:d2:02:00:00:20:00:00:7a:01
02:0d:be:ef:03:06:00:10:f6:02:00:ba:30:00:00:49:01
02:0d:be:ef:03:06:00:c8:d8:02:00:20:30:00:00:49:01
// Requested Packets
02:0d:be:ef:03:06:00:13:d3:01:00:02:30:01:00:21:01
02:0d:be:ef:03:06:00:c2:ff:02:00:90:10:00:00:d8:01
其中
HE
是 HEader(固定为0x02
)DL
是 DataLength(始终为 < code>0x0d,因为数据包都是相同的长度)CS
是CheckSum(这是我的问题)ID
是连接ID(在我的测试中似乎总是01)
我无法弄清楚如何计算校验和。我希望我提供了足够的信息。
提前致谢。
How do you interpret this phrase?
Checksum
This is the value to make zero on the addition of the lower 8 bits from the header to the checksum.
With this protocol description:
Protocol
Consist of header (1 byte) + data length (1 byte) +
command data (13 bytes) + check sum (1 bytes) + connection ID (1
byte).
(I literally copied this protocol description, so I'dont know why there is 1 bytes
(in plural). But I can tell you it is only one byte)
Here are some sample TCP packets of this protocol:
HE:DL:------------Command Data -------------:CS:ID
02:0d:be:ef:03:06:00:19:d3:02:00:00:60:00:00:ed:01
02:0d:be:ef:03:06:00:cd:d2:02:00:00:20:00:00:7a:01
02:0d:be:ef:03:06:00:10:f6:02:00:ba:30:00:00:49:01
02:0d:be:ef:03:06:00:c8:d8:02:00:20:30:00:00:49:01
// Requested Packets
02:0d:be:ef:03:06:00:13:d3:01:00:02:30:01:00:21:01
02:0d:be:ef:03:06:00:c2:ff:02:00:90:10:00:00:d8:01
Where
HE
is the HEader (which is fixed to0x02
)DL
is the DataLength (which is always0x0d
, because the packets are all the same length)CS
is the CheckSum (which is my question about)ID
is the connection ID (seems to be always 01 in my tests)
I can't figure out how the checksum is computed. I hope I gave enough info.
Thanks in advance.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(4)
我认为只是描述中有错误。看起来他们正在对标头和校验和之间的所有字节求和。校验和只是清除低 8 位的数字。因此,对于第一个示例,标头和校验和之间的所有字节之和为 0x0313。或者
当它像这样排列时,您可以清楚地看到您将把低 8 位清零并返回:
您没有指定语言,但您也可以通过执行 (0 XOR returned) + 来快速计算自己的校验和1.
I think there's just an error in the description. It looks like they are summing all the bytes between the header and the checksum. And the checksum is just a number that clears the lower 8 bits. So, for the first example, the sum of all bytes between the header and the checksum is 0x0313. Or
When it's lined up like that, you can clearly see you'll be zeroing out the lower 8 bits and returning:
You didn't specify a language, but you could also quickly calculate your own checksum by doing (0 XOR calculatedSum) + 1.
您
无论如何,此 C 代码计算所有 4 个示例的正确总和:
You
Anyway, this C code computes the correct sum for all your 4 examples:
如果将 Header、DataLength、CommandData 和 CheckSum 中的所有十六进制数字相加,则为 1024。
例如,这是第二个示例的总和(我跳过了 0x00):
屏幕截图(sum 只是我编写的一个 javascript 函数自动对十六进制值求和):
编辑:
它不一定会等于 1024,相反,如果有效,它会等于一个低 8 位为 0 的数字,例如 1024 (10000000000)、768 (1100000000 )和 1280 (10100000000)。
If you add up all the hex numbers in the Header, DataLength, CommandData, and CheckSum, it makes 1024.
For example, here's the sum of the second example (I skipped the 0x00's):
Screenshot (sum is just a javascript function I wrote to sum the hex values automatically):
EDIT:
It will not necessarily sum to 1024, rather, if it is valid it will sum to a number where the 8 lower bits are 0, such as 1024 (10000000000), 768 (1100000000), and 1280 (10100000000).
只是为了好玩,我将此作为使用 Boost Spirit (c++) 编写简单二进制解析器的练习。我包括了问题格式的转换和校验和验证。
我让解析器识别实际数据长度并任意选择数据包数据的 STL 容器。输出如下:
输出
Just for fun, I took this as an exercise in writing a simple binary parser using Boost Spirit (c++). I included the conversion from the question format and the checksum verification.
I made the parser recognize actual datalength and arbitrary choice of STL container for the packet data. Output below:
Output