EML 文件中的 RTF 消息正文
我们使用 LumiSoft .NET MIME 库 用于创建 EML 文件。这些 EML 文件是由数据库值构建的。电子邮件正文可以是纯文本、RTF 或 HTML。我们知道主体何时为 HTML，因此，当发生这种情况时，我们的 EML 文件的内容类型将使用以下行设置：
Content-Type: text/html; charset="utf-8"
当主体为纯文本或 RTF（因为我们不知道它是什么）时，我们设置内容-像这样输入 RTF
Content-Type: text/rtf; charset="utf-8".
HTML EML 文件在不同的产品中显示得很好...但是 RTF EML 文件似乎由不同的产品以不同的方式解释。这种方法多年来一直有效，我们生成的 EML 文件针对 Outlook Express 进行了 QA，并且它们显示正常。但最近，一些客户报告了这些电子邮件以邮件正文作为附件显示的问题。在 Outlook 2007 SP2 和 Outlook 2010 中，电子邮件正文确实显示为附加到电子邮件的 TXT 文件...并且电子邮件本身内的正文是空的。此外，我们使用名为 dtSearch 的产品，当它将这些 EML 文件转换为 HTML 时，它会执行类似的转换，其中 EML 文件的正文显示在名为 Attachment0.DAT 的附件的内容中。此外，我们还通过 Outlook Redemption 处理这些 EML 文件，就像 Outlook 2010 一样，邮件正文位于 TXT 文件附件中。如此奇怪的行为......这是它的一些实际操作的屏幕截图。
Outlook Express：
Outlook 2010：
是我们使用 RTF 作为内容类型在这里做错了什么？它似乎过去曾工作过并且与 Outlook Express 一起工作。建议使用 Redemption 切换到 MSG 格式而不是 EML 格式来缓解这种情况，但我相信这对 Outlook 或 MAPI 库的用户计算机提出了先决条件要求......但如果 EML 格式未解析不同的产品都是一样的，那么也许 MSG 格式是正确的选择。
We use the LumiSoft.NET MIME library to create EML files. These EML files are constructed by database values. The body of the email can be plain text, RTF, or HTML. We know when the body is HTML so, when that occurs, our EML file's content-type is set with this line:
Content-Type: text/html; charset="utf-8"
When the body is plain text or RTF (because we don't know which it is), we set the content-type to RTF like so
Content-Type: text/rtf; charset="utf-8".
The HTML EML files show up just fine across different products... but the RTF EML files seem to be interpreted differently by different products. This worked for years and our resulting EML files were QA'd against Outlook Express and they appeared normally. But recently we had some customers report issues with these emails showing up with the message bodies as attachments. In Outlook 2007 SP2 and Outlook 2010, the email bodies do indeed show up as TXT files that are attached to the email... and the bodies inside the email itself are empty. Furthermore, we use a product called dtSearch and when it converts these EML files to HTML, it does a similar translation where the body of the EML file is shown in the content of an attachment named Attachment0.DAT. Futhermore, we also process these EML files through Outlook Redemption and, just like Outlook 2010, the message bodies are in a TXT file attachment. So weird behavior across the board... here's some screenshot of it in action.
Outlook Express:
Outlook 2010:
Are we doing something wrong here by using RTF for the content type? It seems to have worked in the past and works with Outlook Express. It's been recommended to switch to the MSG format using Redemption instead of EML format to alleviate this but I believe that puts a prerequisite requirement on the user machine of either Outlook or the MAPI library.... but if the EML format isn't parsed the same by different products, then maybe the MSG format is the way to go.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
电子邮件的内容看起来不像有效的 rtf（没有幻数“{\rtf”）。
它是带有引用的可打印传输编码的纯文本。
您应该使用内容类型：text/plain。
The content of the email does not look like a valid rtf (No magic number "{\rtf").
It's plain text with quoted printable transfer encoding.
You should use content-type: text/plain.