Yes, we suspect the problem is in the transmit from .Net as well due
to the truncation at 1st NULL char in the Unicode string. I'm sending
the data back as a TIBCO message which also adds the field as a
string. Do you think if I use the AddField(string, byte[]) overload,
it'll work on the server?


On Apr 4, 6:04 am, Marc Gravell <> wrote:
> I've just been looking more - and ParseFromString should do the job.
> I /suspect/ the problem is the definition a "string"... you aren't
> going to be able to treat raw binary in .NET as a String; you are
> going to have to treat it as a Stream or a byte[], or you can encode
> it to base-64 (as above) to get something that *can* be treated as a
> String.
> Either as binary or a base-64, you would then transfer that to the
> server. At the server, ProtoBuf again expects raw binary, but in a C++
> string (if you have used base-64 as a transfer mechanism, you would
> have to decode the base-64 back to binary). You should then be able to
> mount that data into a C++ string (or an istream).
> My best guess is that at the moment you are losing data during
> transfer (as above).
> What mechanism are you using to transfer the data? If it is a network
> socket (for example) you should be able to just send binary, without
> ever touching a .NET string; likewise HTTP can be used without
> creating a .NET string.
> Marc
You received this message because you are subscribed to the Google Groups 
"Protocol Buffers" group.
To post to this group, send email to
To unsubscribe from this group, send email to
For more options, visit this group at

Reply via email to