Autor Thema: Email-Kodierung und Umlaute (Gelesen 9110 mal)

hampa · « **am:** 13.03.12 - 14:51:17 »

Hallo zusammen,

Ich bin am Verzweifeln. Bei der Aufgabe, die ich lösen soll geht es um folgendes:

Ich erhalten von einem Email-Absender (kein Notes-Email) eine Email und speise diese in eine Mail-In Datenbank auf meinem Server ein. Umlaute werden wie folgt übersetzt (ü --> =FC)

Bei Content-Tranfer-Encoding steht in der Header-Infomartion des Body-Abschnitts "quoted printable" obwohl mir der Absender der Email einen Ausdruck des Quell-Textes der gesendeten Email überlassen hat, indem als Content-Tranfer-Encoding 7bit ausgewiesen wird.

Ich muss aus dem Email-Text eine neue Email erstellen und diese weiterschicken. Leider bleiben die Kodierten Zeichen weiterhin codiert. Das steht in der neuen Email "Gr=FCsse".

Wie bringe ich dem System bei, dass es entweder beim Empfangen von codiertem Text diesen als dekodierten Text ins Body Feld speichert? Oder muss ich während es erstellens der neuen Email etwas beachten?

Die erhaltenen Email lese ich übrigens als MIME-Email aus und erstelle die neue Email ebenfalls mit MIME.

Vielen Dank für jeden Tipp

Grüsse
Hampa

m3 · « **Antwort #1 am:** 13.03.12 - 15:06:06 »

"einspeisen"? Manuell mit Code?
Pls. explain.

Und zeig mal den anonymiserten Source der Mail her.

hampa · « **Antwort #2 am:** 13.03.12 - 16:24:26 »

Hallo Martin

Mit "einspeisen" meinte ich, dass ich einen "Mail-In Database" Eintrag (Dokument) erstellt habe, der mir Emails, die an eine darin definierte Email adressiert sind an die definierte Datenbank schickt und aus dieser Email ein Dokument mit der Form "Memo" in der Datenbank erstellt.

In diesem Dokument befinden sich nun vier Body-Felder mit folgendem Inhalt:

Code

Body-Feld-1:
"Content-Type: multipart/mixed; 
 boundary="----=_Part_1050_33530222.1331648857364"
"

Body-Feld-2:
"------=_Part_1050_33530222.1331648857364
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;charset=iso-8859-1

<CustomerEmail>
<Application>CF</Application>
<To>hans.Muster@test.com</To>
<Subject>Ich bin das Subject</Subject>
<Body><br><br>Anbei der Kommentar zur offenen Frage zum Thema Rechnungstell=
ung.

Beste Gr=FCsse<br><br></Body>
<MailTime>TimeStamp</MailTime>
</CustomerEmail>"

Body-Feld-3:
"
------=_Part_1050_33530222.1331648857364
Content-Type: audio/x-wav; 
 name=Voice-File-33.wav
Content-Disposition: attachment; 
 filename=Voice-File-33.wav
Content-Transfer-Encoding: base64

Voice-File-33.wav"

Body-Feld-4:
"
------=_Part_1050_33530222.1331648857364--
"

Aus diesen Angaben, die im XML verpackt sind, muss ich nun ein neues Email zusammenstellen und weiterschicken. Das Problem ist jetzt, wie ich auch den Codierten Umlauten und "Zeilenenden" den korrekten Text bekomme.

Gruss und Dank
Hampa

Peter Klett · « **Antwort #3 am:** 13.03.12 - 17:04:36 »

Merkwürdig, saß am Wochenende genau an dem gleichen Problem, habe es innerhalb meines Scriptes schlicht mit Replace übersetzt. Hatte als Grundlage das Tool RTF2HTML von nsftools. Hier mein Codefetzen dazu

Dim suchenersetzen List As String
suchenersetzen ("=" & Chr (13) & Chr (10)) = ""
suchenersetzen ("=E4") = "ä"
suchenersetzen ("=F6") = "ö"
suchenersetzen ("=FC") = "ü"
suchenersetzen ("=C4") = "Ä"
suchenersetzen ("=D6") = "Ö"
suchenersetzen ("=DC") = "Ü"
suchenersetzen ("=DF") = "ß"
suchenersetzen ("=A7") = "§"
suchenersetzen ("=E9") = "é"
suchenersetzen ("=3D") = "="
Forall se In suchenersetzen
mText = Replace (mText, Listtag (se), se)
End Forall

Die Liste der zu ersetzenden Zeichen kann natürlich beliebig verändert werden. Evtl. verwendest Du auch UChr, um plattformunabhängig zu sein.

pram · « **Antwort #4 am:** 13.03.12 - 19:25:22 »

