Android protobuf - 从其中包含单个 GUID 的响应中解析 GUID

Question

我们有 .NET protobuf web 服务，其中之一返回单个 GUID 作为响应，如下所示:

return newItemGuid;

如何从Android代码中读取这个值？我们收到 20 个字节的响应，将它们传递给 parseFrom(byte[]) 或 parseFrom(InputStream) 不起作用 - 返回值为空 指导.

如何正确解析这样的响应？

这里是来自响应的字节:

[10, 18, 9, 73, -7, 96, 69, -115, -33, 29, 68, 17, -107, -110, -92, 46, -100, -113, -10, -64]

GUID 应该是:4c6640a7-c955-4c34-b2d7-7b470cba4a9c

Answer 1

好吧，我在这里向你道歉；基本上，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
}

So - 包含两个字段的子消息，lo 和 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

这是...是的，这有点糟糕。糟糕的设计选择。如果我可以返回并重新做出该决定，我会将其设为预期长度为 16 的 bytes，并且我会修复字节顺序。嗯，事后诸葛亮。然而，在不影响现有代码的情况下恢复多年前做出的错误决定是非常有问题的。

所以这是 18 个字节。最后 2 个字节几乎肯定是前导 0A-12，这意味着“字段 1，长度分隔:18 字节”。

所以；您有以下选择:

• 解码为 lo/hi 对，并解释疯狂的字节顺序(对此我只能道歉)
• 更改 .NET 代码以将值广告为 byte[] 而不是
• 还有一个案例需要以开箱即用的理智方式实现 Guid 的功能请求；我同意现有的实现坦率地说:不好 - 但是必须选择加入，以避免倒退