Confusing google protobuf field
I'm analysing some protobuf data using https://protogen.marcgravell.com/decode and i cannot make sense of this:
I'm reading through the protobuf encoding guide and i can see the data doesn't have to be a string, but rather something length-delimited string, bytes, embedded messages, packed repeated fields
What i don't understand is why it has a perfectly good string apples1
in field 105, but then 3x random empty payloads for the same field 105? Is this just some oddness with the 3rd parties use of protbufs that i'm looking at, or is it something else i'm missing?
Thanks in advance.
c++ protocol-buffers
add a comment |
I'm analysing some protobuf data using https://protogen.marcgravell.com/decode and i cannot make sense of this:
I'm reading through the protobuf encoding guide and i can see the data doesn't have to be a string, but rather something length-delimited string, bytes, embedded messages, packed repeated fields
What i don't understand is why it has a perfectly good string apples1
in field 105, but then 3x random empty payloads for the same field 105? Is this just some oddness with the 3rd parties use of protbufs that i'm looking at, or is it something else i'm missing?
Thanks in advance.
c++ protocol-buffers
Well, theapple1
string suggests that this is test data, but in real life situations there's nothing particularly unusual about empty string fields, think e.g. address line 2.
– 500 - Internal Server Error
Nov 13 '18 at 18:19
add a comment |
I'm analysing some protobuf data using https://protogen.marcgravell.com/decode and i cannot make sense of this:
I'm reading through the protobuf encoding guide and i can see the data doesn't have to be a string, but rather something length-delimited string, bytes, embedded messages, packed repeated fields
What i don't understand is why it has a perfectly good string apples1
in field 105, but then 3x random empty payloads for the same field 105? Is this just some oddness with the 3rd parties use of protbufs that i'm looking at, or is it something else i'm missing?
Thanks in advance.
c++ protocol-buffers
I'm analysing some protobuf data using https://protogen.marcgravell.com/decode and i cannot make sense of this:
I'm reading through the protobuf encoding guide and i can see the data doesn't have to be a string, but rather something length-delimited string, bytes, embedded messages, packed repeated fields
What i don't understand is why it has a perfectly good string apples1
in field 105, but then 3x random empty payloads for the same field 105? Is this just some oddness with the 3rd parties use of protbufs that i'm looking at, or is it something else i'm missing?
Thanks in advance.
c++ protocol-buffers
c++ protocol-buffers
edited Nov 13 '18 at 18:16
Spark
asked Nov 13 '18 at 13:12
SparkSpark
4031320
4031320
Well, theapple1
string suggests that this is test data, but in real life situations there's nothing particularly unusual about empty string fields, think e.g. address line 2.
– 500 - Internal Server Error
Nov 13 '18 at 18:19
add a comment |
Well, theapple1
string suggests that this is test data, but in real life situations there's nothing particularly unusual about empty string fields, think e.g. address line 2.
– 500 - Internal Server Error
Nov 13 '18 at 18:19
Well, the
apple1
string suggests that this is test data, but in real life situations there's nothing particularly unusual about empty string fields, think e.g. address line 2.– 500 - Internal Server Error
Nov 13 '18 at 18:19
Well, the
apple1
string suggests that this is test data, but in real life situations there's nothing particularly unusual about empty string fields, think e.g. address line 2.– 500 - Internal Server Error
Nov 13 '18 at 18:19
add a comment |
1 Answer
1
active
oldest
votes
There's nothing especially unusual about empty strings; however, it is also entirely possible that they are sub-messages - just objects without any interesting properties. A nil (not assigned / null / etc) sub-message won't be present at all, but a non-nil sub-message without any interesting content will be: a zero-byte binary string (in protobuf terms).
Likewise: a bytes
field that is explicitly assigned a zero-length buffer: will be a zero-byte binary string. And: a "packed" array with zero elements: will be a zero-byte binary string.
So: nothing unusual here - that's perfectly normal and expected protobuf for a range of scenarios.
Since the field number doesn't change, it sounds like something like:
repeated string whatever = 105;
i.e.
obj.Whatever = [ "apples1", "", "", "" ];
Odd, but not invalid.
Ahh that makes more sense, thanks for your help Marc, and the decoding tool!
– Spark
Nov 13 '18 at 22:02
add a comment |
Your Answer
StackExchange.ifUsing("editor", function ()
StackExchange.using("externalEditor", function ()
StackExchange.using("snippets", function ()
StackExchange.snippets.init();
);
);
, "code-snippets");
StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "1"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);
else
createEditor();
);
function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader:
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
,
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);
);
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53281785%2fconfusing-google-protobuf-field%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
There's nothing especially unusual about empty strings; however, it is also entirely possible that they are sub-messages - just objects without any interesting properties. A nil (not assigned / null / etc) sub-message won't be present at all, but a non-nil sub-message without any interesting content will be: a zero-byte binary string (in protobuf terms).
Likewise: a bytes
field that is explicitly assigned a zero-length buffer: will be a zero-byte binary string. And: a "packed" array with zero elements: will be a zero-byte binary string.
So: nothing unusual here - that's perfectly normal and expected protobuf for a range of scenarios.
Since the field number doesn't change, it sounds like something like:
repeated string whatever = 105;
i.e.
obj.Whatever = [ "apples1", "", "", "" ];
Odd, but not invalid.
Ahh that makes more sense, thanks for your help Marc, and the decoding tool!
– Spark
Nov 13 '18 at 22:02
add a comment |
There's nothing especially unusual about empty strings; however, it is also entirely possible that they are sub-messages - just objects without any interesting properties. A nil (not assigned / null / etc) sub-message won't be present at all, but a non-nil sub-message without any interesting content will be: a zero-byte binary string (in protobuf terms).
Likewise: a bytes
field that is explicitly assigned a zero-length buffer: will be a zero-byte binary string. And: a "packed" array with zero elements: will be a zero-byte binary string.
So: nothing unusual here - that's perfectly normal and expected protobuf for a range of scenarios.
Since the field number doesn't change, it sounds like something like:
repeated string whatever = 105;
i.e.
obj.Whatever = [ "apples1", "", "", "" ];
Odd, but not invalid.
Ahh that makes more sense, thanks for your help Marc, and the decoding tool!
– Spark
Nov 13 '18 at 22:02
add a comment |
There's nothing especially unusual about empty strings; however, it is also entirely possible that they are sub-messages - just objects without any interesting properties. A nil (not assigned / null / etc) sub-message won't be present at all, but a non-nil sub-message without any interesting content will be: a zero-byte binary string (in protobuf terms).
Likewise: a bytes
field that is explicitly assigned a zero-length buffer: will be a zero-byte binary string. And: a "packed" array with zero elements: will be a zero-byte binary string.
So: nothing unusual here - that's perfectly normal and expected protobuf for a range of scenarios.
Since the field number doesn't change, it sounds like something like:
repeated string whatever = 105;
i.e.
obj.Whatever = [ "apples1", "", "", "" ];
Odd, but not invalid.
There's nothing especially unusual about empty strings; however, it is also entirely possible that they are sub-messages - just objects without any interesting properties. A nil (not assigned / null / etc) sub-message won't be present at all, but a non-nil sub-message without any interesting content will be: a zero-byte binary string (in protobuf terms).
Likewise: a bytes
field that is explicitly assigned a zero-length buffer: will be a zero-byte binary string. And: a "packed" array with zero elements: will be a zero-byte binary string.
So: nothing unusual here - that's perfectly normal and expected protobuf for a range of scenarios.
Since the field number doesn't change, it sounds like something like:
repeated string whatever = 105;
i.e.
obj.Whatever = [ "apples1", "", "", "" ];
Odd, but not invalid.
answered Nov 13 '18 at 18:49
Marc Gravell♦Marc Gravell
780k19421342543
780k19421342543
Ahh that makes more sense, thanks for your help Marc, and the decoding tool!
– Spark
Nov 13 '18 at 22:02
add a comment |
Ahh that makes more sense, thanks for your help Marc, and the decoding tool!
– Spark
Nov 13 '18 at 22:02
Ahh that makes more sense, thanks for your help Marc, and the decoding tool!
– Spark
Nov 13 '18 at 22:02
Ahh that makes more sense, thanks for your help Marc, and the decoding tool!
– Spark
Nov 13 '18 at 22:02
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53281785%2fconfusing-google-protobuf-field%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Well, the
apple1
string suggests that this is test data, but in real life situations there's nothing particularly unusual about empty string fields, think e.g. address line 2.– 500 - Internal Server Error
Nov 13 '18 at 18:19