Я использую EWS Java 1.2, хотя 2.0 в C # показывает те же проблемы, что и Exchange 2010 с пакетом обновления 3 (SP3), поэтому конкретная ошибка в пакете обновления 2 до накопительного пакета 3, касающаяся тел сообщений, не является проблемой

Короче говоря: EWS + Exchange = боль. Используя EWS в Exchange, вы можете создать встречу. Вы можете указать, что тело сообщения Встречи должно быть HTML, и дать ему набор HTML, чтобы идти с ним. Это выполнит какое-то преобразование HTML -> RTF, которое разрушит HTML при просмотре его на рабочем столе Outlook или в веб-клиенте. Хорошо, мы можем адаптировать HTML к чему-то, что не съедается в процессе и все еще выглядит прилично.

За исключением того, что когда вы обновляете Встречу с изменением тела сообщения, оно ДЕЙСТВИТЕЛЬНО съедает форматирование HTML. Неважно, тот ли это HTML-код, который вы дали при создании. Второе сохранение уничтожит его, оставив чуть больше, чем жирный текст, разрывы строк и вкладки. Это как если бы он либо отображал простой текст с несколькими небольшими фрагментами форматирования, либо отображал очень урезанный RTF из преобразованного HTML. Что на самом деле сводит с ума, так это то, что это происходит только после обновления тела.

Дело в том, что я посмотрел на эти Встречи (и связанные с ними MeetingRequests, которые обрабатываются одинаково) как в MFCMAPI, так и в EWS, проверив расширенные свойства. Когда Встреча создается впервые, заполняется только тело RTF. Обычный текст и HTML-тела имеют нулевое значение, RTF синхронизирован, а значение собственного тела равно 2, что означает, что он должен отображать RTF. Хорошо, это имеет смысл.

При обновлении присутствуют все три типа телосложения. RTF не синхронизирован. Собственное значение тела равно 3, что означает, что он должен отображать HTML. Я проверил в MFCMAPI. Как текстовое тело, так и текст RTF показывают ошибки памяти, но открытие свойства покажет его правильно. Тело HTML присутствует. Существует нулевая причина, по которой это должно происходить в соответствии с документацией. Алгоритм Best Body гласит, что если заполнено свойство native body, то именно это и будет использовано, и все будет сделано. Ну, этого явно не происходит. Если он по какой-то причине не получает это значение, он будет проходить через условную цепочку. Что ж, условная цепочка показывает, что тело HTML должно отображаться в этом случае. MFCMAPI соглашается, когда элемент экспортируется, так как показывает, что собственное тело является телом HTML. OWA покажет это просто отлично. Но Outlook 2010/2013? Нет.

Я в конце моего остроумия здесь. Я не могу заставить рабочий стол Outlook правильно отображать тело независимо от того, что я делаю. Похоже, что это что-то принципиально сломанное на стороне сервера, но в списке нет известных ошибок (кроме вышеупомянутой проблемы с предварительным выпуском пакета обновления 3 (SP2), которая здесь не так), и я не могу найти какую-либо документацию, объясняющую, почему обновление так ломает ее плохо. Лучшее, что я смог сделать, - это установить pidTagBodyHtml непосредственно при создании и разбить его с самого начала. По крайней мере, это соответствует.

РЕДАКТИРОВАТЬ: я реализовал алгоритм декомпрессии RTF, чтобы заглянуть внутрь. Конечно же, тело сообщения RTF для новой встречи и тело сообщения RTF для обновленной встречи (в которой тело было обновлено практически идентичным) очень разные! Exchange следует двум отдельным путям кода на стороне сервера и нарушает формат тела! Единственное возможное решение, которое я вижу, - это также реализовать алгоритмы сжатия и форматирования и вручную создать действительное тело RTF в клиенте, что не является маленьким подвигом.