Android protobuf - 从响应中解析 GUID，其中包含单个 GUID答案

【问题标题】：Android protobuf - parse GUID from response with single GUID in itAndroid protobuf - 从响应中解析 GUID，其中包含单个 GUID
【发布时间】：2013-08-06 12:41:06
【问题描述】：

我们有 .NET protobuf Web 服务，其中一个会返回一个 GUID 作为响应，如下所示：

return newItemGuid;

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

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

以下是响应的字节数：

[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

【问题讨论】：

好吧，一个 guid 不是 20 字节；它是 16 个字节。您有我们可以看到的这 20 个字节的示例吗？理想情况下它代表的指南？例如，这可能是 guid 的 base-64 编码的 ASCII 吗？（嗯......不，那将是 24 个字节）
Protobuf 添加了一些额外的数据，这就是它不是纯 16 字节的原因。奇怪的是它的parseFrom() 方法并没有正确使用传递的值。
哇；我什至没有注意到这是一个 protobuf-net 问题！（这很讽刺）；一会儿……

标签： android web-services protocol-buffers guid protobuf-net

【解决方案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 最初假设它是以“理智”的方式实现的，并立即通过了所有测试）。 p>

现在，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 和 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；我同意坦率地说，现有的实现是：不好 - 但是必须选择加入，以避免回归

【讨论】：