Używam EWS Java 1.2, chociaż 2.0 w C # pokazuje dokładnie te same problemy, a Exchange 2010 SP3, więc szczególny błąd w SP2 przed pakietem 3 dotyczący treści wiadomości nie stanowi problemu.

Krótko mówiąc: EWS + wymiana = ból. Używając EWS w Exchange, możesz utworzyć Spotkanie. Możesz określić, że treść wiadomości w Spotkaniu będzie HTML i dać mu kilka HTML, aby przejść z nią. Spowoduje to konwersję HTML -> RTF, która niszczy kod HTML podczas przeglądania go na pulpicie programu Outlook lub kliencie WWW. Dobrze, możemy dostosować HTML do czegoś, co nie zostanie zjedzone w procesie i nadal wygląda przyzwoicie.

Z wyjątkiem tego, że podczas aktualizacji Spotkania ze zmianą treści wiadomości NAPRAWDĘ zjada formatowanie HTML. Nie ma znaczenia, czy jest to ten sam kod HTML, który podałeś podczas tworzenia. Drugi zapis zniszczy go, pozostawiając niewiele więcej niż pogrubiony tekst, podziały wierszy i karty. To tak, jakby wyświetlał zwykły tekst z kilkoma małymi fragmentami formatowania lub wyświetlał bardzo uproszczony RTF z przekonwertowanego HTML. Naprawdę denerwujące jest to, że dzieje się to dopiero po zaktualizowaniu ciała.

Rzecz w tym, że przyjrzałem się tym spotkaniom (i powiązanym wymaganiom MeetingRequest, które są podzielone w ten sam sposób) zarówno w MFCMAPI, jak iw EWS, sprawdzając rozszerzone właściwości. Po pierwszym utworzeniu spotkania wypełniane jest tylko ciało RTF. Ciała zwykłego tekstu i HTML są zerowe, RTF jest zsynchronizowany, a wartość natywna to 2, co oznacza, że ​​powinien wyświetlać RTF. Ok, to ma sens.

Po aktualizacji wszystkie trzy typy treści są obecne. RTF jest niezsynchronizowany. Wartość natywnego obiektu wynosi 3, co oznacza, że ​​powinien wyświetlać HTML. Sprawdziłem w MFCMAPI. Zarówno treść zwykłego tekstu, jak i treść RTF pokazują błędy pamięci, ale otwarcie właściwości spowoduje jej prawidłowe wyświetlenie. Treść HTML jest obecna. ZERO istnieje powód, aby tak się działo zgodnie z dokumentacją. Algorytm Best Body stwierdza, że ​​jeśli właściwość rodzimego ciała jest wypełniona, to jest to, co zostanie użyte i wszystko zostanie wykonane. Cóż, to oczywiście się nie dzieje. Jeśli z jakiegoś powodu nie otrzyma tej wartości, przejdzie przez łańcuch warunkowy. Cóż, łańcuch warunkowy pokazuje, że w tym przypadku powinno być wyświetlane ciało HTML. MFCMAPI zgadza się, gdy element jest eksportowany, ponieważ pokazuje ciało macierzyste jako ciało HTML. OWA wyświetli to dobrze. Ale Outlook 2010/2013? Nie.

Jestem tu po mojej stronie. Nie mogę uzyskać programu Outlook Outlook do prawidłowego wyświetlania treści bez względu na to, co robię. Wydaje się, że jest to coś zasadniczo zepsutego, ale nie ma na nim żadnych znanych błędów (poza wspomnianym wcześniej problemem SP2 poprzedzającym zestawienie 3, co nie ma tu miejsca) i nie mogę znaleźć żadnej dokumentacji, która wyjaśniałaby, dlaczego aktualizacja go przerwała źle. Najlepsze, co mogłem zrobić, to ustawić pidTagBodyHtml bezpośrednio podczas tworzenia i od początku go łamać. Przynajmniej to jest spójne.

EDYCJA: Zaimplementowałem algorytm dekompresji RTF, aby zajrzeć do środka. Rzecz jasna treść wiadomości RTF dla nowego spotkania i treść wiadomości RTF dla zaktualizowanego spotkania (w którym ciało zostało zaktualizowane z praktycznie identycznym) są bardzo różne! Exchange podąża za dwoma oddzielnymi serwerami ścieżek kodu i łamie format treści! Jedynym możliwym rozwiązaniem, które widzę, jest również zaimplementowanie algorytmów kompresji i formatowania oraz ręczne skonstruowanie prawidłowego ciała RTF w kliencie, co nie jest do końca małym wyczynem.