Python 取消序列化从telegram.org服务器返回的msg_容器对象

我无法反序列化

msg\u容器

对象。问题似乎在于我对

标志

字段在

消息

中的位置的理解，因为这对我来说没有意义。我的以下假设来自阅读本页：

这是我看到的，我希望有人能澄清

来自电报服务器的响应如下所示：

    ('server_answer: ', '\xdc\xf8\xf1s\x02\x00\x00\x00\x018\xcb\x8cCu\xcdW\x01\x00\x00\x00\x1c\x00\x00\x00\x08\t\xc2\x9e\x00t\xbe?Cu\xcdW\x82\x0e:\x11\xe0\xda\xed\x05\xd7\xbezI4\x05Tf\x01\xdc\xcb\x8cCu\xcdW\x02\x00\x00\x00\x14\x00\x00\x00Y\xb4\xd6b\x15\xc4\xb5\x1c\x01\x00\x00\x00\x00t\xbe?Cu\xcdW')

 0 | DC F8 F1 73 02 00 00 00
 8 | 01 38 CB 8C 43 75 CD 57
16 | 01 00 00 00 1C 00 00 00
24 | 08 09 C2 9E 00 74 BE 3F
32 | 43 75 CD 57 82 0E 3A 11
40 | E0 DA ED 05 D7 BE 7A 49
48 | 34 05 54 66 01 DC CB 8C
56 | 43 75 CD 57 02 00 00 00
64 | 14 00 00 00 59 B4 D6 62
72 | 15 C4 B5 1C 01 00 00 00
80 | 00 74 BE 3F 43 75 CD 57

msg_container#73f1f8dc messages:vector<message> = MessageContainer;

message#c09be45f flags:# out:flags.1?true mentioned:flags.4?true media_unread:flags.5?true silent:flags.13?true post:flags.14?true id:int from_id:flags.8?int to_id:Peer fwd_from:flags.2?MessageFwdHeader via_bot_id:flags.11?int reply_to_msg_id:flags.3?int date:int message:string media:flags.9?MessageMedia reply_markup:flags.6?ReplyMarkup entities:flags.7?Vector<MessageEntity> views:flags.10?int edit_date:flags.15?int = Message;
messageService#9e19a1f6 flags:# out:flags.1?true mentioned:flags.4?true media_unread:flags.5?true silent:flags.13?true post:flags.14?true id:int from_id:flags.8?int to_id:Peer reply_to_msg_id:flags.3?int date:int action:MessageAction = Message;

表示一个

MessageContainer

对象，如下所示：

    ('server_answer: ', '\xdc\xf8\xf1s\x02\x00\x00\x00\x018\xcb\x8cCu\xcdW\x01\x00\x00\x00\x1c\x00\x00\x00\x08\t\xc2\x9e\x00t\xbe?Cu\xcdW\x82\x0e:\x11\xe0\xda\xed\x05\xd7\xbezI4\x05Tf\x01\xdc\xcb\x8cCu\xcdW\x02\x00\x00\x00\x14\x00\x00\x00Y\xb4\xd6b\x15\xc4\xb5\x1c\x01\x00\x00\x00\x00t\xbe?Cu\xcdW')

 0 | DC F8 F1 73 02 00 00 00
 8 | 01 38 CB 8C 43 75 CD 57
16 | 01 00 00 00 1C 00 00 00
24 | 08 09 C2 9E 00 74 BE 3F
32 | 43 75 CD 57 82 0E 3A 11
40 | E0 DA ED 05 D7 BE 7A 49
48 | 34 05 54 66 01 DC CB 8C
56 | 43 75 CD 57 02 00 00 00
64 | 14 00 00 00 59 B4 D6 62
72 | 15 C4 B5 1C 01 00 00 00
80 | 00 74 BE 3F 43 75 CD 57

msg_container#73f1f8dc messages:vector<message> = MessageContainer;

message#c09be45f flags:# out:flags.1?true mentioned:flags.4?true media_unread:flags.5?true silent:flags.13?true post:flags.14?true id:int from_id:flags.8?int to_id:Peer fwd_from:flags.2?MessageFwdHeader via_bot_id:flags.11?int reply_to_msg_id:flags.3?int date:int message:string media:flags.9?MessageMedia reply_markup:flags.6?ReplyMarkup entities:flags.7?Vector<MessageEntity> views:flags.10?int edit_date:flags.15?int = Message;
messageService#9e19a1f6 flags:# out:flags.1?true mentioned:flags.4?true media_unread:flags.5?true silent:flags.13?true post:flags.14?true id:int from_id:flags.8?int to_id:Peer reply_to_msg_id:flags.3?int date:int action:MessageAction = Message;

因此，我假设接下来的四个字节将是第一条消息中的第一个参数，即

flags

字段。但这四个字节的值是

8ccb3801

，它是一个无符号整数2362128385L，对于一个简单的位掩码来说，这个值大得令人怀疑。另外，如果我使用这个值从字节流的其余部分反序列化可选参数，它们就没有意义，最终会因类型不匹配而失败。我尝试将

标志

字段作为有符号整数，结果也类似

---

我对电报服务器如何使用msg_container对象响应的理解有什么不正确之处？

以下是一种处理包装在容器中的邮件的简单方法：

Container_type_header
Content_count
[messages]

每封邮件都是这样包装的：

msgs_id
seq_no
mgs_len
msg_body

根据您的示例数据：

DCF8F173 --> container_type_header
02000000 --> message_count_in_container

0138CB8C4375CD57 --> msg_id of first message
01000000 --> seq_no of first message
1C000000 --> length of first message; 1C == 28 bytes
0809C29E0074BE3F4375CD57820E3A11E0DAED05D7BE7A4934055466 --> 28 byte msg_body

01DCCB8C4375CD57 --> msg_id of second message
02000000 --> seq_number of second message
14000000 --> lenght of second message; 14 == 20 bytes
59B4D66215C4B51C010000000074BE3F4375CD57 --> 20 byte msg_body

解码后的第一条信息给出：

0809C29E0074BE3F4375CD57820E3A11E0DAED05D7BE7A4934055466

New_Session_Created{first_msg_id: 6326841983218119680,  server_salt: 7373524212041563863, unique_id: 427238195566612098}

0x59B4D66215C4B51C010000000074BE3F4375CD57 

Msgs_Ack{msg_ids: [6326841983218119680]}

解码后的第二条消息给出：

0809C29E0074BE3F4375CD57820E3A11E0DAED05D7BE7A4934055466

New_Session_Created{first_msg_id: 6326841983218119680,  server_salt: 7373524212041563863, unique_id: 427238195566612098}

0x59B4D66215C4B51C010000000074BE3F4375CD57 

Msgs_Ack{msg_ids: [6326841983218119680]}

---

哇，我一个人永远也不会想到这一点。这有什么记录吗？这似乎与其他数据类型的工作方式不一致，因为我找不到包含以下内容的数据类型：msg_id、seq_number、length、msg_body