如何解码TCP缓冲区数据

问题描述:

我想写一个tcp服务器从邻近908 GPS跟踪器获取数据。从跟踪器建立连接后,我得到以下缓冲区输出。如何解码TCP缓冲区数据

<Buffer 78 78 0d 01 03 87 11 31 20 86 48 42 00 06 64 be 0d 0a> 
<Buffer 78 78 0d 01 03 87 11 31 20 86 48 42 00 06 64 be 0d 0a> 
<Buffer 78 78 0d 01 03 87 11 31 20 86 48 42 00 06 64 be 0d 0a> 
<Buffer 78 78 0d 01 03 87 11 31 20 86 48 42 00 06 64 be 0d 0a> 
<Buffer 78 78 0d 01 03 87 11 31 20 86 48 42 00 06 64 be 0d 0a> 
<Buffer 78 78 0d 01 03 87 11 31 20 86 48 42 00 06 64 be 0d 0a> 
<Buffer 78 78 0d 01 03 87 11 31 20 86 48 42 00 06 64 be 0d 0a> 

我不知道如何将这些数据解码为适当的可读格式。

注:当然,我试图达到制造,但他们没有响应。

TCP协议有哪些可能的编码格式?

在第二天,我得到的数据是这样

<Buffer 78 78 0d 01 03 87 11 31 20 86 48 42 00 07 75 37 0d 0a> 
<Buffer 78 78 0d 01 03 87 11 31 20 86 48 42 00 07 75 37 0d 0a> 
<Buffer 78 78 0d 01 03 87 11 31 20 86 48 42 00 07 75 37 0d 0a> 
<Buffer 78 78 0d 01 03 87 11 31 20 86 48 42 00 07 75 37 0d 0a> 
<Buffer 78 78 0d 01 03 87 11 31 20 86 48 42 00 07 75 37 0d 0a> 
<Buffer 78 78 0d 01 03 87 11 31 20 86 48 42 00 07 75 37 0d 0a> 
<Buffer 78 78 0d 01 03 87 11 31 20 86 48 42 00 07 75 37 0d 0a> 
<Buffer 78 78 0d 01 03 87 11 31 20 86 48 42 00 07 75 37 0d 0a> 
<Buffer 78 78 0d 01 03 87 11 31 20 86 48 42 00 07 75 37 0d 0a> 
<Buffer 78 78 0d 01 03 87 11 31 20 86 48 42 00 08 8d c0 0d 0a> 
<Buffer 78 78 0d 01 03 87 11 31 20 86 48 42 00 08 8d c0 0d 0a> 
<Buffer 78 78 0d 01 03 87 11 31 20 86 48 42 00 08 8d c0 0d 0a> 
<Buffer 78 78 0d 01 03 87 11 31 20 86 48 42 00 08 8d c0 0d 0a> 
<Buffer 78 78 0d 01 03 87 11 31 20 86 48 42 00 08 8d c0 0d 0a> 
<Buffer 78 78 0d 01 03 87 11 31 20 86 48 42 00 08 8d c0 0d 0a> 
<Buffer 78 78 0d 01 03 87 11 31 20 86 48 42 00 08 8d c0 0d 0a> 
<Buffer 78 78 0d 01 03 87 11 31 20 86 48 42 00 08 8d c0 0d 0a> 
<Buffer 78 78 0d 01 03 87 11 31 20 86 48 42 00 08 8d c0 0d 0a> 
<Buffer 78 78 0d 01 03 87 11 31 20 86 48 42 00 08 8d c0 0d 0a> 
<Buffer 78 78 0d 01 03 87 11 31 20 86 48 42 00 08 8d c0 0d 0a> 
<Buffer 78 78 0d 01 03 87 11 31 20 86 48 42 00 08 8d c0 0d 0a> 

<Buffer 78 78 1f 12 0e 02 14 13 01 14 c8 03 5f a6 50 07 f7 f8 c1 32 35 39 01 9a 04 0f a2 00 b0 5a 00 1a 9b 7a 0d 0a> 
<Buffer 78 78 1f 12 0e 02 14 13 01 1e c8 03 5f ad bc 07 f7 f0 76 41 35 40 01 9a 04 0f a2 00 b0 5a 00 1b b6 31 0d 0a> 

东西正在被改变,但不知道它是什么...

+0

