Inoffizielles deutsches Xbase-Forum

Guten Tag

Habe neue Version von Alaska installiert 1354.

Versand mit Eamil gehe ich den Weg von Alaska

Nun habe ich beim empfang der Emails keine Umlaute mehr.

Dies nur in der Message

=E9=E0=A3=E8=21=F6=E4=24=FC=A8
test
=DC=A8=D6=C4=24=C8=21=C9=C0=A3

Alaska hat da mit MimeMessage():setCharset() was hinzugefügt.

Kann mir da jemand helfen, bevor ich wieder zurück auf die Version 1334 gehe.

Schöne Grüsse
Thomas

Hallo Thomas

du erschreckst mich, ich sende Mails auf die selbe Art.

Hast du weitere Infos in welchem Umfeld das Problem auftritt?

Ich habe als erste Zeilen in der HTML Message des Mails die Zeilen Ich vermute dass nun offensichtlich noch UTF-8 eingesetzt/verwendet wird.

Die obige Message kommt beim Empfäger nun so an: ist aber beim Empfänger korrekt lesbar.

Hallo Carlo

Was zu sagen ist, ich sende nur Text.

So habe ich eingestellt

oMimeMsg:addHeader( "Content-Type", "text/plain; charset=ISO-8859-1" )
oMimeMsg:setMessage( ToQP(cMessage) )

Wie kann ich das auslesen, was ankommt.

Wenn ich die asinet10.dll vom version 1334 tausche, geht dies ohne Probleme.

Gruss
Thomas

Hallo Thomas

du hast recht bei Textmails ist es komisch. Habe das Problem damit auch.

Was ankommt siehst du wenn du dir ein Mail selbst zustellst und dann z.B. auf dem Mailclient die Datei ansiehst.

Hallo,
hatte das Problem auch bei dem Empfang von eMails.
Nachdem ich bei HTML-Mails die Konvertierung mit char2utf8( cHTML )
eingesetzt habe, war es gut.
Werner

Hallo Werner

Ja leider sende ich nur in Text

Gruss
Thomas

Stimmt,
den Versand meiner Mails hatte ich noch nicht getestet.
Stelle jetzt fest, dass meine gesendete Textmail auch nicht gut mit outlook lesebar ist (die Umlaute sind nicht korrekt).

Hallo Thomas

Zuerst Danke für dein Beitrag. Dank dem bin ich da wo ich die neue Version übers WE installiert habe nicht in den "Hammer" gelaufen sondern konnte noch eingreifen bevor allzuviele Missgebildete "Nur Text" Mails rausgingen.

Es ist schon krass dass so eine änderung im Verhalten des SMTP-Clients ohne Hinweis oder Vorwarnung mit einem Update kommt.

Ich bin zurück zur Vorgehenden Version. Weil der Fehler schlägt auch auf der "Betreff" Zeile zu und einfach die Daten als UTF8 übergeben macht kein Sinn bevor Alaksa zu dem Problem Stellung nimmt.

Jemand der dazu Zeit hat sollte es Alaska melden.

Habe ich bereits gemeldet

Nur ist der Support in den Ferien bis 11 Januar.


Carlo, wenn du die asinet10.dll von alter Version nimmst, geht alles,
auch wenn du mit neuer Version kompilierst.
Das hat zu tun mit setCharset. Dies ist in der alten asinet10.dll nicht vorhanden

Schöne Grüsse
Thomas

Hallo Carlo

Das kam vom Support

1) Das Rufen der Methode :setTransferEncoding() ist nicht notwendig
2) Das Rufen der Methode :setHeader() ist nicht notwendig
3) Das Rufen von Bin2QP() ist nicht mehr notwendig.

Dein Code beschränkt sich also nur auf:

////////////////////////////////////////////////////////////////////////
oMimeMsg:setMessage( cMessage )
////////////////////////////////////////////////////////////////////////

Probiere dies mal, jetzt geht dies bei mir mit den Umlauten.

Schöne Grüsse
Thomas

Achtung das geht doch noch nicht.

Habe dies nochmals Alaska gesendet

Gruss
Thomas

Hallo Thomas

für meine "nur Text" verwende ich nur

oMimeMsg:setMessage( cMessage )

beim versenden sind dann beim Empfänger nicht nur die Umlaute der Message missgebildet sondern auch die Betreff Zeile.
Es geht also wirklich seit dem Update nicht mehr.

DLL's verschieder Runtime Versionen zu mischen ist nicht so mein Ding.
Auch wenn es scheinbar funktioniert möchte ich dies so nicht bei einem Kunden installieren.

Hallo Carlo

Ja mache ich auch nicht.

Vielleicht höre ich nochmals was von Alaska.
Ansonsten zurück auf alte Version.

