解析 FETCH 多个 UID答案

【问题标题】：Parsing FETCH multiple UID解析 FETCH 多个 UID
【发布时间】：2015-07-17 19:31:18
【问题描述】：

我需要编写一个 IMAP 代码来解析这个命令的结果：

tag FETCH 1,2,3,4 ALL

大多数时候，响应是这样的

* 1 FETCH (FLAGS ... ) ENVELOPE ("time" "subject" ... )\r\n
* 2 FETCH (FLAGS ... ) ENVELOPE ("time" "subject" ... )\r\n
....
tag OK FETCH COMPLETE

以此类推，每个信封以星号 UID 开头，以 CRLF 结尾，因此我可以使用 CRLF 作为解析点。

问题是一些服务器使用 IMAP 字符串文字来响应我，即 {150}\r\n .... 由于 \r\n 是字符串文字的一部分，我不能再将其用作解析点。

一个想法是使用 * UID 作为解析点，但如果有人碰巧将它用作电子邮件主题或其他类似的东西，它会破坏算法，所以我认为这样做是个坏主意。

谁能告诉我如何在不使用 CRLF 的情况下有效地解析这种类型的响应？非常感谢你。

编辑 - 希望改进问题，我正在尝试根据解析点将每个单独的 ENVELOPE 解析为它自己的字符串，我需要一个解析点来标识一个字符串的开头和另一个字符串的结尾。

【问题讨论】：

标签： imap envelope

【解决方案1】：

您需要的技巧是区分两种换行符，并且它存在：开始阅读，阅读直到看到 CRLF，然后查看您所拥有的开头。标记空间是 OK、NO、BAD 还是 PREAUTH？如果是这样，你有一个完整的回应。如果没有，请查看最后 10-15 个字符。它们是“{”、一个数字、可选的加号、“}”和 CRLF？如果是这样，请阅读直到下一个 CRLF 并重复。如果没有，你有一个完整的回应。

请注意，在 IMAP 中，您必须先处理响应，然后才能解析下一个响应。如果你不这样做，MSN 处理就会中断，可能还有其他问题。

【讨论】：

谢谢你。您的答案的第二部分是正确的，我需要寻找没有出现在 } 之后的 CRLF。但是，对于您答案的第一部分，OK、NO、BAD 仅在 FETCH 结束时出现一次。因此，你可以获取 1000 个信封，最后只有一个 OK，所以这些不能没有解析点。
另外，为什么你说你必须在处理下一个响应之前采取行动？什么意思？
嗯，最后必须有一个标记好的 OK，但是服务器可以发送任意数量的未标记的额外 OK 响应，无论出于何种原因。常见原因包括想要发送响应代码并击败 NAT 中间盒。当您发送 A UID FETCH 1000:1200 ... 时，您可能会收到 * FETCH、* EXPUNGE、* FETCH、A OK。（或者你可能会得到 * FETCH, * OK [VANISHED], * FETCH, A OK 如果 RFC7162 正在使用中。）第二个 FETCH 的正确解析取决于介入的 EXPUNGE（或 VANISHED）的处理。
请注意，服务器可以并且经常会为您没有请求的消息发送 FETCH 响应。尝试同时与另一个客户端一起阅读邮件：服务器将在设置了 \seen 标志时通知两个客户端，即使一个客户端实际上并没有要求被告知。