Inoffizielles deutsches Xbase-Forum

Hi Leute,

um eine Datei per E-Mail via MIMEMessage:attachFile() versenden zu können, muss ein ANSI-Dateiname übergeben werden. Auf der Empfängerseite werden anschliessend in der Liste der Anhänge die Umlaute im Dateiname als schwarze Raute mit Fragezeichen angezeigt.

Hat jemand diesen Konflikt gelöst?

ConvToAnsiCp() oder ConvToOemCp() ?

ConvToAnsiCp() brauche ich in meinen Mail-Funktionen.

Ja, gelöst durch eine Funtion welche in den Dateinamen lediglich a-z 0-9 sowie die Zeichen -_. zulässt und alle anderen Zeichen entsprechend ersetzt und die Datei zur weiteren Verwendung automatisch umbenennt .

Gruss Carlo

Danke,

@Roland: Das trifft das Problem leider nicht. Dieses entsteht dadurch, dass für das Einlesen der Datei der Dateiname in ANSI , für die Anzeige im MailClient jedoch in UTF8 benötigt wird.

@Carlo: So habe ich mir auch beholfen, nur gefallen mir Aufwand und Ergebnis nicht.

Der Support hat eine Lösung mit einer undokumentierten Methode gesandt. Mit ihr funktionieren die Umlaute, es gibt aber noch ein Problem mit der Darstellung des Inhalts. Ich informiere euch, sobald wir die Lösung haben.

Eigentlich sollte die Methode den ANSI Namen nutzen um die Datei auf dem lokalen Rechner zu lesen, aber an MIME als UTF8 übergeben.
Wenn diese das nicht tut ...

so ist das, Hubert, so ist das...

Guten Morgen,

die Lösung funktioniert nun Dank der kräftigen und zeitnahen Hilfe von Alaskas Support. Das Problem wird im PDR 6351 beschrieben. Wer nähere Infos braucht, kann sich gerne per PN melden.

Hallo Klaus !

Wer nähere Infos braucht, kann sich gerne per PN melden.

Warum stellst du die Lösung (in Schritten) nicht hier ein?
Dafür ist doch ein Forum da.
Hubert könnte das dann ins Archiv stellen

Hallo HaPe,

da die Lösung von Alaska stammt und von mir nur angepasst und ein wenig ergänzt wurde, habe ich beim Support nachgefragt, ob ich diese in's Forum stellen können. Als Antwort bekam ich den Verweis auf die PDR. Keine Ahnung wie das urheberrechtlich zu bewerten ist. Vielleicht gibt es auch eine Übereinkunft zwischen dem Forum und Alaska? Kann jemand vom Vorstand etwas dazu sagen?

Moin Klaus,
es gibt keine diesbezügliche Übereinkunft!
Wenn Alaska möchte, dass auf den PDR verwiesen wird, dann ist das so hinzunehmen.
Habt ihr euch den PDR schon mal angeschaut?

Viele Grüße,
Martin

Hier mal der deeplink: http://www.alaska-software.com/scripts/ ... PDRID=6351
Der dort unter Solution gepostete Code dürfte auch das sein, was Klaus von Alaska erhalten hat.

Viele Grüße,
Martin

Moin Martin,

sie waren so freundlich zusätzlich eine Funktion, welche die Funktion im PDR anwendet, zu liefern.

Wenn Alaska auf die Anfrage auf den PDR verweist, dann müssen wir das so hinnehmen. Grundsätzlich ist das ja auch OK so, denn warum sollte das doppelt gepostet werden? Als PDF bei Alaska und bei uns im Forum? nach dem Hinweis von Klaus auf den PDR kann ja jeder hier nachschauen, worum es da geht und wie man mit dem Problem umgehen kann.

Ich denke aber auch das nichts dagegen spricht, wenn Klaus hier seinen Code postet mit seinen Anpassungen des PDR-Codes inkl. dem Hinweis warum genau er das so angepasst hat. Denn DAS könnte ja in der Tat etwas sein was hier alle interessiert. Und er PDR nicht hergeben kann.

Jan

der Kern besteht tatsächlich aus der Funktion im PDR. Die Schritte darum sind:

Inhalt der Anhang-Datei mit FRead einlesen

eingelesenen Inhalt mit Bin2Base64 umwandeln

korrekten Typ für MimeContent():new() mit der Dateiendung nach 'application/' und EncodeHeader(Dateiename) nach 'name=' erstellen

MimeContent():new( umgewandelter Inhalt, Typ, 'base64' ) aufrufen

das erzeugte Objekt mit ::attachMixed anstelle von ::attachFile als Anhang übergeben.

Wichtig ist, das CHARSET auf ANSI steht. Ggf. danach zurücksetzen.

Hallo Klaus !

Vielen Dank fürs einstellen

@Klaus

wenn es funktioniert...

