好的,在这里我欠你一个道歉;基本上,使用的 protobuf-net 的 v1 版本Guid.ToByteArray
——如果我必须给它一个名字——我将不得不称之为“crazy-endian”——它使用了可能是一个糟糕的布局设计选择。为了说明“crazy-endian”:
var guid = new Guid("00112233445566778899AABBCCDDEEFF");
var msBlob = guid.ToByteArray();
var msHex = BitConverter.ToString(msBlob);
显然......msHex
是字符串:
33-22-11-00-55-44-77-66-88-99-AA-BB-CC-DD-EE-FF
您应该能够在上面看到每个输入/输出字节如何映射;我的意思是,谁不会选择它作为显而易见的选择Guid.ToByteArray
?只是……叹息。
好的,所以...这很奇怪...但是:当 v1 选择使用ToByteArray
. 虽然,IIRC 注意到当 v2 需要证明兼容性时它是多么奇怪(v2 最初假设它是以“理智”的方式实现的,并且立即通过了所有测试)。
现在,protobuf-net 使用bcl.proto中定义的布局,具体来说:
message Guid {
optional fixed64 lo = 1; // the first 8 bytes of the guid
optional fixed64 hi = 2; // the second 8 bytes of the guid
}
lo
所以 - 包含两个字段 a和 a的子消息hi
。字段 1 fixed64 和字段 2 fixed64 的字段标题分别是09
和11
,所以我们应该期望:
09-33-22-11-00-55-44-77-66-11-88-99-AA-BB-CC-DD-EE-FF
这是...是的,这有点糟糕。一个糟糕的设计选择。如果我可以返回并重新做出该决定,我会将其bytes
设为预期长度 16,并且我会修复字节顺序。好吧,事后诸葛亮是伟大的。然而,在不影响现有代码的情况下恢复多年前做出的错误决定是非常有问题的。
所以这是18个字节。最后 2 个字节几乎可以肯定是一个前导0A-12
,这意味着“字段 1,长度分隔:18 个字节”。
所以; 你有选择:
- 解码为
lo
/hi
对,并解释疯狂的字节顺序(对此我无能为力,但道歉)
- 更改 .NET 代码以将值宣传为
byte[]
a
- 还有一个案例可以让功能请求以
Guid
一种开箱即用的方式实现;我同意,坦率地说,现有的实现是:不好 - 但是必须选择加入,以避免回归