Liest du die Mime-Items über XML oder über die NotesMimeItems aus?
Wenn letzteres, müsstest du mit mimentity.decodeContent/...encodeContent(ENC_NONE) eigentlich zum Ziel kommen.
Die Lösung von Peter würd ich nur machen, wenn es nicht anders geht (irgend ein Zeichen vergisst man ja immer in der Übersetzungstabelle und irgendwann stellt der Absender das Encoding um)

Werbung

: Folgendes auch unbedingt lesen: http://atnotes.de/index.php/topic,52040.msg334799.html (falls noch nicht geschehen)

Gruß
Roland

koehlerbv · « **Antwort #5 am:** 13.03.12 - 20:45:42 »

Zitat von: pram am 13.03.12 - 19:25:22

Werbung

Keine Werbung, Roland - Pflichtlektüre

Bernhard

hampa · « **Antwort #6 am:** 13.03.12 - 21:05:33 »

Hallo zusammen

@Peter. Diesen Ansatz habe ich mir auch schon überlegt. Wie Roland sagt, würde ich das wirklich nur einsetzen wollen/müssen, wenn ich's wirklich nicht anders hinbekomme. Der Text der da stehen kann ist Freitext, den der User eingeben kann und da weiss man ja nie, auf was für Ideen die kommen.

@Roland. Danke für den Link. Diesen Artikel habe ich in meiner Verzweiflung schon x-mal gelesen. Aber ich werde ihn noch einmal lesen, da ich bestimmt etwas übersehen habe.

Das mit mimeentity.decodeContent/...encodeContent(ENC_NONE) werde ich gleich morgen ausprobieren. Im voraus schon mal besten Dank für den Hinweis.

Gruss
Hampa

Peter Klett · « **Antwort #7 am:** 13.03.12 - 23:32:35 »

@Roland: Danke auch von mir für den Tipp

Habe es jetzt so umgeschrieben:

If Not (mimeItem Is Nothing) Then
If (mimeItem.Type = MIME_PART) Then
Set mime = mimeItem.GetMimeEntity
If Not (mime Is Nothing) Then
Call mime.DecodeContent
Call mime.EncodeContent (ENC_NONE)
...

Das Ergebnis ist grundsätzlich super, die anschließend erzeugte HTML-Datei (die bei mir am Ende herauskommen muss) sieht im Browser perfekt aus. Aber die Umlaute sind nicht übersetzt äöüæøå stehen im Klartext, also kein ä usw.. Ist das heute nicht mehr aktuell? Oder gibt es eine andere Encode-Variante?

Ich werde jetzt beide Verfahren kombinieren. Erst mit DecodeContent und EncodeContent grundsätzlich "schick" machen und dann die gebräuchlichsten Umlaute zu Fuß nachübersetzen. Und wenn da einer vergessen wird, und irgendein Browser das falsch darstellt, dann ist es halt so ...

Aber sicherlich hast Du da auch noch einen Tipp parat.

pram · « **Antwort #8 am:** 14.03.12 - 00:18:14 »

Umlaute sind m.E. erlaubt, und müssen nicht übersetzt werden, wenn die Encodierung passt.
entweder setzt du die Codierung in einem HTML-Header, das geht in einem Notes-Agenten z.B. mit

print "Content-Type: text/html; charset=utf-8"
print "" ' leerzeile zum signaisieren: Header ende
print "<doctype....."

