=E2=80=9E umwandeln

[josefkoller]

Hallo,

ich hole mir für meine Probiererei Mails von meinem Mailserver.

Ich hab jetzt besagte Mail mal in meinem Thunderbird gesucht.

Das Blöde ist, daß dort auch besagte Fragezeichen gefunden und interpretiert werden.
Die Thunderbird Leute müssen also irgendeine Funktionen benutzen, die sowas findet.

Der Quelltext kommt bei beiden (also bei meinem pop3 und in Thunderbird) gleich an.

In Thunderbird Quelltext6 steht z. B. =D6 für "Ö", bei mir auch.

Bei Thunderbird kommt dann in der Ansicht ein "Ö" raus, bei mir ein "?".

Die bei Thunderbird bekommen es hin und ich nicht. Das ärgert mich.

Vielleicht doch noch eine Idee??

Danke

Josef

Und noch was:
Der Sender ist ein MacRechner. Das Sonderzeichen dieser Mail für "ä" lautet: =E4. In den anderen Quelltexten steht für ä, =C3=A4.

[himitsu]

Ein einzelnes =D6 ist nunmal kein gültiges UTF-8-Zeichen

Hat der Thunderbird da eventuell eine andere Codierung angegeben?
#$D6 bzw. #214 ist das Ö in den meisten deutschen ANSI-Kodierungen.

[Namenloser]

Mit sowas hatte ich auch schon mal zu kämpfen, allerdings in PHP. Es scheint bei Mails leider häufiger vorzukommen, dass sie falsch enkodiert sind, als umgekehrt. Es bleibt einem kaum etwas anderes übrig, als mit Heuristiken zu arbeiten (bzw. entsprechende Bibliotheken zu verwenden).

[josefkoller]

Hallo,

bei meinem aktuellen Problem hab ich es jetzt so gemacht:

Delphi-Quellcode:

...
pop.RetrStream(i, retrStream);
      retrStream.Position := 0;
      mess.Lines.LoadFromStream(retrStream);
      mess.Lines.Text:=replaceUmlaute(mess.Lines.Text);
      mess.Lines.Text:=DecodeQuotedPrintable(mess.Lines.Text);
...

Delphi-Quellcode:

function replaceUmlaute(Text: string): string;
begin
  Text := StringReplace(Text, '=F6', 'ö', [rfReplaceAll]);
  Text := StringReplace(Text, '=D6', 'Ö', [rfReplaceAll]);
  Text := StringReplace(Text, '=FC', 'ü', [rfReplaceAll]);
  Text := StringReplace(Text, '=DF', 'ß', [rfReplaceAll]);
  Text := StringReplace(Text, '=E4', 'ä', [rfReplaceAll]);
  Text := StringReplace(Text, '=C4', 'Ä', [rfReplaceAll]);
  Text := StringReplace(Text, '=DC', 'Ü', [rfReplaceAll]);
  Result := Text;
end;

Also erst wird nach diesen "falschen" =D6 gesucht und ersetzt (mit function replaceUmlaute)und dann mit function DecodeQuotedPrintable aus synacode.pas die "richtigen" HEX Werte, also die =C3=B6, usw. umgewandelt.

diese Reihenfolge ist notwendig, sonst klappt es wieder nicht!


Dann schaut es gut aus. Ich werd mal noch ein paar andere Mails damit laden. Wahrscheinlich tauchen noch andere Werte auf. Die müßte ich dann halt auch noch in meine funktion reinschreiben. Oder vielleicht gleich die ganze Zeichensatztabelle??

Nur ...welche? Was ist denn das für ein Zeichensatz, der =F6,=D6, usw. definiert???

Danke.

Josef

P.S.
Ein weiteres Problem sind Mails, die mit der PHP Mail funktion verschickt werden.
Bei php mail() reicht es, ein from und ein to anzugeben.

Du findest dann kein Date oder keine Message-ID im Kopf usw. Auch kann "Message-Id" oder "Message-ID" im Header geschrieben werden, um die Werte zu definieren. usw.

Mit anderen Worten:
Ich habe es mir viel einfacher vorgestellt,meinen eigenen pop client zu machen.

In einem anderen Post hab ich gefragt, wie ich ein Datum in Form von "Mon, 3 Feb 2014 02:57:08 +0100 (CET)" im Headertext finden kann (also kein Date: davor).

Bisher keine Antworten. Ich weiß es auch nicht.

vielleicht dazu eine Idee???

[Namenloser]

Zitat von josefkoller:

Nur ...welche? Was ist denn das für ein Zeichensatz, der =F6,=D6, usw. definiert???

Gar keiner. Es ist nur eine Schreibweise, um Byte-Werte zu kodieren. Wie diese Bytewerte zu interpretieren sind, ob als ANSI, als UTF-8 usw., darüber kann man ohne weitere Informationen keine Aussage machen.

Theoretisch müsste im Header der E-Mail das korrekte Encoding angegeben sein, darauf kann man sich aber nur bedingt verlassen.

[p80286]

Zitat von josefkoller:

Also erst wird nach diesen "falschen" =D6 gesucht und ersetzt (mit function replaceUmlaute)und dann mit function DecodeQuotedPrintable aus synacode.pas die "richtigen" HEX Werte, also die =C3=B6, usw. umgewandelt.

diese Reihenfolge ist notwendig, sonst klappt es wieder nicht!

Bist Du Dir da ganz sicher?
Eigentlich sollte erst die Dekodierung der 3Byte und 2Byte Sequenzen erfolgen und dann zum Schluß der Rest der übrig bleibt. Bei Deiner Vorgehensweise kann es sein, daß in einer Sequenz die mehrere Bytes enthält eine Falschinformation eingefügt wird.

Zitat:

Es ist nur eine Schreibweise, um Byte-Werte zu kodieren. Wie diese Bytewerte zu interpretieren sind, ob als ANSI, als UTF-8 usw., darüber kann man ohne weitere Informationen keine Aussage machen.

Gruß
K-H

[Mikkey]

Zitat von Namenloser:

Zitat von josefkoller:

Nur ...welche? Was ist denn das für ein Zeichensatz, der =F6,=D6, usw. definiert???

Gar keiner. Es ist nur eine Schreibweise, um Byte-Werte zu kodieren. Wie diese Bytewerte zu interpretieren sind, ob als ANSI, als UTF-8 usw., darüber kann man ohne weitere Informationen keine Aussage machen.

Theoretisch müsste im Header der E-Mail das korrekte Encoding angegeben sein, darauf kann man sich aber nur bedingt verlassen.

Es ist DOS-Westeuropäisch, AFAIR Codepage 451

[josefkoller]

[QUOTE=Es ist DOS-Westeuropäisch, AFAIR Codepage 451[/QUOTE]

Dank für den Hinweis. DOS-Westeuropäisch ist 850. die ist es aber auch nicht.
Dafür hab ich DOS-mitteleuropäisch 852 gefunden. die scheint zu passen.

Die kann auch mit den synapse funktionen angewandt werden.

Nur, im Ergebnis haben dann die anderen Mails wieder fehlerhafte Zeichen drin.

Das Einzige was bisher hilft, ist mein eigenes String Replace.

Ich schreib da jetzt mal noch einige Zeichen aus der CP 852 rein und dann muß es passen.

Danke für die Hinweise und für die Geduld.

Josef