我有一个包含编码protobuf数据的coredump,我想解码这个数据并查看内容。我有.proto文件,它在原始协议缓冲区中定义了此消息。我的proto文件如下所示:
$ cat my.proto
message header {
required uint32 u1 = 1;
required uint32 u2 = 2;
optional uint32 u3 = 3 [default=0];
optional bool b1 = 4 [default=true];
optional string s1 = 5;
optional uint32 u4 = 6;
optional uint32 u5 = 7;
optional string s2 = 9;
optional string s3 = 10;
optional uint32 u6 = 8;
}
和协议版本:
$ protoc --version
libprotoc 2.3.0
我尝试了以下方法:
>
从内核转储原始数据
(gdb)转储内存B.bin 0x7FD70DB7E964 0x7FD70DB7E96D
传给protoc
//proto文件(my.proto)在当前目录中
$protoc---decode--proto_path=$pwd my.proto
缺少标志的值:--decode
要解码未知消息,请使用--decode_raw.
$protoc--decode_raw
无法分析输入。
对如何解码有什么想法吗?文档并没有解释如何进行。
编辑:二进制格式的数据(10字节)
(gdb) x/10xb 0x7fd70db7e964
0x7fd70db7e964: 0x08 0xff 0xff 0x01 0x10 0x08 0x40 0xf7
0x7fd70db7e96c: 0xd4 0x38
您正确地使用了--decode_raw
,但您的输入似乎不是protobuf。
对于--decode
,需要指定类型名,如:
protoc --decode header my.proto < b.bin
但是,如果--decode_raw
报告解析错误,则--decode
也会报告解析错误。
您通过gdb提取的字节似乎不是有效的protobuf。也许您的地址并不完全正确:如果您在任一端添加或删除了一个字节,它可能无法解析。
我注意到,根据您指定的地址,protobuf只有9个字节长,这仅够设置三个或四个字段的空间。这是你所期待的吗?也许你可以把字节贴在这里。
编辑:
添加到问题中的10个字节似乎可以使用--decode_raw
成功解码:
$ echo 08ffff01100840f7d438 | xxd -r -p | protoc --decode_raw
1: 32767
2: 8
8: 928375
交叉参照字段编号,我们得到:
u1: 32767
u2: 8
u6: 928375
问题内容: 我们正在捕获大小可变(从100k到800k)的原始二进制字符串,并且我们想存储这些单独的字符串。它们不需要索引(duh),并且不会对该字段的内容进行任何查询。 这些插件的数量将非常大(用于存档),例如每天10,000。像这样的大型二进制字符串的最佳字段类型是什么?应该是还是其他? 问题答案: 就 PostgreSQL 而言,类型是不可能的。与目标相比,它更慢,占用更多空间并且更容易出错
本文向大家介绍php保存二进制原始数据为图片的程序代码,包括了php保存二进制原始数据为图片的程序代码的使用技巧和注意事项,需要的朋友参考一下 得到post过来的二进制原始数据,选择一个生成路径及图片的名字,之后写入,思路很显而易见
我需要编写一个能够处理CUrl发送的二进制数据的应用程序,例如: 我创建了一个POST处理方法,如下所示: 然而,它似乎没有返回原始的二进制数据。我试着发送一个GZip文件,在经历了Spring之后,它现在是可解压缩的,这让我相信我要么得到了太多的数据,要么得到了太少的数据。 如何解决此问题并获取原始二进制数据?
问题内容: 我知道用和 将小数转换为二进制(在这里我取32位结果的低16位)。 我想做的是另一种方法,并采用16位二进制补码二进制字符串并将其转换为十进制。 即 而不是 我该怎么做? 问题答案: 您需要将结果读取到中。 此打印。
我正在使用协议缓冲区和smack制作程序。 smack(xmpp)只能传输字符串类型的数据。并且协议缓冲器可以产生字节阵列数据。所以,我这样做 使用协议缓冲区制作byte[]数据。 使用base64将byte[]数据编码为字符串 使用smack传输 将接收到的字符串(使用base64编码)解码为字符串 将解码字符串更改为byte[] 使用协议缓冲区从byte[]解析数据。 那么没有< code>I
我已经有了protobuf消息对象的proto二进制文件。 现在要进行gRPC调用,我需要将其解组并通过message对象发送到gRPC客户端(该客户端将再次封送相同的对象),这会浪费延迟。 如何通过将二进制文件传递给客户端来避免这种情况?