Outlook .MSG 和 .OFT 文件格式之间有区别吗?

发布于 2024-12-13 08:17:25 字数 955 浏览 1 评论 0原文

这个问题有点遥远,但我花了几个小时却无济于事。我有一些代码可以在网络服务器上生成电子邮件文件,并允许用户下载该电子邮件并在 Outlook 中打开它。从这里,他们可以在将电子邮件发送给一群人之前对电子邮件进行各种手动更改。

现在,我生成一个 .OFT 文件,它基本上是一个电子邮件模板。我想要做的是生成一个 .MSG 文件,这是一封实际的电子邮件。从二进制的角度来看,这些文件格式似乎是相同的。它们具有相同的流 ID 和属性等。

我的方法是首先在 Outlook 中创建一封空白电子邮件,然后将其保存到名为 Base.oft 的文件中。在我的代码中,我打开文档并修改流 ID __substg1.0_1013001E,它是 HTML 电子邮件正文的 ID。然后我保存文件并将其写给客户端。这非常有效。

我对 MSG 格式尝试了相同的方法。我创建了一封空白电子邮件,将其另存为 Base.msg,并修改相同的流 ID。如果我查看生成的文件,就会发现新的正文实际上位于其中并已保存。但是,如果我打开电子邮件,正文仍然是空白。

更奇怪的是,如果我在 Outlook 中输入正文并将其保存到基本文件中,我可以在流 0_1013001E 下看到该正文。如果我随后使用不同的正文修改该流,我可以验证新正文确实保存在文件中,但如果我在 Outlook 中打开邮件,我会看到旧的原始正文。就好像电子邮件正文以 .MSG 格式存储在文件中的不同位置,但是我查看了每个流,但找不到任何其他看起来可能是电子邮件正文的内容。

也许 .MSG 文件是加密的,或者它们的主体以某种专有的二进制格式存储,与 .OFT 文件不同?希望有人对此有一些见解,因为我在互联网上搜索并发现基本上没有关于这些格式的信息。

更新:

.MSG 格式似乎将正文存储在流 ID __substg1.0_10090102 中 - 它以某种二进制形式编码(不确定是什么。)如果我删除流(或将其设置为单个 \0,文件会损坏。

This question is somewhat of a long shot, but I've spent hours on it to no avail. I have some code that generates an email file on a webserver, and allows the user to download that email and open it in Outlook. From here, they can make various manual changes to the email before they send it to a bunch of people.

Right now, I generate a .OFT file, which is basically an email template. What I want to do is generate a .MSG file, which is an actual email. From a binary point of view, it seems these file formats are identical. They have the same Stream IDs and properties and stuff.

My approach was to first create a blank email message in Outlook and then just save it to a file called Base.oft. In my code, I open the document and modify Stream ID __substg1.0_1013001E which is the ID for the HTML email body. I then save the file and write it out to the cilent. This works perfectly.

I tried the same approach with the MSG format. I created a blank email message, saved it as Base.msg, and modify the same Stream ID. If I look at the resulting file, the new body is actually in there and saved. However, if I open the email, the body is still blank.

What's even weirder is if I type in a body in Outlook and save that to the base file, I can see that body under stream 0_1013001E. If I then modify that stream with a different body, I can verify the new body is indeed saved in the file, but if I open the message in Outlook, I see the old, original body. It's as if the email body is stored in a different place in the file for the .MSG format, however I've looked through each stream and cannot find anything else that looks like it could be an email body.

Perhaps .MSG files are encrypted, or their bodies are stored in some proprietary binary format unlike .OFT files? Hopefully someone has some insight on this, as I scoured the Internet and found basically nothing on these formats.

Update:

It seems the .MSG format stores the body in Stream ID __substg1.0_10090102 - Which is encoded in some binary form (not sure what.) If I delete the stream (or set it to a single \0, the file becomes corrupt.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

萝莉病 2024-12-20 08:17:25

首先,要查找有关此主题和相关主题的更多信息,请远离原始子流编号并通过 google 查找相应的 MAPI 属性。例如,1013 是 PR_HTML,1009 是 PR_RTF_COMPRESSED。 MAPI 具有将正文从一种格式同步到另一种格式的方法。

请参阅 MSDN 上的这篇文章,了解所有与内容相关的 MAPI 的详细概述属性(即.MSG 文件内的不同“流”)。

要写入 PR_RTF_COMPRESSED,请将流包装在 WrapCompressedStream 内。另一方面,在您的特定情况下,您可能希望避免代码中的 MAPI 依赖性,因此您最好找到 PR_STORE_SUPPORT_MASK 并设置 STORE_UNCOMPRESSED_RTF少量。这将允许您在 PR_RTF_COMPRESSED 子流中使用直接 RTF。或者如果您有勇气的话,Outlooks 也可以使用 html-wrapped-in-rtf。

这些东西都不适合胆小的人,但是看到您已经如何处理原始 .MSG 子流写入,我猜这是可行的。

First of all, to find more information on this and related topics, move away from raw substream numbers and google for the corresponding MAPI properties. For example, 1013 is PR_HTML and 1009 is PR_RTF_COMPRESSED. MAPI has ways of synching the body from one format to the other.

See this article on MSDN for a good overview of all content-related MAPI properties (i.e. the different "streams" inside the .MSG file).

To write PR_RTF_COMPRESSED, wrap the stream inside WrapCompressedStream. On the other hand, in your particular situation you might want to avoid the MAPI-dependencies in your code, so maybe you're better off finding the PR_STORE_SUPPORT_MASK and setting the STORE_UNCOMPRESSED_RTF bit. This will allow you to use straight RTF in the PR_RTF_COMPRESSED substream. Or Outlooks fancy html-wrapped-in-rtf, if you are feeling brave.

None of this stuff is for the faint of heart, but seeing how you are already handing raw .MSG substream writing, I'm guessing it would be feasible.

孤独患者 2024-12-20 08:17:25

就格式而言,没有什么区别。
唯一的区别是 OFT 文件将 CLSID_TemplateMessage ({0006F046-0000-0000-C000-000000000046}) 作为存储类 (WriteClassStg) ,而 MSG 文件使用 CLSID_MailMessage (<代码>{00020D0B-0000-0000-C000-000000000046})

When it comes to the format, there is no difference.
the only difference is that OFT files have CLSID_TemplateMessage ({0006F046-0000-0000-C000-000000000046}) as the storage class (WriteClassStg), while MSG files use CLSID_MailMessage ({00020D0B-0000-0000-C000-000000000046})

给不了的爱 2024-12-20 08:17:25

在我搜索两种格式之间的差异时出现了此链接。

然而,通过测试收集到的对我有帮助的答案是,在 Outlook 中打开时,.oft 扩展名将自动插入已保存的默认电子邮件签名,而 .msg 格式则不会。

This link came up in my search for the difference between two formats.

The answer that helped me, however, gleaned through testing, is the .oft extension will automatically insert a saved default email signature and the .msg format does not, when opened in Outlook.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文