FAQ
Question
Bonjour ! pour le code suivant :
Aspose.Email.Mime.ContentType ct = new Aspose.Email.Mime.ContentType();
ct.MediaType = "application/msword";
ct.CharSet = "ISO-2022-JP";
Attachment att = new Attachment("Test.doc", ct);
Console.WriteLine(att.ContentType.Name);
att.ContentType.Name renvoie le nom du document joint. Est‑ce un comportement attendu ?
Réponse : Oui, c’est un comportement attendu. Si ContentType.Name n’est pas défini explicitement, la valeur du nom de fichier sera prise comme nom.
Question :
Pourquoi ExchangeWebServiceClient.FetchMessage transforme-t-il les images intégrées en pièces jointes ?
Réponse : Microsoft Exchange Server possède une telle fonctionnalité que « Conversion de contenu, qui est le processus de formatage correct d’un message pour chaque destinataire. La décision d’effectuer une conversion de contenu sur un message dépend de la destination et du format du message traité.
En d’autres termes, pour les clients inconnus, le serveur peut formater le message selon les paramètres du serveur (pour sélectionner le format de message le plus approprié). Comme vous le comprenez, le format le plus universel pour tout client est « text/plain » et ces paramètres sont configurables sur le serveur.
Veuillez noter : Outlook est un client de messagerie bien connu pour Microsoft Exchange Server (dans le cas où MS Outlook possède une version plus ancienne que le serveur). Cela signifie que Exchange Server adapte le format du message aux capacités d’Outlook. Dans notre cas, lorsque ExchangeWebServiceClient tente de récupérer le message, les capacités de nos composants sont inconnues de MS Exchange. Le serveur transmet le message aux composants dans le format le plus simple (text/plain). En d’autres termes, il n’y a aucune partie HTML dans la réponse du serveur. Dans cette situation, les images sont incluses dans le message comme des pièces jointes.
Il existe une façon d’éviter le problème décrit. Si le message sur le serveur possède un en‑tête Content‑Type : multipart/alternative et que l’une de ses parties est text/plain, alors ce message est transmis au client tel quel. Les images sont alors affichées dans le corps du message car le message contient également une partie HTML. Dans le scénario actuel, le message est ajouté à MS Exchange à l’aide de MS Outlook et, en conséquence, le Content‑Type du message n’est pas « multipart/alternative ». En conséquence, nous rencontrons un problème lors de la récupération du message. Par exemple, voici des exemples de problèmes similaires : un (http://support.risualblogs.com/blog/2011/02/24/html-mails-sent-via-owa-and-outlook-2011-are-received-as-plain-text-mails-externally/), deux (http://forums.mozillazine.org/viewtopic.php?f=39&t=628678), trois (http://stackoverflow.com/questions/4681798/how-do-i-send-html-multipart-alternative-from-exchange-web-services-2010-sp1). En conclusion, la situation décrite dans le problème (images incluses dans le message en tant que pièces jointes) n’est pas un bug des composants Aspose. Il s’agit d’une fonctionnalité spécifique du serveur Exchange.
Question : Comment extraire les données de la pièce jointe "oleData.mso" que j’obtiens suite à la lecture d’un MapiMessage contenant un objet OLE intégré ?
Réponse : Les fichiers comme "oleData.mso" font référence au format Microsoft Compound Document (MCDF) et, malheureusement, la prise en charge de tels fichiers dépasse le champ d’action d’Aspose.Email. Cependant, il existe certaines bibliothèques .NET open source, par exemple OpenMCDF, qui peuvent être utilisées pour lire le contenu de ces fichiers afin de les enregistrer sur le disque.
Question : Pouvons‑nous écrire dans le même fichier PST avec des threads parallèles en utilisant les mêmes objets ?
Réponse : Non, la sécurité des threads n’est pas garantie dans ce cas. L’écriture des messages doit être effectuée dans un seul thread. Cependant, le produit doit fonctionner correctement avec différents objets provenant de différents threads.