从厂商的PDF(http://www.heacent.com/download/Heacent %20gps%20munual(908).pdf)我想你问的是用于“在线实时跟踪”的协议,他们建议你使用自己的服务。所以你想编写自己的服务器来接受来自这个设备的数据,而不是使用制造商的服务,对吗? –

+0

是的正确!我想用我自己的个人用途! – coure2011

+0

好的。他们还发布了一份协议指南,但不清楚它是否解释了您上面写的内容:http://www.heacent.com/download%5CGPS%20protocol(Heacent).pdf –

你问什么可能的编码格式有用于TCP。这有些奇怪的问题:使用TCP作为基础协议的编码格式数量无限。但不管怎么样,我们都可以尝试弄清楚这一点!

您已经发布了一些示例消息。让我们来看看,如果我们可以翻译它们:

byte 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 
rev 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 
---------------------------------------------------------- 
hex 78 78 0d 01 03 87 11 31 20 86 48 42 00 06 64 be 0d 0a 
text x x \r -- -- -- -- 1 -- H B -- -- d -- \r \n 
dec  13 1 3 17     0 6 100 13 10 
be32  [218170247] [288432262]  [ 419006] 
---------------------------------------------------------- 
hex 78 78 0d 01 03 87 11 31 20 86 48 42 00 07 75 37 0d 0a 
text          -- u 7 
dec           7 117 55 
be32          [ 488759] 
---------------------------------------------------------- 
hex 78 78 0d 01 03 87 11 31 20 86 48 42 00 08 8d c0 0d 0a 
text          -- -- -- 
dec           8 141 
be32          [ 560576] 
----------------------------------------------------- byte 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 
hex 78 78 1f 12 0e 02 14 13 01 14 c8 03 5f a6 50 07 f7 f8 c1 32 35 39 01 9a 04 0f a2 00 b0 5a 00 1a 9b 7a 0d 0a 
text  -- -- -- -- -- -- -- -- -- -- _ -- P -- -- -- -- 2 5 9 -- -- -- -- -- -- -- -- -- xx -- z \r \n 
---------------------------------------------------------- 
hex 78 78 1f 12 0e 02 14 13 01 1e c8 03 5f ad bc 07 f7 f0 76 41 35 40 01 9a 04 0f a2 00 b0 5a 00 1b b6 31 0d 0a 
text           --  -- -- A 5 @       -- xx -- 1 

一些潜在的有趣的事实:

  • 开始以“XX \ r \ 01”这或多或少似乎是一个可能的标题。但后来的消息以“xx”和其他内容开头。无论如何,鉴于NMEA有一个“GP”的前缀,如果这些设备使用“xx”作为“不是NMEA的东西”,我不会感到震惊。
  • 中间有“HB”,这可能意味着“心跳”,因为这是重复的,也许等待服务器的回复。
  • 以“\ r \ n”结尾(通常在Windows上),尽管其余部分看起来并不完全是文本。
  • 较早的消息长度为18个字节,后面的消息长度为36个字节。一个猜测是短的是状态更新或心跳,而长的是实际的位置信息。 36个字节是不够的,如果我们的数字:
    • 4字节纬度:如果你捏(see)24位,25-32位更容易
    • 4字节经度:同纬度
    • 6字节的时间戳:39比特,如果采用划时代时间厘秒,32/48/64位更容易
    • 2字节高度:我怀疑这个设备不公布海拔高度在所有的,给予一定的文档的

所以我认为发生的事情是你看到的这些消息只是设备“ping”服务器并等待响应。什么样的回应?那么,你可以试图强制它,但更容易的是在你的程序中建立一个桥梁,它将从设备接收到的任何东西,发送到制造商的服务器,然后做相反的事情对设备的响应。通过这种方式,您可以快速收集到有效消息的语料库,如果我们确实需要对此进行逆向工程,这将非常有用。或者,如果你幸运的话它会变成初始会话协商后,使用一些标准协议一样NMEA

编辑:现在你已经给了我们从设备的更多消息,我们可以看到,它似乎发送别的可变内容。也许这就是位置数据,但我现在没有时间尝试对其进行反向工程。一种想法是物理单位从西向东移动或南北捕捉它在这段时间内发送邮件,试图找出是哪个消息的部分是经度和它们的纬度(也许时间戳太)。

我认为这是相当清楚的是,前两个字节是“XX”为标题,最后两个是“\ r \ n”作为终结。在较长的消息中留下32个字节的有效负载,所有这些都是二进制数据。

+0

man !!!为什么stackoverlow不允许upvote多次:)。非常感谢这次调查。你为我提供了很多信息。将根据您的调查进行更多研究。 – coure2011

这是GT06协议,你可以找到它的规格在这里: