Into the parseString you can pass the serialized omitting the last char, like ParseFromString(serialized[0:-1]).
That seemed to work for me. -S On Thursday, March 28, 2013 2:27:43 AM UTC-7, Oliver wrote: > > On Thu, Mar 28, 2013 at 12:54 AM, W. David Jarvis <vena...@gmail.com > <javascript:>> wrote: > >> If I compare the len() of the two strings (pre-writing/reading v. >> post-writing/reading) I tend to get two add'l chars on the reading, so I >> guess I'm confused by how this is getting truncated? Is python running into >> a newline char and interpreting it literally somehow? > > > Don't use 'print', use file.write(). Using print adds a newline (or > probably CRLF in your case). The encoded form is not self-delimiting so if > you include an extra CRLF in the bytes given to the decoder, it'll happily > try to interpret them, and then run out of data because the decoder's > interpretation of the extra bytes implies there should be more data > following them. > > I wouldn't rely on sys.stdout being binary-safe either. The encoded forms > are binary, not text - you should treat them as such - if any conversion of > linefeeds happens, it will corrupt the message. > > Oliver > > -- You received this message because you are subscribed to the Google Groups "Protocol Buffers" group. To unsubscribe from this group and stop receiving emails from it, send an email to protobuf+unsubscr...@googlegroups.com. To post to this group, send email to protobuf@googlegroups.com. Visit this group at http://groups.google.com/group/protobuf. For more options, visit https://groups.google.com/d/optout.
