It uses invalid UTF-8 chars all over the place, I guess it assumes text to be Latin-1.
‚¤¨£ - all those chars would be two bytes in utf-8, and even worse, you'll have to escape high utf-8 characters thus making your MsgPack message bigger than JSON if you're unlucky enough.
> This is by design. MessagePack doesn't have string type but only bytes type. So decoding bytes to string is application layer business.
So it looks like all of the claims of "just change one line of code" (and also most of these benchmarks) aren't quite true: unless you can guarantee your input text is ASCII, technically you have to first traverse your objects and replace all strings with decoded byte arrays. I would think that would be a dealbreaker for any user input.
Comments
What problems does it have with UTF-8?
It uses invalid UTF-8 chars all over the place, I guess it assumes text to be Latin-1.
‚¤¨£ - all those chars would be two bytes in utf-8, and even worse, you'll have to escape high utf-8 characters thus making your MsgPack message bigger than JSON if you're unlucky enough.
According to https://github.com/msgpack/msgpack/issues/26 it doesn't handle strings at all:
> This is by design. MessagePack doesn't have string type but only bytes type. So decoding bytes to string is application layer business.
So it looks like all of the claims of "just change one line of code" (and also most of these benchmarks) aren't quite true: unless you can guarantee your input text is ASCII, technically you have to first traverse your objects and replace all strings with decoded byte arrays. I would think that would be a dealbreaker for any user input.