Es geht um den Dateinamen und die ganze Datei muss gewandelt werden?
Das kann es doch nicht sein - Umwandlung des Dateiinhalts nur um Umlaute in den Dateinamen zu bringen.
Da würde ich Nebenwirkungrn erwarten beim Versand von Binärdaten.

Würd ich nie machen. Dann lieber einen anderen Weg suchen.

Moin Roland,

DelUser01 hat geschrieben: ↑Mi, 07. Mär 2018 12:43Das kann es doch nicht sein - Umwandlung des Dateiinhalts nur um Umlaute in den Dateinamen zu bringen.
Da würde ich Nebenwirkungrn erwarten beim Versand von Binärdaten.

Da kann ich Dich beruhigen - Umwandlung in MIME ist beim Versand von Dateien (nicht nur bei Binärdateien) als Mailanhang eigentlich Pflicht - alles andere geht eh nicht (also Versand per Mail ohne Umwandlung)!

Viele Grüße,
Martin

Für die Ungläubigen unter Euch: https://de.wikipedia.org/wiki/Multipurp ... Extensions

Viele Grüße,
Martin

Dann ist die Vorgehensweise ja eher normal und kein Workaround. Und da gibt es immer noch keine Funktion in Xbase++ die das am Stück erledigt...?

DelUser01 hat geschrieben: ↑Mi, 07. Mär 2018 12:43 Es geht um den Dateinamen und die ganze Datei muss gewandelt werden?
Das kann es doch nicht sein - Umwandlung des Dateiinhalts nur um Umlaute in den Dateinamen zu bringen.

wie Martin schrieb, ist das immer so, dass ALLE Daten die mehr als 7 bit ASCII Zeichen benötigen, bei eMails in ein Format gewandelt werden müssen, das nur noch 7 bit ASCII Zeichen enthält.
Das Standardverfahren bei eMail ist base64.

DelUser01 hat geschrieben:Dann ist die Vorgehensweise ja eher normal und kein Workaround. Und da gibt es immer noch keine Funktion in Xbase++ die das am Stück erledigt...?

Die Methode attachFile() macht genau das mit dem Dateiinhalt, nämlich umwandeln nach base64 Format und anhängen ...
lediglich beim Dateinamen wurde die Umwandlung von OEM / Ansi nach UTF8 vergessen - oder die Umsetzung der Methode ist älter als "Umlaute in Dateinamen sind erlaubt"

Egal wie, die vorgestellte Lösung korrigiert nur den Dateinamen ... aber der Hinweis notfalls die EXE auf ANSI und dann wieder zurück umzustellen ist nicht sinnvoll

Wenn die EXE Ansi ist, kann man direkt den Fehler des Dateinamens so verbessern:

cUtf8FileName := Bin2Base64(Char2Utf8(cStr))

wenn die EXE auf OEM steht, sollte die neue Funktion Char2Utf8(cOemStr) dennoch einen richtigen UTF8 String erzeugen, aber es könnte sein, dass der ANSI Name aus directory() zuerst noch nach OEM umgesetzt werden muss, da eine Funktion nicht erkennt, ob ANSI im String ist oder nicht, es geht rein um die OEM / Ansi Einstellung des Programmes:

Char2UTF8()
Convert an OEM/ANSI encoded character string to an UTF8 encoded character string

Char2UTF8( <cString>] ) --> utf8String

dann müsste man also statt ...

cUtf8FileName := Bin2Base64(Char2Utf8(cStr))

wenn die EXE auf OEM steht ....

Code: Alles auswählen

cOemStr := convToOemCP(cAnsiStr)
cUtf8FileName := Bin2Base64(Char2Utf8(cOemStr))

verwenden.

Ich habe früher meine eigenen Funktionsbibliothek in OEM und ANSI Quellcode vorgehalten, das mache ich jetzt nicht mehr, unterscheide mit diesen Funktionen ...

Code: Alles auswählen

// besser wäre es die Parameter 1 und 0 gleich durch die Konstanten aus COLLAT.CH zu ersetzen, 
// aber ich glaube nicht, dass sich diese hier ändern ;-)
// #define CHARSET_OEM      1
// #define CHARSET_ANSI      0

*--------------------------------------------------------------------------------
function IsOEM()
return ( set(_SET_CHARSET) = 1 )
*--------------------------------------------------------------------------------
function IsAnsi()
return ( set(_SET_CHARSET) = 0 )

den aktuellen Zustand und sehe beide Umsetzungen vor, so spart man sich Ärger, wenn die EXE später doch auf ANSI geändert wird:

Code: Alles auswählen

// directory liefert immer ANSI Namen ... Vorsicht, bei OEM EXE, hier werden je nach Aufgabe entweder OEM oder ANSI Version benötigt !
cAnsiFileName := aFiles[x,F_NAME]
if IsOEM()
   cOemFileName := convToOemCP(cFileName)
endif
... nimm was du brauchst ....
cAnsiFileName
cOemFileName

