Client Outlook 2011, serveur Exchange 2010; lettres manquantes dans le texte des articles envoyés

Sur un client Mac exécutant Outlook 2011 connecté à un serveur Exchange 2010: tout à coup, des caractères sont supprimés dans les messages électroniques sortants. La machine client a été redémarrée et cela se reproduit toujours avec chaque message envoyé.

Quelqu'un at-il une idée de ce qui pourrait provoquer cela? Se sent comme un retour aux jours BBS.

Message de test tel qu'il apparaît dans Éléments envoyés et tel que reçu par les destinataires:

Capture d'écran prise avant de cliquer sur Envoyer:

Cette question est ancienne, mais apparaît toujours sur la première page de "sans réponse", donc je voulais ajouter quelques points.

• il n'est pas clair s'il s'agit d'un problème avec le contenu ou le rendu des messages
• Pour déterminer quel est le problème, dans la liste des messages du dossier, cliquez sur le message avec la commande et sélectionnez «Afficher la source» dans le menu contextuel.
  • Cela ouvrira l'e-mail tel qu'il a été envoyé dans le bloc de texte, d'où vous pourrez voir si le contenu est correct.
  • Si vous ne pouvez pas savoir si des caractères non imprimables sont présents, enregistrez une copie de la source du message dans un fichier texte:
  • Choisissez Fichier> Dupliquer, choisissez Fichier> Enregistrer, saisissez un nom, choisissez où vous souhaitez enregistrer le document, puis cliquez sur Enregistrer.
  • Dans une fenêtre de terminal, exécutez "od -tc my_mail_message.txt | less"
  • vous verrez probablement un désordre confus de différentes fins de ligne, avec les deux 012 et 015 apparaissant individuellement.
• s'il s'agit d'un problème de police, l'affichage en texte brut devrait résoudre ce problème. Si ce n'est pas le cas, ce n'est pas un problème de police, bien que cela puisse signifier que le caractère n'est pas imprimable dans la police d'affichage par défaut.

J'ai récemment rencontré ce problème et c'était l'un des seuls sujets disponibles sur le problème, je voulais donc ajouter mes commentaires.

J'ai également trouvé cet article , qui laisse entendre qu'Outlook 2011 n'aime pas lorsque les e-mails sont codés avec "Windows-1252".

L'e-mail avec lequel j'ai vu ce problème était en fait codé dans Windows-1252. Ce qui était étrange, c'est que la source de courrier électronique manquait également les lettres, même si l'aperçu était correct.

Rien de ce que j'ai fait ne l'a vraiment corrigé, et ma seule recommandation à l'utilisateur était d'utiliser Entourage pour répondre à ce message et réitérer qu'il ne s'agit que d'un problème ponctuel de cette utilisation particulière avec certains paramètres de messagerie.

Très étrange cependant!

voici quelques aperçus:

La définition manuelle de l'encodage de texte sur UTF-8 (Format -> Encodage de texte -> Unicode (UTF-8) "corrige" en effet le problème.

Mais jusqu'à aujourd'hui: impossible de définir le codage préféré pour les messages sortants dans Outlook 2011 - Microsoft Answers

Le codage de caractères des e-mails change - Microsoft Answers En réponse au message de Robert P. du 8 mai 2012 Bonjour et merci pour la réponse,

J'ai 3 comptes définis dans Outlook (2 IPAM et 1 POP) et je n'ai jamais eu de messages d'erreur ou de problèmes de police en dehors des éléments suivants:

Avant cette mise à niveau, j'avais (et j'ai toujours) le problème connu concernant le jeu de caractères 7 bits lorsque l'encodage du format est réglé sur AUTO. Par exemple, si vous utilisez du grec ou d'autres caractères en dehors du 7 bits (russe, etc.) et que vous l'envoyez avec l'encodage défini sur AUTO (par défaut), il n'utilisera pas UTF-8 (ou ISO grec) mais un autre encodage (windows-1254), ce qui entraîne un format incorrect et un contenu illisible. Vous devez le définir spécifiquement sur UTF-8 à chaque fois que vous envoyez un e-mail (il n'y a pas de jeu permanent par défaut) ou utiliser une solution rapide pour inclure un caractère (dans la signature) en dehors du 7 bits (comme le symbole de l'euro) et ce comme vous forcez le codage au format AUTO à utiliser UTF-8.

Ce qui précède est lors de l'envoi et la solution de contournement est correcte, mais la même chose est apparue après la mise à niveau lorsque vous recevez un e-mail et il n'y a aucun contrôle. donc: