Outlook 2011-Client, Exchange 2010-Server; Buchstaben fehlen im Text der gesendeten Artikel


9

Auf einem Mac-Client mit Outlook 2011, der mit einem Exchange 2010-Server verbunden ist: Plötzlich werden Zeichen in ausgehenden E-Mail-Nachrichten gelöscht. Der Clientcomputer wurde neu gestartet und wiederholt sich immer noch bei jeder gesendeten Nachricht.

Hat jemand eine Idee, was dies verursachen würde? Fühlt sich an wie ein Rückfall in die BBS-Tage.

Testnachricht wie in Gesendete Objekte angezeigt und von Adressaten empfangen:

Geben Sie hier die Bildbeschreibung ein

Screenshot vor dem Klicken auf Senden:

Geben Sie hier die Bildbeschreibung ein


Erhalten Sie unterschiedliche Ergebnisse, wenn Sie eine Nur-Text-E-Mail senden?
MikeyB

1
Sie sind möglicherweise nicht allein - answers.microsoft.com/en-us/mac/forum/macoffice2011-macoutlook/… und möglicherweise hier: answers.microsoft.com/en-us/mac/forum/macoffice2011-macword/… Vielleicht ist es ein Schriftproblem auf dem Mac?
TheCleaner

1
Ich habe dieses Problem und es wird deutlich in meinem Exchange-E-Mail-Ordner angezeigt. Das Ändern meiner Schriftarten für HTML- und Text-E-Mails in "Lucida Console" ändert nichts am Verhalten.
Epu

1
Dies geschieht immer noch, wenn das Outlook 2011 SP2-Update angewendet wird.
Epu

2
Ja, ich verstehe das Gleiche. Fehlende Buchstaben. Nur-Text-E-Mails. Eine weitere Sache, die mir aufgefallen ist, ist, dass, wenn ich Text aus einer dieser E-Mails kopiere und einfüge und dann versuche, diesen eingefügten Text zu bearbeiten, beim Löschen von Zeichen wirklich seltsame Dinge passieren, z. B. wenn die Hälfte der Zeile über die andere Hälfte zur vorherigen Zeile verschoben wird. Wenn Sie den Entwurf schließen, die Schriftart in eine andere Standardschriftart wie Arial oder Calibri ändern und anschließend Outlook neu starten, wird das Problem normalerweise behoben. Nur ein weiteres wunderbares Microsoft-Produkt. Schade, dass ich Exchange für die Kontakte und das Kalendern mit dem Rest meines Unternehmens verwenden muss. Ich wünsche dort

Antworten:


1

Diese Frage ist alt, erscheint aber immer noch auf der ersten Seite von "unbeantwortet", daher wollte ich einige Punkte hinzufügen.

  • Es ist nicht klar, ob dies ein Problem mit dem Nachrichteninhalt oder dem Rendern ist
  • Um festzustellen, um welches Problem es sich handelt, klicken Sie in der Nachrichtenliste des Ordners mit der Befehlstaste auf die Nachricht und wählen Sie im Kontextmenü die Option "Quelle anzeigen".
    • Dadurch wird die im Textfeld gesendete E-Mail geöffnet, von wo aus Sie möglicherweise sehen können, ob der Inhalt korrekt ist.
    • Wenn Sie nicht feststellen können, ob nicht druckbare Zeichen vorhanden sind, speichern Sie eine Kopie der Nachrichtenquelle in einer Textdatei:
    • Wählen Sie "Datei"> "Duplizieren", wählen Sie "Datei"> "Speichern", geben Sie einen Namen ein, wählen Sie aus, wo Sie das Dokument speichern möchten, und klicken Sie dann auf "Speichern".
    • Führen Sie in einem Terminalfenster "od -tc my_mail_message.txt | less" aus.
    • Sie werden wahrscheinlich ein verwirrtes Durcheinander verschiedener Zeilenenden sehen, wobei sowohl 012 als auch 015 einzeln angezeigt werden.
  • Wenn es sich um ein Schriftproblem handelt, sollte dies durch Anzeigen im Klartext behoben werden. Wenn dies nicht der Fall ist, handelt es sich nicht um ein Schriftartenproblem. Dies kann jedoch bedeuten, dass das Zeichen in der Standardanzeige nicht gedruckt werden kann.

0

Ich habe dieses Problem kürzlich erlebt und dies war einer der wenigen verfügbaren Threads zu diesem Problem. Daher wollte ich meine Kommentare hinzufügen.

Ich habe auch diesen Artikel gefunden , der darauf hinweist, dass Outlook 2011 nicht gefällt, wenn E-Mails mit "Windows-1252" codiert werden.

Die E-Mail, mit der ich dieses Problem gesehen habe, wurde tatsächlich in Windows-1252 codiert. Was seltsam war, war, dass der E-Mail-Quelle auch die Buchstaben fehlten, obwohl die Vorschau in Ordnung war.

Nichts, was ich wirklich behoben habe, und meine einzige Empfehlung an den Benutzer war, Entourage zu verwenden, um auf diese Nachricht zu antworten und erneut zu wiederholen, dass es sich bei bestimmten E-Mail-Einstellungen nur um ein einmaliges Problem dieser bestimmten Verwendung handelt.

Sehr seltsam!


-3

hier einige einblicke:

Das manuelle Einstellen der Textcodierung auf UTF-8 (Format -> Textcodierung -> Unicode (UTF-8) "behebt" das Problem tatsächlich.

Aber: bis heute: In Outlook 2011 - Microsoft Answers kann die bevorzugte Codierung für ausgehende Nachrichten nicht festgelegt werden


Die Zeichencodierung von E-Mails ändert sich - Microsoft Answers Als Antwort auf den Beitrag von Robert P. am 8. Mai 2012 Hallo und vielen Dank für die Antwort,

Ich habe 3 Konten in Outlook eingerichtet (2 IPAM und 1 POP) und ich hatte nie Fehlermeldungen oder Schriftartenprobleme außer den folgenden:

Vor diesem Upgrade hatte (und habe) ich das bekannte Problem bezüglich des 7-Bit-Zeichensatzes, wenn die Formatcodierung auf AUTO eingestellt ist. Wenn Sie beispielsweise griechische oder andere Zeichen außerhalb des 7-Bit-Bereichs (russisch usw.) verwenden und diese mit der auf AUTO (Standard) eingestellten Codierung senden, wird nicht UTF-8 (oder griechische ISO), sondern eine andere Codierung verwendet (Windows-1254), was zu falschem Format und unlesbarem Inhalt führt. Sie müssen es jedes Mal, wenn Sie eine E-Mail senden (es gibt keinen permanenten Standardsatz), speziell auf UTF-8 einstellen oder eine schnelle Problemumgehung verwenden, um ein Zeichen (in der Signatur) außerhalb des 7-Bit-Zeichens (wie das Euro-Symbol) und dieses einzufügen So erzwingen Sie, dass die Codierung im AUTO-Format UTF-8 verwendet.

Das Obige ist während des Sendens und die Problemumgehung ist in Ordnung, aber das gleiche ist nach dem Upgrade aufgetreten, wenn Sie eine E-Mail erhalten und es keine Kontrolle gibt. so:


2
Hüte dich vor dem Jubjub-Vogel und meide den schäumenden Bandersnatch!
MikeyB
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.