Alle neuen Programme (immer GUI) nutzen bei mir nur noch ANSI, aber meine Funktionsbibliotheken sollen die Abhängigkeit von dieser Einstellung verlieren,
ein Quellcode für beide Welten

Hallo Hubert,

da ich kongurierend mit einer Clipper-Anwendung auf die Daten zugreife, arbeite ich vorsichtshalber mit OEM. Daher der Hinweis ggf. auf ANSI umzustellen.

Ein schöner Seiteneffekt davon, dass der Inhalt vorab eingelesen wird, ist, dass man der E-Mail einen abweichenden Namen für die Datei mitgeben kann. Ich verwende zur zeitlichen Steuerung von Dateien eine Angabe des Zeitraums im Dateinnamen: DateiName[TT.MM.JJJJ-TT.MM.JJJJ].xxx. Das sieht in der Mail natürlich für den Endkunden nicht gut aus. Mit dem Seiteneffekt kein Problem mehr. Ebenso können Pfadangaben entfernt werden, usw.

Klaus Schuster hat geschrieben: ↑Mi, 07. Mär 2018 17:49 arbeite ich vorsichtshalber mit OEM. Daher der Hinweis ggf. auf ANSI umzustellen.

ich meinte es spricht nichts gegen die OEM EXE, aber nicht für den Bereich die EXE Einstellung ändern,
sondern diese ermitteln (falls man sicher gehen will) und mit ConvToAnsiCP() etc. die Umwandlung direkt verwenden, wenn man diese benötigt !

Code: Alles auswählen

   // Implement overloaded MimeMessage class
   CLASS MyMIMEMessage FROM MIMEMessage
     EXPORTED
       METHOD attachFile
   ENDCLASS

   //
   // Overload method :attachFile().
   // This implementation always encodes using base64.
   // Alos, this method accepts the encoding-type.
   //
   METHOD MyMIMEMessage:attachFile( cFileName, cType )
     LOCAL nHandle, nBytes, nLen, cBuffer

     // Read the file if possible
     IF ! FILE( cFileName ) .or. (nHandle := fopen(cFileName, FO_READ)) == -1
        RETURN .F.
     ENDIF

     // Request buffer of required size
     nBytes := FSize( nHandle )
     cBuffer := Space( nBytes )

     // Read the file
     nLen := FRead( nHandle, @cBuffer, nBytes )

     // Close File
     FClose( nHandle )

     IF nLen != nBytes
       RETURN .F.
     ENDIF

     default cType to "application/" + substr(cFileName, rat(".", cFileName) + 1) + "; name=" + Char2UTF8(dateiname(cFileName))
     // Attach buffer contents mixed
     ::MIMEContent:attachMixed( MIMEContent():encodeBase64( cBuffer, cType ) )
   RETURN .T.


function dateiname(cDatei) // gibt den reinen Dateinamen ohne evtl. Pfad zurück

cDatei := alltrim(substr(cDatei, rat("\", cDatei) + 1))
return substr(cDatei, rat("/", cDatei) + 1)  // falls "/" vorkommt

Ergänzend zum PDR 6351 und die Lösung für UTF-8-Mails:

Code: Alles auswählen

oMail := MyMIMEMessage():encodeQuotedPrintable( Char2UTF8(cBody), "text/html; charset=UTF-8")
oMail:attachFile("öäüß.pdf")

Inoffizielles deutsches Xbase-Forum

Umlaute mit MIMEMessage:attachFile()

Umlaute mit MIMEMessage:attachFile()

Re: Umlaute mit MIMEMessage:attachFile()

Re: Umlaute mit MIMEMessage:attachFile()

Re: Umlaute mit MIMEMessage:attachFile()

Re: Umlaute mit MIMEMessage:attachFile()

Re: Umlaute mit MIMEMessage:attachFile()

Re: Umlaute mit MIMEMessage:attachFile()

Re: Umlaute mit MIMEMessage:attachFile()

Re: Umlaute mit MIMEMessage:attachFile()

Re: Umlaute mit MIMEMessage:attachFile()

Re: Umlaute mit MIMEMessage:attachFile()

Re: Umlaute mit MIMEMessage:attachFile()

Re: Umlaute mit MIMEMessage:attachFile()

Re: Umlaute mit MIMEMessage:attachFile()

Re: Umlaute mit MIMEMessage:attachFile()

Re: Umlaute mit MIMEMessage:attachFile()

Re: Umlaute mit MIMEMessage:attachFile()

Re: Umlaute mit MIMEMessage:attachFile()

Re: Umlaute mit MIMEMessage:attachFile()

Re: Umlaute mit MIMEMessage:attachFile()

Re: Umlaute mit MIMEMessage:attachFile()

Re: Umlaute mit MIMEMessage:attachFile()

Re: Umlaute mit MIMEMessage:attachFile()

Re: Umlaute mit MIMEMessage:attachFile()