Am Donnerstag, den 23.02.2017, 14:42 +0100 schrieb Dirk Paul Finkeldey: > Keine sorge ich möchte kein Faß aufmachen, es interessiert mich nur wie > es kommt das mitten in thread scheinbar die Zeichen Code Tabelle durch > einander gerät. > > Als Beispiel : > > Nachrichten-Id<[🔎] 6935c65a5b6676d4b0d1776371a58f8d@localhost> > > Hier werden die Schriftzeichen korrekt dargestellt > > Nachrichten-Id<[🔎] 20170223084904.GA7771@cq58.hosts.tdnet.eu> > > Hier sind die Schriftzeichen nicht mehr in Ordnung, in den Header sind > keine Informationen zur Text Kodierung. > > Icedove habe ich so eingestellt das automatische Erkennung der Text > Kodierung ignoriert und immer UTF-8 verwendet werden soll. Keine Ahnung was man damit abstellt. Es könnte sein, daß die automatische Erkennung nur dann anspringt, wenn kein 'charset' angegeben ist. Es kann aber auch sein, daß damit 'charset' völlig ignoriert wird und immer UTF-8 verwendet wird. > Nachrichten-Id<[🔎] 1877825.80s6DNda61@merkaba> > <[🔎] 20170223102441.GC4980@leo.home.cknoke.de> > <[🔎] 176a9eea537f675375e535c1209fb8f7@localhost> > > Hier sind die Schriftzeichen auch OK > > Nachrichten-Id<[🔎] 2227961.BxQdKxxXl7@merkaba> > > Hier sind die Schriftzeichen wieder durcheinander, hier verstehe ich > nicht weshalb in einer vorherigen Mail die von der selben Domain > verschickt wurde alles OK war. > > Ich glaube nicht das es daran liegt das iso-8859-1 Kodierung verwendet > wurde, in der nächsten Antwort wird windows-1252 Kodierung verwendet und > die Schriftzeichen stimmen wieder. > > Wer kann mir da ein wenig technische Erleuchtung geben? Bei mir sehen alle Emails korrekt aus. Nur in den Emails von Dir, sobald Umlaute verwendet werden, wird das Unicode-Zeichen 0xFFFD (Replacement Character) eingesetzt. Das Ersatz-Zeichen wird also nicht deshalb angezeigt weil die Codierung nicht verstanden wird, sondern weil dein Emailclient es tatsächlich so geschrieben hat. In diesem Sinne sind auch deine Emails korrekt codiert. Warum dein Emailclient alle Zeichen höher 0x007F mit 0xFFFD ersetzt ist hier die Frage. > Ich möchte ausschließen das der Fehler mit der Kodierung auf meiner > Seite erfolgt. Es liegt aber leider an deinem Emailclient. Der Fehler tritt auf, sobald du auf eine Email antwortest, die nicht UTF-8 codiert ist. Zum Beispiel die Email von Christian Schmidt am 21 Feb 2017 um 10:56:09 +0100 wird bei mir korrekt angezeigt unt enthält die Informationen: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Deine Antwort darauf am 21 Feb 2017 um 13:13:19 +0100 enthält bereits (korrekt codierte) Ersatz-Zeichen und hat folgende Informationen: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Frage: wird die Email von Christian Schmidt am 21 Feb 2017 um 10:56:09 +0100 in deinem Emailclient korrekt angezeigt? Wenn ja, dann klicke mal auf 'Antworten' und schau ob auch der zitierte Text korrekt angezeigt wird. Wenn ja, dann vermurkts dein Emailclient die Nachricht erst beim verschicken. Wenn nein, dann dürfte es an der deaktivierten automatischen Erkennung liegen. Er versucht dann einfach alles als UTF-( zu lesen und was nicht passt wird durch ein Ersatz-Zeichen ersetzt. Du könntest auch probieren die automatische Erkennung wieder einzuschalten und auf eine Email, die nicht UTF-8 codiert ist, zu antworten. Eventuell liegt es ja daran. Wenn dem so ist, wäre die Benennung 'automatische Erkennung deaktivieren' falsch und müsste 'Zeichencodierung ignorieren' heißen. -- mfG Sascha GPG key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x92BBDD596C5FDC0F GPG fingerprint: 5A68 F665 44E6 0E50 001C 75A6 92BB DD59 6C5F DC0F Die Tochter sitzt im Zimmer und versucht ein Kreuzworträtsel zu lösen. Plötzlich stockt sie und fragt den Vater: "Vati, Lebensende mit drei Buchstaben?" Vater: "Ehe".
Attachment:
signature.asc
Description: This is a digitally signed message part