Alternativ kann man den Contet-Type bzwl Charset *) auch in der Maske/Page/... angeben (option müsste ich jetzt nachsehen)
oder eben über einen speziellen "<meta...." Tag.
Bis jetzt hatte ich (nach dem ich das richtige Encoding rausgefunden hatte) keine Probleme mit Umlauten, auch ohne Ersetzung (bis auf die Steuerzeichen < > & " )
Die Ersetzungsliste ist ja inzwischen endlos: http://de.selfhtml.org/html/referenz/zeichen.htm
Wobei eine Ersetzung von ä=>ä etc. mit Sicherheit nicht falsch ist, allerdings wird man nie alle, wenn auch in unserer Region seltene, Sonderzeichen erfassen können, so dass man versuchen sollte, das Problem durch ein korrektes Encoding zu fixen.
(@Peter: Da deine Datei jetzt sauber aussieht, denke ich hast du das auch geschafft)

Wenn die Umlaute, Steuer und escapezeichen ( < > " ' & / \ ) dann sauber durchkommen, mach ich als Härtetest oft eine "UTF-8-Insel": *̡͌l̡*̡̡ ̴̡ı̴̴̡ ̡̡͡|̲̲̲͡͡͡ ̲▫̲͡ ̲̲̲͡͡π̲̲͡͡ ̲̲͡▫̲̲͡͡ ̲|̡̡̡ ̡ ̴̡ı̴*̡͌l̡*-

Wenn diese Sonderzeichen 1x den Roundtrip schaffen, gehe ich davon aus, dass ich nicht viel beim Encoding falsch gemacht habe.

Gruß
Roland

*) Vielleicht nochmal zur Klarstellung, weil ich das selber oft ein wenig vermische

Content-Type:
Der "Doumenttyp", z.B. text/html, image/gif, application/octet-stream....

Content-Transefer-Encoding:
Die Art, wie der Content über den Kommunkikationskanal übertragen wird. Gängig ist: None bzw. Binary, Base64, quoted-printable, 7bit (falls keine Zeichen > 128), chunked
(letzteres ist bei Notes-Agenten nützlich, wenn man größere Attachments senden will: http://atnotes.de/index.php/topic,50597.msg324992.html#msg324992)

Charset:
Das Charset spielt eigentlich nur bei Texten eine Rolle. Nachdem der Content encodiert wurde, muss der Browser (oder auch Texteditor) wissen, wie er die einzelnen Bytes darstellen muss. Am Gängisten ist inzwischen wohl UTF-8, gefolgt von ISO-8859-15, CP1252, ASCII,....
das Charset wird i.d.R. hinter dem Content-Type angegeben: z.B. "text/html; charset=UTF-8" (das funktioniert auch, wenn man das so in einer Maske/Page eingibt)

Peter Klett · « **Antwort #9 am:** 14.03.12 - 00:33:40 »

Vielen Dank. Habe inzwischen auch die Umlaute-Übersetzung wieder rausgenommen, nachdem mir

ø in ö übersetzt wurde (er sollte das überhaupt nicht übersetzen, hat es aber als ö erkannt)

Was immer der da gelesen hat. Ich lasse es jetzt so und fasse das erst wieder an, falls ein Problem auftritt.

Der Tipp mit dem Decode und Encode ist aber Gold wert, da schläft es sich gleich ruhiger ...

pram · « **Antwort #10 am:** 14.03.12 - 07:50:22 »

@Peter: Ich hab nochmal nachgedacht, eigentlich sollte eine der beiden Zeilen reichen:
Call mime.DecodeContent
Call mime.EncodeContent (ENC_NONE)
da sie in meinen Augen äquivalent sind.

Zu deimen Ersetzungsproblem: Notes macht da oft ganz komische Sachen und ehandelt bestimmte Zeichen bei bestimmten Ländereinstellungen "gleich":
In (deutschen) Ansichten wird z.B. "ue" und "ü" gleich behandelt.
(Mach mal eine kategorisierte Ansicht mit dem Eintrag "Müller" und "Mueller" => sie landen in der gleichen Kategorie, auch ein Lookup nach "Müller" liefert u.U. "Mueller" als Treffer und umgekehrt)

Beim Stringvergleich habe ich ebenso schon solche Dinge erlebt: z.B. ƒ = f

Und seit ich das gelesen habe: http://atnotes.de/index.php/topic,49757.msg319797.html#msg319797
mache ich Vergleiche an kritischen Stellen zeichenbasiert mit Asc/Uni (meist geht es um das Herausfiltern von Sonderzeichen)

Ich denke dass bei deinem Replace auch dieses "Feature" zugeschlagen hat.

Gruß
Roland

Peter Klett · « **Antwort #11 am:** 14.03.12 - 08:24:12 »

Ja, Du hast Recht, nur mit DecodeContent bekomme ich das gleiche Resultat.

Das mit den Übersetzungen habe ich auch schon festgestellt. Mit norwegischer Ländereinstellung wird aa (was ja recht weit vorne im Alphabet steht) stumpf in å übersetzt, und das ist das drittletzte Zeichen (und so wird es hier auch einsortiert, im Gegensatz zu einem deutschen Umlaut, denn å ist kein Umlaut, sondern ein eigenständiger Buchstabe). Beim ersten mal habe ich mir einen Wolf nach einem Dokument gesucht, dessen Kategorie in der Ansicht mit Aa anfing (z.B Aachen) ...

Wer das gebaut hat, hat sich bestimmt was dabei gedacht, ich möchte nur nicht wissen, was

hampa · « **Antwort #12 am:** 14.03.12 - 10:32:08 »

Hallo zusammen

Ich habe mich heute morgen gleich ans Umsetzen des Tipps von Roland gemacht und meinen Java-Code geöffnet und... ich war schon einwenig enttäuscht. Entäuscht deshalb, weil ich im Code diese beiden Befehl vorfand. Ich füge mal den Code ein, vielleicht sieht jemand den Fehler der dazu führt, dass auch =FC kein ü wird.

Code

try {
	// Parse the XML body of the mail message.			
	// Do not convert MIME to rich text
	s.setConvertMIME(false);
	MIMEEntity mime = docSourceEmail.getMIMEEntity();
	if (mime != null) {

		// DecodeContent
		mime.decodeContent();
	        mime.encodeContent(MIMEEntity.ENC_NONE);
		          
		// If multipart MIME entity
		if (mime.getContentType().equals("multipart")) {

		          // Read content of each child entity
		         MIMEEntity child1 = mime.getFirstChildEntity();
		         if (child1 != null) {
			sTmpBodyText = child1.getContentAsText();
		         }					
		} else {
			// If not multipart, just print content
			sTmpBodyText = mime.getContentAsText();
		}
	} else {
			throw new ParserException("[parseXMLBody] Keine gültige XML-Message vorhanden.");
	}

		// <br>-Varianten durch CRLF ersetzen
		sBodyText = sTmpBodyText.replaceAll("<br>|<br\\>|<br \\>", "\r\n");
						
		// Aus dem RichTextFeld die XML-Message "herausschälen"
		// Bestehende Item "BodyText" löschen
		if (docSourceEmail.hasItem("BodyText")) {
			docSourceEmail.removeItem("BodyText");
		}

		// Neues NotesItem auf dem Dokument erstellen.
		RichTextItem inBodyText = docSourceEmail.createRichTextItem("BodyText");
			
		// Start und End-Position der XML-Message feststellen
		logger.debug("Unformatted Text from Body: " + sBodyText);
		int iStartPos = sBodyText.indexOf("<CustomerEmail>");
		logger.debug("[SMCUtils.parseXMLBody] Startposition <CustomerEmail>: " + iStartPos);
		int iEndPos = sBodyText.indexOf("</CustomerEmail>");
		logger.debug("[SMCUtils.parseXMLBody] Startposition </CustomerEmail>: " + iEndPos);

		// Prüfen, ob eine gültige XML-Message vorhanden ist.
		if ((iStartPos < 0 || iEndPos < 0) || (iStartPos > iEndPos)) {
			throw new ParserException("[parseXMLBody] Keine gültige XML-Message vorhanden.");
		}

		// XML-Message aus dem gesamten Body herausschneiden
		String sTmpBodyXMLMessage = sBodyText.substring(iStartPos, iEndPos + 16);
		logger.debug("[SMCUtils.parseXMLBody] XML-Message (Trim): " + sTmpBodyXMLMessage);

		// XML-Message in neues Item abfüllen
		inBodyText.appendText(sTmpBodyXMLMessage.trim());
		// Document speichern
		docSourceEmail.save();
                               .......

Gruss und Dank
Hampa

pram · « **Antwort #13 am:** 14.03.12 - 12:50:58 »

Zitat von: hampa am 14.03.12 - 10:32:08

Hallo zusammen

Ich habe mich heute morgen gleich ans Umsetzen des Tipps von Roland gemacht und meinen Java-Code geöffnet und... ich war schon einwenig enttäuscht. Entäuscht deshalb, weil ich im Code diese beiden Befehl vorfand. Ich füge mal den Code ein, vielleicht sieht jemand den Fehler der dazu führt, dass auch =FC

Aber klar doch....

Code

....
	          // Read content of each child entity
	         MIMEEntity child1 = mime.getFirstChildEntity();
	         if (child1 != null) {
			sTmpBodyText = child1.getContentAsText();
	         }

child1 will auch noch dekodiert werden.

Gruß
Roland

hampa · « **Antwort #14 am:** 14.03.12 - 13:25:37 »

Hallo Rolaaaaaaand !

Zitat von: pram am 14.03.12 - 12:50:58

Aber klar doch....
child1 will auch noch dekodiert werden.

Wenn du einen Frau wärst würde ich dich auf der Stelle küssen!

Es funktioniert! Und wie! Jipiii!

Es hat sich mir aus dem Help vom Notes-Designer nicht erschlossen, dass jede MIMEEntity gesondert decoded werden will. Aber jetzt weiss ich's besser.

Vielen, vielen herzlichen Dank

Hampa

Autor Thema: Email-Kodierung und Umlaute (Gelesen 9110 mal)

hampa

Email-Kodierung und Umlaute

m3

Re: Email-Kodierung und Umlaute

hampa

Re: Email-Kodierung und Umlaute

Peter Klett

Re: Email-Kodierung und Umlaute

pram

Re: Email-Kodierung und Umlaute

koehlerbv

Re: Email-Kodierung und Umlaute

hampa

Re: Email-Kodierung und Umlaute

Peter Klett

Re: Email-Kodierung und Umlaute

pram

Re: Email-Kodierung und Umlaute

Peter Klett

Re: Email-Kodierung und Umlaute

pram

Re: Email-Kodierung und Umlaute

Peter Klett

Re: Email-Kodierung und Umlaute

hampa

Re: Email-Kodierung und Umlaute

pram

Re: Email-Kodierung und Umlaute

hampa

Re: Email-Kodierung und Umlaute