Protocol buffers 关于protobuf重复变分译码

我使用charles并从其他iOS应用程序获得了一条protobuf http消息。现在我想生成相同的http数据包，但输出不相同。

我的protobuf文件：

message TTCreateConversationBody
{
    repeated uint32 imUid1 = 2;
}

我使用的是objective-c：

    TTCreateConversationBody *body = [TTCreateConversationBody new];

    GPBUInt32Array *arr = [[GPBUInt32Array alloc] initWithCapacity:2];
    [arr addValue:123123];
    [arr addValue:9999999];

    body.imUid1Array = arr;

我的输出charles将其解码为长度分隔字符串：

这是原始数据和我的：

8A-26-10-08-01-10-AE-F7-81-80-9F-03-10-D4-E4-82-F0-D2-01
8A-26-10-08-01-12-0C-F9-F6-C3-9D-FA-02-AE-F7-81-80-9F-03

---

正确的protobuf文件格式是什么？

它们实际上都是有效的。。。伊什

这归结为“压缩”字段；如果没有“压缩”，两个整数将被编码为

• [标题，变量][值][标题，变量][值]
• [10] [AE-F7-81-80-9F-03][10][D4-E4-82-F0-D2-01]

与“打包”一样，它变成了

• [标题，字符串][长度][值][值]
• [12] [0C][F9-F6-C3-9D-FA-02][AE-F7-81-80-9F-03]

注意：两次运行中的实际值看起来非常不同。。。我想那是偶然的

:

协议缓冲区解析器必须能够解析编译为打包的重复字段，就像它们没有打包一样，反之亦然。这允许以向前和向后兼容的方式向现有字段添加[packed=true]

---

因此：序列化程序应该编写由数据是否“打包”定义的布局，但解码器必须能够以任何方式处理它。有些库在遇到应该“打包”的数据时：确定哪种布局实际上更短，并根据这一点做出最终决定。实际上，这可以近似为“只要至少有两个项目，就使用压缩编码”。

你是对的，这两个项目都是正确的。我将格式更改为

重复uint64 imUid1=2和服务器接受它。