在使用gRPC在C和Python之间传输二进制数据的时候发现，明明客户端发送的都是等长的二进制bytes，服务端收到的却是长短不一的bytearray。
基于对著名框架的信赖，只考虑可能输入数据的问题。浪费了一天时间后突然意识到也没有可能是本身通讯框架的问题？
用谷歌检索了英文网站发现果然有人提到了类似的情况：https://stackoverflow.com/questions/47373976/why-is-my-protobuf-message-in-python-ignoring-zero-values，即 “0” 被忽略了！
也就是说如果一个10 bytes长的字节流是 0123456789 (此处为简单理解，对二进制数据使用十进制表示法），那么只能收到 123456789。如果0出现在首尾还好说，如果出现在中间那就彻底破坏了二进制流的结构。尽管protobuf解释了自己这样设计的缘由是为了节省通讯资源，但是为了解决这个问题，我不得不使用更多的资源……因为我需要将二进制的bytes转写成string，反而增加了数据量。
由于对gRPC的涉猎较浅，不确定该问题是否有更通用的解决方法，如果对该问题有了解，欢迎指正。
