Reputation: 311
Is a serialized protocol buffer difficult to parse without using the .proto/a class compiled from it?
Obviously, it's easier to do with the .proto. I'm wondering if the structure of data serialized with protocol buffers can be easily parsed without them, given some other descriptor of the data. i.e. If the code parsing my data (which was serialized with a protocol buffer) knows that it's expecting two ints and a boolean, is it easy to parse those values out? Or does the protocol buffer add extra padding/fluff?
Upvotes: 1
Views: 496
Reputation: 1062550
If the code parsing my data (which was serialized with a protocol buffer) knows that it's expecting two ints and a boolean, is it easy to parse those values out?
Sure; you don't even need to know that - here's a tool that will attempt to decode an unknown protobuf without any schema data, but there are caveats and some of the data can be ambiguous. protoc
has a similar tool built in.
As for how to access that from your own code: that depends entire on the library you are using. If the library you are using has a raw reader /parser API (rather than just a full deserializer), then you can use that. You could also define a proto2 proto type with everything as extension fields, and use the extension API. Or if you know the expected layout of your specific object, you can just declare your own type either in .proto, or perhaps not even that. Names don't need to match, just the field numbers and types. For example, with protobuf-net (.NET) the following would work with your scenario:
class SomeType {
[ProtoMember(1)] public int A {get;set;}
[ProtoMember(2)] public int A {get;set;}
[ProtoMember(3)] public bool A {get;set;}
}
...
var obj = Serializer.Deserialize<SomeType>(source);
Console.WriteLine(obj.A); // int
Console.WriteLine(obj.B); // int
Console.WriteLine(obj.C); // bool
There is extra "padding/fluff", which is why I recommend a reader/parser library, but... it isn't that difficult.
Upvotes: 1