【问题标题】:string reading problem through IMAP通过 IMAP 读取字符串的问题
【发布时间】:2012-02-12 20:14:18
【问题描述】:

我正在处理 IMAP,所以只是读取正文 (body[header.fields (DATE FROM SUBJECT)]) 我正在传递这个命令。

但问题就像有一段时间我的字符串从我的原始字符串中返回了额外的东西。 有时我得到有限的部分字符串意味着身体的一半。 所以每当我传递第二个命令时,它都会接受作为第一个命令并返回结果作为 第一个命令等待结果;

所以我担心的是我无法检索身体部位的正确数据。

据我所知,我认为这是由于 Internet 数据包 tresfersize 而发生的,但除了这个外观之外,其他邮件管理器将正常工作,所以这是什么机制 此数据正在检索。

或者我的编码要做的任何其他事情.....

谢谢..

【问题讨论】:

  • 您可以使用现有的 IMAP 库吗?这将比自己编写要容易得多。如果没有,您能否发布来自 IMAP 服务器的包含“额外内容”的示例响应?您连接到哪个 IMAP 服务器进行测试?

标签: imap


【解决方案1】:

从 IMAP 服务器发布包含“额外内容”的示例响应会有所帮助。

您最有可能面临的问题是未标记的服务器响应。

RFC3501 是这么说的:

状态响应可以加标签或不加标签。标记状态响应指示客户端命令的完成结果(OK、NO 或 BAD 状态),并具有与命令匹配的标记:

C: a002 NOOP
S: a002 OK NOOP completed

一些状态响应和所有服务器数据都没有标记。一个 未标记的响应由标记“*”而不是标记指示。

C: a047 NOOP
S: * 22 EXPUNGE
S: * 23 EXISTS
S: * 3 RECENT
S: * 14 FETCH (FLAGS (\Seen \Deleted))
S: a047 OK NOOP completed

所以你需要区分这两种响应类型。

请记住,检查收到的每行是否都以“*”字符开头是不够的,因为您的电子邮件也可能有以星号开头的行:

C:    a004 fetch 12 body[header]
S:    * 12 FETCH (RFC822 {342}
S:    Date: Wed, 17 Jul 1996 02:23:25 -0700 (PDT)
S:    From: Terry Gray <gray@cac.washington.edu>
S:    Subject: IMAP4rev1 WG mtg summary and minutes
S:    MIME-Version: 1.0
S:    
S:    * This is email body containing start char
S:    )
S:    a004 OK FETCH completed

{342} 是您应该读取的确切字节数。

底线是不要使用现有的库重新发明轮子。

你可以查看我的IMAP component(不是免费的)。

【讨论】:

  • 感谢 pawel 我在选择文件夹命令后使用了 NOOP,但问题仍然没有解决。如果你提供一些例子,那么我会感谢你..
  • NOOP 不是您问题的答案。我使用 NOOP 命令来说明 IMAP 服务器对客户端命令的响应可能包含其他信息。例如,当新电子邮件到达邮箱时,您会看到额外的“未标记响应”,通知您邮箱中的某些内容发生了变化。
猜你喜欢
  • 2016-02-06
  • 2012-04-06
  • 2020-05-17
  • 1970-01-01
  • 1970-01-01
  • 2015-01-12
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多