我正在使用EWS Java 1.2，尽管C＃中的2.0显示完全相同的问题，而Exchange 2010 SP3，因此在汇总3之前的SP2中有关邮件正文的特定错误不是问题。
长话短说：EWS + Exchange =痛苦。在Exchange中使用EWS，您可以创建约会。您可以指定约会的消息正文是HTML，并为其提供一堆HTML。这将做某种HTML - ＆gt;在Outlook桌面或Web客户端中查看HTML时，会破坏HTML的RTF转换。好吧，我们可以将HTML定制为在过程中没有被吃掉但仍然看起来不错的东西。
除非您通过对邮件正文进行更改来更新约会时，它才会真正使用HTML格式。如果它与您在创建时提供的HTML相同并不重要。第二次保存会破坏它，只留下粗体文本，换行符和制表符。就好像它是显示纯文本的几个小块格式，或者它是从转换后的HTML中显示一个非常精简的RTF。真正令人抓狂的是它只会在你更新身体后才会发生。
问题是，我通过检查扩展属性，在MFCMAPI和EWS中查看了这些约会（和相关的MeetingRequests，它们以相同的方式覆盖）。首次创建约会时，仅填充RTF正文。纯文本和HTML正文为空，RTF同步，本机正文值为2，这意味着它应显示RTF。好的，这是有道理的。
在更新时，所有三种体型都存在。 RTF不同步。本机正文值为3，这意味着它应该显示HTML。我签了MFCMAPI。纯文本正文和RTF正文都显示内存不足错误，但打开属性会正确显示。 HTML正文存在。根据文档，这应该发生，这是零的原因。最佳主体算法指出，如果填充了本机主体属性，那么将使用它并且全部完成。嗯，这显然没有发生。如果它由于某种原因没有获得该值，那么它将通过条件链。好吧，条件链表明在这种情况下应该显示HTML正文。 MFCMAPI同意导出的项目，因为它显示本机主体是HTML正文。 OWA会很好地展示它。但Outlook 2010/2013？不。
我在这里结束了我的智慧。无论我做什么，我都无法让桌面Outlook正确显示身体。它似乎是从根本上破坏了服务器端的东西，但没有列出已知的错误（除了前面提到的SP2预卷3问题，这不是这里的情况），我找不到任何解释为什么更新打破它的文档厉害。我能做的最好的事情就是直接在创建时设置pidTagBodyHtml，并从一开始就将它打破。至少那是一致的。
编辑：我已经实现了RTF解压缩算法来查看内部。果然，用于新约会的RTF消息正文和用于更新约会的RTF消息正文（其中正文更新为几乎相同的约会）是非常不同的！ Exchange遵循两个单独的代码路径服务器端，它打破了正文格式！我看到唯一可行的解决方案是实现压缩和格式化算法，并在客户端中手动构建一个有效的RTF主体，这不是一个小小的壮举。