Я использую EWS Java 1.2, хотя версия 2.0 на C# показывает те же самые проблемы, что и Exchange 2010 SP3, поэтому конкретная ошибка в пакете обновления 2 до свертки 3, касающаяся тел сообщений, не является проблемой.
Короче говоря: EWS + Exchange = боль. Используя EWS в Exchange, вы можете создать встречу. Вы можете указать, что тело сообщения о встрече должно быть HTML, и добавить к нему кучу HTML. Это приведет к некоторому преобразованию HTML -> RTF, которое разрушит HTML, когда вы просматриваете его на рабочем столе Outlook или в веб-клиенте. Хорошо, мы можем адаптировать HTML к чему-то, что не съедается в процессе и все еще выглядит прилично.
За исключением того, что когда вы обновляете встречу с изменением тела сообщения, оно ДЕЙСТВИТЕЛЬНО съедает форматирование HTML. Неважно, тот ли это HTML-код, который вы дали ему при создании. Второе сохранение уничтожит его, оставив лишь полужирный текст, разрывы строк и табуляции. Это как если бы он отображал либо обычный текст с несколькими небольшими фрагментами форматирования, либо отображал бы очень урезанный RTF из преобразованного HTML. Что действительно бесит, так это то, что это происходит только после обновления тела.
Дело в том, что я просмотрел эти встречи (и связанные с ними запросы на встречи, которые мульчируются одинаково) как в MFCMAPI, так и в EWS, проверив расширенные свойства. Когда назначение создается впервые, заполняется только тело RTF. Простой текст и тело HTML пусты, RTF синхронизирован, а собственное значение тела равно 2, что означает, что он должен отображать RTF. Хорошо, это имеет смысл.
При обновлении присутствуют все три типа кузова. RTF не синхронизирован. Собственное значение body равно 3, что означает, что он должен отображать HTML. Я проверил в MFCMAPI. Как текстовое тело, так и тело RTF показывают ошибки нехватки памяти, но открытие свойства покажет это правильно. Тело HTML присутствует. В соответствии с документацией нет НУЛЕВОЙ причины, по которой это должно происходить. Алгоритм Best Body утверждает, что если свойство собственного тела заполнено, то это то, что будет использоваться, и все готово. Ну, этого явно не происходит. Если по какой-то причине он не получает это значение, он будет проходить через условную цепочку. Что ж, условная цепочка показывает, что в этом случае должно отображаться тело HTML. MFCMAPI соглашается, когда элемент экспортируется, поскольку он показывает, что собственное тело является телом HTML. OWA отобразит это просто отлично. А Outlook 2010/2013? Неа.
Я в своем уме здесь. Я не могу заставить Outlook для рабочего стола правильно отображать тело, что бы я ни делал. Похоже, что это что-то принципиально сломанное на стороне сервера, но в списке нет известных ошибок (кроме вышеупомянутой проблемы с пакетом обновления 3 до обновления 3, которая здесь не имеет место), и я не могу найти документацию, объясняющую, почему обновление так ломает его. плохо. Лучшее, что мне удалось сделать, это установить pidTagBodyHtml непосредственно при создании и с самого начала сломать его. По крайней мере, это последовательно.
РЕДАКТИРОВАТЬ: я реализовал алгоритм декомпрессии RTF, чтобы заглянуть внутрь. Конечно же, тело сообщения RTF для новой встречи и тело сообщения RTF для обновленной встречи (в котором тело было обновлено практически идентичным) сильно различаются! Exchange следует двум отдельным путям кода на стороне сервера и нарушает формат тела! Единственное возможное решение, которое я вижу, состоит в том, чтобы также реализовать алгоритмы сжатия и форматирования и вручную создать действительное тело RTF в клиенте, что не так уж и мало.