Gruss
Thomas

Muecke hat geschrieben: ↑Mo, 21. Dez 2020 16:08 Ansonsten zurück auf alte Version.

Das ist für den Entwickler und dessen Kunden der einzige Weg mit dem geringsten Frustpotential .....

So jetzt geht es mit Text
Alaska Support hat mir dies geschrieben.

oMimeMsg:setCharset( "utf-8" )
oMimeMsg:setMessage( cMessage )

So kommen die Umlaute bei mir richtig.

Schöne Grüsse
Thomas

Thomas,

Danke für die Mitteilung. Hab das gleich bei mir eingebaut.

Jan

Jan
nicht nur einbauen, auch schnell testen.

Gruss
Thomas

Thmas,

das gehört ja zum Einbauen zwangsläufig dazu.

Jan

Muecke hat geschrieben: ↑Di, 22. Dez 2020 10:14 So jetzt geht es mit Text
Alaska Support hat mir dies geschrieben.

oMimeMsg:setCharset( "utf-8" )
oMimeMsg:setMessage( cMessage )

So kommen die Umlaute bei mir richtig.

Schöne Grüsse
Thomas

nur zur Sicherheit, die cMessage kann OEM oder ANSI Text sein und du hast die nicht selbst nach UTF-8 umgewandelt ?

Dann wäre das ja eine echte Erleichterung.

Hallo Thomas

Danke für deine Bemühung und die Infos.

Getestet mit OEM Files und OEM Subject ohne Umwandlung ist es so mit setCharset () einwandfrei.

Alle Methoden und Funktionen, die nativer Bestandteil von Xbase++ sind, sorgen dafür, dass der in der Anwendung verwendete Zeichensatz bei Konvertierungen korrekt ankommt.

Tom hat geschrieben: ↑Di, 22. Dez 2020 13:38 Alle Methoden und Funktionen, die nativer Bestandteil von Xbase++ sind, sorgen dafür, dass der in der Anwendung verwendete Zeichensatz bei Konvertierungen korrekt ankommt.

Hallo Tom

da muss ich dir klar wiedersprechen! Das ist heute so aber das war früher nicht so.
z.B. in einem Programm das intern den Zeichensatz OEM verwendet musste z.B. der Betreff vor der übergabe nach ANSI gewandelt werden.
Das ist aktuell nicht mehr nötig. Der Code muss entsprechend angepasst werden bez. das umwanden in ANSI muss ausgebaut werden.
Du kannst dies gerne mit der Version 2.0.951 testen.

Carlo,

ich bin mir jetzt im Moment nicht ganz sicher, ob ich Dich richtig verstehe, oder Du etwas falsch verstehst.

Tom hat natürlich Recht wenn er sagt, das Xbase++ sich selber um die korrekten Konvertierungen kümmert. Aber dazu muß das natürlich wissen, was Du willst. Das, was Xbase++ selber erkennen kann, macht es auch. Manchmal so wild das man sich nicht daggen wehren kann, wie ich sleber mal leidvoll und zeitintensiv erkennen musste.

Bislang musste ich den Bestandteilen von MimeMessage wie Betreff oder Body mitgeben, welchen Zeichensatz das haben soll. Woher sollte der auch wissen, wie ich die Mails versendet haben will? Ich habe also beides beim Einbau in die Mail manuell nach UTF-8 konvertiert.

Jetzt nach der neuen Methode setCharset() muß ich das nicht mehr. Darf das sogar nicht mehr, denn dann würde das doppelt konvertiert werden. Das bedeutet: Ich gebe MimeMesage() mit, welchen Zeichensatz ich will, und der kümert sich selber darum alle relevanten Teile passend zu konvertieren. Egal aus welchem Zeichensatz im Programm die Strings her kommen.

Jan

Jedenfalls sollte es grundsätzlich so sein. Ganz egal, ob man mit ANSI, OEM oder einem anderen Charset arbeitet, Funktionen und Methoden, die im Ergebnis bestimmte Zeichensätze erwarten, werden das konvertieren. Das gilt z.B. für Wrapperfunktionen, die mit der API reden, für das ganze ActiveX-Gedöns usw..

Aber leider auch nicht immer. Die aus den Xbase-Tools importierte Funktion "File()" arbeitet intern mit ANSI, konvertiert aber nicht, wenn sie OEM bekommt. Das muss man berücksichtigen, wenn man noch mit OEM arbeitet. Dasselbe gilt für selbstgebaute Wrapper für DLL-Calls.

Tom,

der XbpFileDialog() hatte das gleiche Problem. Das hat Alaska dann aber mit PDR 7251 korrigiert, nachdem ich darauf hingewiesen hatte.

Jan