这个问题有点长，但我花了好几个小时都无济于事。我有一些代码可以在Web服务器上生成电子邮件文件，并允许用户下载该电子邮件并在Outlook中打开它。从这里开始，他们可以在将电子邮件发送给一群人之前对其进行各种手动更改。
现在，我生成一个.OFT文件，它基本上是一个电子邮件模板。我想要做的是生成.MSG文件，这是一个实际的电子邮件。从二进制的角度来看，似乎这些文件格式是相同的。它们具有相同的Stream ID和属性以及内容。
我的方法是先在Outlook中创建一个空白的电子邮件，然后将其保存到名为Base.oft的文件中。在我的代码中，我打开文档并修改流ID __substg1.0_1013001E，这是HTML电子邮件正文的ID。然后我保存文件并将其写入cilent。这非常有效。
我尝试了与MSG格式相同的方法。我创建了一封空白电子邮件，将其保存为Base.msg，并修改了相同的Stream ID。如果我查看生成的文件，新实体就在那里并保存。但是，如果我打开电子邮件，则正文仍为空白。
如果我在Outlook中键入一个正文并将其保存到基本文件中，那么甚至更奇怪的是，我可以在流0_1013001E下看到该正文。如果我然后使用不同的主体修改该流，我可以验证新主体确实保存在文件中，但如果我在Outlook中打开该消息，我会看到旧的原始主体。好像电子邮件正文存储在.MSG格式的文件中的不同位置，但是我查看了每个流，但找不到任何看起来像是电子邮件正文的内容。
也许.MSG文件是加密的，或者它们的主体以某种专有的二进制格式存储，而不像.OFT文件？希望有人对此有一些了解，因为我搜索了互联网，基本上没有发现这些格式。
更新
似乎.MSG格式将正文存储在流ID __substg1.0_10090102中 - 它以某种二进制形式编码（不确定是什么。）如果我删除了流（或将其设置为单个{{1} }，文件已损坏。
答案 0 :(得分：3)
首先，要查找有关此主题和相关主题的更多信息，请远离原始子流数和谷歌以获取相应的MAPI属性。例如，1013是PR_HTML，1009是PR_RTF_COMPRESSED。 MAPI具有将身体从一种格式同步到另一种格式的方法。
有关所有与内容相关的MAPI属性（即.MSG文件中的不同“流”）的详细概述，请参阅MSDN上的this文章。
要编写PR_RTF_COMPRESSED，请将流包装在WrapCompressedStream中。另一方面，在您的特定情况下，您可能希望避免代码中的MAPI依赖性，因此您最好找到PR_STORE_SUPPORT_MASK并设置STORE_UNCOMPRESSED_RTF位。这将允许您在PR_RTF_COMPRESSED子流中使用直接RTF。或者，如果你感觉很勇敢，那么Outlook会看上去很好的html-wrapped-in-rtf。
这些东西都不适合胆小的人，但看看你是如何处理原始的.MSG子流写作，我猜它是可行的。
答案 1 :(得分：0)
说到格式，没有区别。 唯一的区别是OFT文件有CLSID_TemplateMessage（{0006F046-0000-0000-C000-000000000046}）作为存储类（WriteClassStg），而MSG文件使用CLSID_MailMessage（{00020D0B-0000-0000-C000-000000000046}）