javascript, window.open, mailto und kyrillische Texte
John
mich beschäftigt zur Zeit folgendes Problem: Ich möchte per Javascript
einen Mailto Link ausführen, der mir dann das Client Email Programm
öffnet.
Ich mache dies wie folgt (Javascript):
function xyz() {
var subj = escape("...");
var body = escape("....");
window.open('mailto:reci...@xyz.test?subject='+subj+'&body);
}
Wenn diese Funktion aufgerufen wird, öffnet sich der lokale
Emailclient und eigentlich wäre nun alles gut.
Es funktioniert in allen (von mir benötigten) Sprachen (getestet ist
für Deutsch, Englisch, Kroatisch, Tschechisch, Spanisch, Slowakisch)
außer in Kyrillisch.
In Kyrillisch erscheinen Subject und Body im Email Client wie folgt.
%u0430%u0442%u0438%u0441%u043D%u0456%u0442%u044C %u043D
%u0430%u0441%u0442%u0443%u043F%u043D%u0435 %u043F%u043E
%u0441%u0438%u043B%u0430
Schaue ich mir den HTML Sourcecode an, steht im escape Teil des
subjects/bodys aber correct der kyrillische Text.
Ich stehe vor einem Rätsel und hoffe, jemand weiß hier Rat.
Danke und Gruß
John
Chris Seidel
> In Kyrillisch erscheinen Subject und Body im Email Client wie folgt.
>
> %u0430%u0442%u0438%u0441%u043D%u0456%u0442%u044C %u043D
> %u0430%u0441%u0442%u0443%u043F%u043D%u0435 %u043F%u043E
> %u0441%u0438%u043B%u0430
>
> Schaue ich mir den HTML Sourcecode an, steht im escape Teil des
> subjects/bodys aber correct der kyrillische Text.
Ich sag mal, der EMail-Client kann das dann nicht?
Holger Jeromin
> mich besch�ftigt zur Zeit folgendes Problem: Ich m�chte per Javascript
> einen Mailto Link ausf�hren, der mir dann das Client Email Programm
> �ffnet.
Auch nicht immer und �berall...
Man denke an die vielen Leute die nur Webmail nutzen.
> Ich mache dies wie folgt (Javascript):
>
> function xyz() {
> var subj = escape("...");
> var body = escape("....");
> window.open('mailto:reci...@xyz.test?subject='+subj+'&body);
> }
>
> Wenn diese Funktion aufgerufen wird, �ffnet sich der lokale
> Emailclient und eigentlich w�re nun alles gut.
>
> Es funktioniert in allen (von mir ben�tigten) Sprachen (getestet ist
> f�r Deutsch, Englisch, Kroatisch, Tschechisch, Spanisch, Slowakisch)
> au�er in Kyrillisch.
>
> In Kyrillisch erscheinen Subject und Body im Email Client wie folgt.
>
> %u0430%u0442%u0438%u0441%u043D%u0456%u0442%u044C %u043D
> %u0430%u0441%u0442%u0443%u043F%u043D%u0435 %u043F%u043E
> %u0441%u0438%u043B%u0430
>
> Schaue ich mir den HTML Sourcecode an, steht im escape Teil des
> subjects/bodys aber correct der kyrillische Text.
>
> Ich stehe vor einem R�tsel und hoffe, jemand wei� hier Rat.
escape basiert auf latin1, wo es keine Entsprechung f�r kyrillisch
Zeichen gibt. Also bleibt dem EcmaScript interpreter nichts anderes
�brig, als sie anders zu speichern. Daher kommst du zu den %u0430
Unicodezeichen, welche der E-Mail client (welcher eigentlich?) nicht
unterst�tzt.
--
Mit freundlichen Gr��en
Holger Jeromin
Thomas 'PointedEars' Lahn
> escape basiert auf latin1, wo es keine Entsprechung für kyrillisch
> Zeichen gibt.
Das ist falchs. Das proprietäre escape() basiert zunächst einmal lediglich
auf 8-Bit-Zeichencodierungen und damit implementierbaren Zeichensätzen;
davon ist ISO-8859-1 (Latin-1) einer. Aber auch für Kyrillisch gibt es
natürlich (mindenstens) eine(n), darunter KOI8-R und ISO-8859-5, denn auch
z.B. Russen möchten für ihre normale Schriftsprache keine Unicode-Tastatur
benutzen müssen.
<http://de.wikipedia.org/wiki/Kyrillisches_Alphabet#Zeichenkodierung>
> Also bleibt dem EcmaScript interpreter nichts anderes
> übrig, als sie anders zu speichern.
Das ist ebenfalls fhcsal. Es gibt keinen "EcmaScript interpreter" (egal wie
man das schreibt. Konkret werden wird syntaktisch korreter Quelltext von
ECMAScript-Implementationen wie JavaScript und JScript zu Bytecode
*compiliert* und *dieser Bytecode* dann von einer Virtuellen Maschine
interpretiert. Ausserdem werden die Zeichen nicht von der Script-Engine
(die das zuvor beschriebene macht) konvertiert; sie liegen hier bereits per
Script-Ressource (hier: HTML-Dokument) oder DOM API so vor.
> Daher kommst du zu den %u0430 Unicodezeichen, welche der E-Mail client
> (welcher eigentlich?) nicht unterstützt.
Und nochmal mit beiden Händen voll ins Klo gegriffen. Der E-Mail-Client
unterstützt "Unicodezeichen" sehr wahrscheinlich; sie müssen nur im URI
richtig codiert werden, nämlich äquivalent `%04%30', so wie es
encodeURIComponent() macht und in RFC3986 definiert ist. `%u0430' ist
hingegen kein "Unicodezeichen" (egal wie man es schreibt).
Bitte geh Dich informieren, bevor Du hier weiteren Unfug verbreitest.
PointedEars
Thomas 'PointedEars' Lahn
Wahrscheinlich kann er es. Die Frage wurde dem multipostenden
OP auch in comp.lang.javascript bereits ausführlich beantwortet.
PointedEars
Thomas 'PointedEars' Lahn
> Holger Jeromin wrote:
>> Daher kommst du zu den %u0430 Unicodezeichen, welche der E-Mail client
>> (welcher eigentlich?) nicht unterstützt.
>
> [...] Der E-Mail-Client unterstützt "Unicodezeichen" sehr wahrscheinlich;
> sie müssen nur im URI ichtig codiert werden, nämlich äquivalent `%04%30',
> so wie es encodeURIComponent() macht und in RFC3986 definiert ist.
Korrektur: U+0430 wird in UTF-8 mit D0 B0 (*11*01 0000 *10*11 0000)
codiert¹, d.h. die korrekte Prozent-Codierung dafür ist "%D0%B0", was
encodeURIComponent() in meinem Firefox/Iceweasel 3.5.3 auch liefert.
PointedEars
___________
¹ <http://de.wikipedia.org/wiki/UTF-8#Kodierung>
Holger Jeromin
> Holger Jeromin wrote:
>> escape basiert auf latin1, wo es keine Entsprechung für kyrillisch
>> Zeichen gibt.
> Das ist falchs. Das proprietäre escape() basiert zunächst einmal lediglich
> auf 8-Bit-Zeichencodierungen und damit implementierbaren Zeichensätzen;
> davon ist ISO-8859-1 (Latin-1) einer. Aber auch für Kyrillisch gibt es
> natürlich (mindenstens) eine(n), darunter KOI8-R und ISO-8859-5, denn auch
> z.B. Russen möchten für ihre normale Schriftsprache keine Unicode-Tastatur
> benutzen müssen.
Zeigst du mir ein ECMAScript-Irgendwas, was statt Latin1 bei der
Funktion escape() KOI8-R nutzt?
>> Also bleibt dem EcmaScript interpreter nichts anderes
>> übrig, als sie anders zu speichern.
> Das ist ebenfalls fhcsal. Es gibt keinen "EcmaScript interpreter" (egal wie
> man das schreibt. Konkret werden wird syntaktisch korreter Quelltext von
> ECMAScript-Implementationen wie JavaScript und JScript zu Bytecode
> *compiliert* und *dieser Bytecode* dann von einer Virtuellen Maschine
Ausser im IE oder anderen alten Browsern.
>> Daher kommst du zu den %u0430 Unicodezeichen, welche der E-Mail client
>> (welcher eigentlich?) nicht unterstützt.
> Und nochmal mit beiden Händen voll ins Klo gegriffen. Der E-Mail-Client
> unterstützt "Unicodezeichen" sehr wahrscheinlich; sie müssen nur im URI
> richtig codiert werden, nämlich äquivalent `%04%30', so wie es
> encodeURIComponent() macht und in RFC3986 definiert ist. `%u0430' ist
> hingegen kein "Unicodezeichen" (egal wie man es schreibt).
=> Der E-Mail-Client unterstützt das %u0430 in dieser Form nicht.
Du solltest deinen Beißreflex mal gegen Lesekompetenz tauschen.
--
Mit freundlichen Grüßen
Holger Jeromin
John
danke für die reichlichen Antworten. Insbesondere PointedEars
Engagement dabei. Was mich erschreckt ist der Ton, der dabei von dir
(PointedEars) angeschlagen wurde. Anscheinend bist du Experte und
versucht auch irgendetwas mitzuteilen, was man deiner Meinung nach
doch längst hätte wissen sollen.
Dein Gegenüber (in diesem Fall ich) kenne mich auch nach ausführlichen
Studieren unterschiedlichster Quellen bzgl. UTF, Kyrillisch u.ä. nach
wie vor nur bedingt in diesem Segment aus. Und genau hier sehe ich den
großen Nutzen dieser Gruppen und wenn ich andere Topics anschaue, dann
ist dieses Thema ganz und garnicht trivial.
Und ja, ich habe mir die Mühe gemacht, einmal in einer deutschen und
einmal in einer englischen Gruppe diese Frage zu posten, da nicht
jeder in beiden Sprachen zu Hause ist. Das ist schon ok
Nichtsdestotrotz funktioniert es nach wie vor nicht. D.h. deine
Ausführugnen haben nicht zur einer Lösung geführt, bzw. mir nicht
weitergeholfen.
Der client, den ich verwende ist Outlook Express.
Nutze ich encodeURIComponent() ändert sich die Encodierung zwar und
die UTF Cods (%u1223) werden in andere Symbole umgewandelt, doch die
Darstellung ist nach wie vor nicht Kyrillisch.
D.h. so recht bin ich nicht weitergekommen mit diesem Problem und wäre
über weitere (echte) Hilfe sehr dankbar.
On 29 Okt., 13:54, Thomas 'PointedEars' Lahn <PointedE...@web.de>
wrote:
> Chris Seidel wrote:
Thomas 'PointedEars' Lahn
> Thomas 'PointedEars' Lahn schrieb am 29.10.2009 13:51:
>> Holger Jeromin wrote:
>>> escape basiert auf latin1, wo es keine Entsprechung für kyrillisch
>>> Zeichen gibt.
>> Das ist falchs. Das proprietäre escape() basiert zunächst einmal
>> lediglich auf 8-Bit-Zeichencodierungen und damit implementierbaren
>> Zeichensätzen;
>> davon ist ISO-8859-1 (Latin-1) einer. Aber auch für Kyrillisch gibt es
>> natürlich (mindenstens) eine(n), darunter KOI8-R und ISO-8859-5, denn
>> auch z.B. Russen möchten für ihre normale Schriftsprache keine
>> Unicode-Tastatur benutzen müssen.
>
> Zeigst du mir ein ECMAScript-Irgendwas, was statt Latin1 bei der
> Funktion escape() KOI8-R nutzt?
Dazu müsste ich bei Russisch-Inkasso anrufen, und das willst Du nicht
wirklich.
> >>> Also bleibt dem EcmaScript interpreter nichts anderes
>>> übrig, als sie anders zu speichern.
>> Das ist ebenfalls fhcsal. Es gibt keinen "EcmaScript interpreter" (egal
>> wie
>> man das schreibt. Konkret werden wird syntaktisch korreter Quelltext von
>> ECMAScript-Implementationen wie JavaScript und JScript zu Bytecode
>> *compiliert* und *dieser Bytecode* dann von einer Virtuellen Maschine
>
> Ausser im IE oder anderen alten Browsern.
Das ist schon deswegen Unfug, weil die von IE unterstützte ECMAScript-
Implementation Microsoft JScript ist.
>>> Daher kommst du zu den %u0430 Unicodezeichen, welche der E-Mail client
>>> (welcher eigentlich?) nicht unterstützt.
>> Und nochmal mit beiden Händen voll ins Klo gegriffen. Der E-Mail-Client
>> unterstützt "Unicodezeichen" sehr wahrscheinlich; sie müssen nur im URI
>> richtig codiert werden, nämlich äquivalent `%04%30', so wie es
>> encodeURIComponent() macht und in RFC3986 definiert ist. `%u0430' ist
>> hingegen kein "Unicodezeichen" (egal wie man es schreibt).
>
> => Der E-Mail-Client unterstützt das %u0430 in dieser Form nicht.
Nein, er unterstützt es, deshalb erscheint es ja in der Betreffzeile.
> Du solltest deinen Beißreflex mal gegen Lesekompetenz tauschen.
Du solltest Dein Geschwafel gegen den Hauch der Spur einer Ahnung tauschen.
PointedEars
Holger Jeromin
> Holger Jeromin wrote:
>> Thomas 'PointedEars' Lahn schrieb am 29.10.2009 13:51:
>>> Holger Jeromin wrote:
>>>>> Also bleibt dem EcmaScript interpreter nichts anderes
>>>> übrig, als sie anders zu speichern.
>>> Das ist ebenfalls fhcsal. Es gibt keinen "EcmaScript interpreter" (egal
>>> wie
>>> man das schreibt. Konkret werden wird syntaktisch korreter Quelltext von
>>> ECMAScript-Implementationen wie JavaScript und JScript zu Bytecode
>>> *compiliert* und *dieser Bytecode* dann von einer Virtuellen Maschine
>> Ausser im IE oder anderen alten Browsern.
> Das ist schon deswegen Unfug, weil die von IE unterstützte ECMAScript-
> Implementation Microsoft JScript ist.
*compiliert* denn Firefox 1.5 JavaScript zu Bytecode wie du behauptet hast?
Holger Jeromin
Korrektur: *compiliert* denn Firefox 1.5 syntaktisch korrekten Quelltext
Thomas 'PointedEars' Lahn
> Thomas 'PointedEars' Lahn schrieb am 29.10.2009 16:36:
>> Holger Jeromin wrote:
>>> Thomas 'PointedEars' Lahn schrieb am 29.10.2009 13:51:
>>>> Holger Jeromin wrote:
>>>>>> Also bleibt dem EcmaScript interpreter nichts anderes
>>>>> übrig, als sie anders zu speichern.
>>>> Das ist ebenfalls fhcsal. Es gibt keinen "EcmaScript interpreter"
>>>> (egal wie
>>>> man das schreibt. Konkret werden wird syntaktisch korreter Quelltext
>>>> von ECMAScript-Implementationen wie JavaScript und JScript zu Bytecode
>>>> *compiliert* und *dieser Bytecode* dann von einer Virtuellen Maschine
>>> Ausser im IE oder anderen alten Browsern.
>> Das ist schon deswegen Unfug, weil die von IE unterstützte ECMAScript-
>> Implementation Microsoft JScript ist.
>
> *compiliert* denn Firefox 1.5 JavaScript zu Bytecode wie du behauptet
> hast?
1. Nettes Ablenkungsmanöver.
2. Ja, bei JavaScript und auch JScript ist das schon immer so:
<http://groups.google.de/group/comp.infosystems.www.advocacy/msg/67a0d5add21cf5c1?hl=de&utoken=YVk2FT0AAADdRJqY_P0SuDfxNi4Z9xuSNmDnFDT8htZD6SsgK_cFq_nV2Q72OV4_Docr6d4-
fEzZL6ac0O_n5Dc6qV78cvqf>
| Client JavaScript reads source from SCRIPT tag contents, but compiles it
| into an internal bytecode for faster interpretation.
-- Brendan Eich (Erfinder und Maintainer von JavaScript), 1996
<http://blogs.msdn.com/ptorr/archive/2003/09/14/56184.aspx#56186>
| JScript [...] acts like a compiled language in the sense that before any
| JScript [...] program runs, we fully syntax check the code, generate a
| full parse tree, and generate a bytecode. We then run the bytecode through
| a bytecode interpreter. [d.h. eine Virtuelle Maschine; Anm. d. Red.]
-- Eric Lippert (hauptverantwortlich für JScript bei Microsoft seit 1996),
2003
3. Wie soll denn Bytecode anders entstehen ausser durch *Compilierung*?
PointedEars
Sam Kang
> Es funktioniert in allen (von mir ben�tigten) Sprachen (getestet ist
> f�r Deutsch, Englisch, Kroatisch, Tschechisch, Spanisch, Slowakisch)
> au�er in Kyrillisch.
Nein tut es nicht!
Die Parameter�bergabe im mailto: Protokoll l�uft Byteweise. Jetzt sendest du
W�rter die nicht durchs Protokoll laufen.
Au�erdem ist die Kodierung der Einstellung des Clienten gleich, also undefiniert.
Header sind nach den RFC immer ASCII, du m�chtest
http://www.faqs.org/rfcs/rfc2047.html
lesen. Das 'B' encoding geht einfach mit Base64. Den Encoder findest du hier:
http://www.webtoolkit.info/javascript-base64.html
Gas ganz ist nicht neu sondern schon seit 1996 so.
Damit dein Vorhaben das funktioniert musst du:
1.) Webseite auf UTF8 umstellen
2.) Den Header "Subject=" ASCII kodieren gem�ss RFC 2047
3.) Den Header "Content-Type" auf "text/plain; charset=utf-8" setzen
4.) den Body Parameter als Byteweises UTF-8 senden, den encoder findest du hier:
http://www.webtoolkit.info/javascript-utf8.html
5.) Alle drei Parameter mit encodeURIComponent() zusammenbauen.
Also
subject= '=?UTF-8?B?' + Base64.encode(subject) + '?='
mail = 'mailto:some...@example.com?Content-Type='
+ encodeURIComponent('text/plain; charset=utf-8')
+ '&Subject=' + encodeURIComponent(subject)
+ '&Body=' + encodeURIComponent(Utf8.encode(body))
ungetestet so mal schnell hingetippt.
Sam
--
Fortgeschrittene Inkompetenz ist nicht zu Unterscheiden von Boshaftigkeit.
(J. Porter Clark)
Thomas 'PointedEars' Lahn
> John schrieb:
>> Es funktioniert in allen (von mir benötigten) Sprachen (getestet ist
>> für Deutsch, Englisch, Kroatisch, Tschechisch, Spanisch, Slowakisch)
>> außer in Kyrillisch.
>
> Nein tut es nicht!
Stimmt. Die Gründe sind aber andere als die von Dir angeführten.
> Die Parameterübergabe im mailto: Protokoll läuft Byteweise. Jetzt sendest
> du Wörter die nicht durchs Protokoll laufen.
Soifz. [psf 10.1] Wie schon geschrieben: Fhalcs. "%uXXXX" hat bloss in
`mailto:' URIs keine spezielle Bedeutung, denn in RFC 2368 (der Bezug nimmt
auf RFC 3986) ist es anders definiert.
> Außerdem ist die Kodierung der Einstellung des Clienten gleich, also
> undefiniert.
Sie ist _nicht_ (niemals!) undefiniert (Default ist US-ASCII), sondern hat
möglicherweise ein ungeeignetes statisches Default (kein UTF), wodurch dann
*beim Absenden durch den Benutzer* die vorher vom MUA aus dem `mailto:' URI
decodierten Nicht-ASCII-Zeichen zerhackstückelt werden. Noch ein Grund,
weswegen `mailto:' böse[tm] ist.
> Header sind nach den RFC immer ASCII,
Ja, spielt für `mailto:' aber keine Rolle.
> du möchtest
>
> http://www.faqs.org/rfcs/rfc2047.html
>
> lesen.
RFC 2047 spielt hier gar keine Rolle, denn man muss dem MUA nicht per
`mailto:' sagen, wie er Nicht-ASCII-Zeichen im Header zu codieren hat (es
ist ein URI, und da ist per RFC 3986 klar, wie die Prozent-Codierung zu
interpretieren ist). Das muss man ja bei manueller Eingabe auch nicht.
mailto:' implementiert aber nichts anderes als das; d.h. ein `mailto:' URI
weist lediglich den MUA (sofern vorhanden und im WUA konfiguriert) an, den
URI auszuwerten und die entsprechenden Eingabefelder im E-Mail-
Bearbeitsdialog vorzubelegen. (Falls das zu kompliziert war, hier nochmal
deutlich: Ein `mailto:' URI selbst löst _nicht_ das Versenden einer E-Mail
aus!)
> Damit dein Vorhaben das funktioniert musst du:
>
> 1.) Webseite auf UTF8 umstellen
Das erleichtert zwar die Sache, ist aber nicht zwingend nötig, weil das
(W3C-)DOM genau wie Edition-3-konforme ECMAScript-Implementationen intern
UTF-16LE verwendet (DOMString im W3C-DOM, String in ES3F).
> 2.) Den Header "Subject=" ASCII kodieren gemäss RFC 2047
Nein, sondern gemäss RFC 2368 und damit RFC 3986.
> 3.) Den Header "Content-Type" auf "text/plain; charset=utf-8" setzen
Das fällt für mich unter "Website auf UTF-8 umstellen". Oder meinst Du
etwas anderes?
> 4.) den Body Parameter als Byteweises UTF-8 senden [...]
Unfug. Entweder unterstützen sowohl der WUA als auch der MUA UTF-8 und
damit die in RFC3986 definierte Prozent-Codierung, oder eben nicht. Wenn
nicht, kann man allenfalls auf jegliche explizite Prozent-Codierung
verzichten (also weder escape() noch encodeURIComponent()), und hoffen, dass
das klappt (d.h. dass sich WUA und MUA schon richtig verständigen werden.)
Saubere Programmierung ist natürlich etwas anderes, und besser sollte dann
MUA ein Update erfahren statt dass man an den Symptomen herumdoktert.
> 5.) Alle drei Parameter mit encodeURIComponent() zusammenbauen.
Korrekt, wenn man die vorherigen Schritte weglässt.
> Also
>
> subject= '=?UTF-8?B?' + Base64.encode(subject) + '?='
Ein clientseitig eingebautes Objekt, welches mit `Base64' referenziert
werden könnte, gibt es nicht. Hier den URI-Teil mit Base64 zu codieren
hiesse zudem, dem MUA Base64 im Klartext vorzuwerfen (nebst
Zeichendeklaration im Klartext, den dieser dann wieder Base64 codiert,
wodurch beim Empfänger wieder Base64 im Klartext angekommt. Zwar lassen
sich so auch "verschlüsselte" E-Mail-Nachrichten versenden, die
Vorgehensweise erscheint mir aber für den Alltag wenig sinnvoll :)
Im übrigen unterstützen einige WUAs/MUAs den subject-Parameter in `mailto:'
URIs nicht.
PointedEars
Sam Kang
>> >> Header sind nach den RFC immer ASCII,
> >
> > Ja, spielt für `mailto:' aber keine Rolle.
Nicht für mailto: Die MUAs übernehmen diese Parameter einfach in die Mail als
Header. Die hvalue muss trotzdem ASCII sein.
>> >> 2.) Den Header "Subject=" ASCII kodieren gemäss RFC 2047
> >
> > Nein, sondern gemäss RFC 2368 und damit RFC 3986.
Ok ungenau, der hvalue (hier das Subjekt) ist nach RFC 2047 kodiert.
>> >> 3.) Den Header "Content-Type" auf "text/plain; charset=utf-8" setzen
> >
> > Das fällt für mich unter "Website auf UTF-8 umstellen". Oder meinst Du
> > etwas anderes?
"Content-Type" ist ein Header in der Mail der dem MUA sagt er soll UTF8 verwenden.
>> >> 4.) den Body Parameter als Byteweises UTF-8 senden [...]
> >
> > Unfug. Entweder unterstützen sowohl der WUA als auch der MUA UTF-8 und
> > damit die in RFC3986 definierte Prozent-Codierung, oder eben nicht. Wenn
> > nicht, kann man allenfalls auf jegliche explizite Prozent-Codierung
> > verzichten (also weder escape() noch encodeURIComponent()), und hoffen, dass
> > das klappt (d.h. dass sich WUA und MUA schon richtig verständigen werden.)
> > Saubere Programmierung ist natürlich etwas anderes, und besser sollte dann
> > MUA ein Update erfahren statt dass man an den Symptomen herumdoktert.
Hat nichts miteinander zu tun. Das eine ist eine mailto: URL das andere eine
Mail nach RFC2045.
>> >> subject= '=?UTF-8?B?' + Base64.encode(subject) + '?='
> >
> > Ein clientseitig eingebautes Objekt, welches mit `Base64' referenziert
> > werden könnte, gibt es nicht. Hier den URI-Teil mit Base64 zu codieren
> > hiesse zudem, dem MUA Base64 im Klartext vorzuwerfen (nebst
> > Zeichendeklaration im Klartext, den dieser dann wieder Base64 codiert,
> > wodurch beim Empfänger wieder Base64 im Klartext angekommt. Zwar lassen
> > sich so auch "verschlüsselte" E-Mail-Nachrichten versenden, die
> > Vorgehensweise erscheint mir aber für den Alltag wenig sinnvoll :)
Quatsch, das ist ein Parameter Namens Subject der an die mailto URL angefügt
wird. Die Interpretation des Subjektes in Base64 ist Sache des MUAs.
subject= '=?UTF-8?B?' + Base64.encode(subject) + '?=';
'&Subject=' + encodeURIComponent(subject);
ist ein Parameter nach RFC2368 der RFC2047 mässig kodiert ist.
> > Im übrigen unterstützen einige WUAs/MUAs den subject-Parameter in `mailto:'
> > URIs nicht.
Das ist so nicht richtig. Die MUAs brauchen das auch nicht. Alle Parameter bis
auf den Body werden als "Parameter: Wert(\r)\n" in den Mailtext geschrieben.
Aus &Subject=blabulber wird dann "Subject: blabulber\n" im Mailtest.
Wenn ich also das Subjekt nach RFC 2047 'B' kodiere wird es auch als solches
eingebaut. Wenn nicht sind es Schrottteile die die RFC2368 nicht kennen oder
ignorieren. Selbst M$ kriegt das hin.
Thomas 'PointedEars' Lahn
> Thomas 'PointedEars' Lahn schrieb:
> >> >> Header sind nach den RFC immer ASCII,
> > >
> > > Ja, spielt für `mailto:' aber keine Rolle.
>
> Nicht für mailto: Die MUAs übernehmen diese Parameter einfach in die Mail
> als Header. Die hvalue muss trotzdem ASCII sein.
Ja, die codierten Zeichen; das erledigt encodeURIComponent() bereits.
> >> >> 2.) Den Header "Subject=" ASCII kodieren gemäss RFC 2047
> > >
> > > Nein, sondern gemäss RFC 2368 und damit RFC 3986.
>
> Ok ungenau, der hvalue (hier das Subjekt) ist nach RFC 2047 kodiert.
Das ist er nicht notwendigerweise.
> >> >> 3.) Den Header "Content-Type" auf "text/plain; charset=utf-8"
> >> >> setzen
> > >
> > > Das fällt für mich unter "Website auf UTF-8 umstellen". Oder meinst
> > > Du etwas anderes?
>
> "Content-Type" ist ein Header in der Mail der dem MUA sagt er soll UTF8
> verwenden.
Nein, sondern `Content-Type' ist der Header in der E-Mail, mit dem der
sendende MUA deklarieren kann, dass die Nutzdaten (Message Body)
entsprechend codiert sind. Dieser Header wird vom MUA *beim Senden* gesetzt
und der Headerwert kann vom Benutzer eingestellt werden. Ob er auch
kompatibel per `mailto:'-URI vorgegeben werden kann (so wie es RFC 2368
nahelegt), wäre noch zu zeigen.
> >> >> 4.) den Body Parameter als Byteweises UTF-8 senden [...]
> > >
> > > Unfug. Entweder unterstützen sowohl der WUA als auch der MUA UTF-8
> > > und
> > > damit die in RFC3986 definierte Prozent-Codierung, oder eben nicht.
> > > Wenn nicht, kann man allenfalls auf jegliche explizite
> > > Prozent-Codierung verzichten (also weder escape() noch
> > > encodeURIComponent()), und hoffen, dass das klappt (d.h. dass sich
> > > WUA und MUA schon richtig verständigen werden.) Saubere
> > > Programmierung ist natürlich etwas anderes, und besser sollte dann
> > > MUA ein Update erfahren statt dass man an den Symptomen herumdoktert.
>
> Hat nichts miteinander zu tun. Das eine ist eine mailto: URL das andere
> eine Mail nach RFC2045.
Genau deswegen muss auch keine Codierung im `mailto:' URI angegeben werden.
Du hast behauptet, es müsste, was nachweislich fhcsal ist.
> >> >> subject= '=?UTF-8?B?' + Base64.encode(subject) + '?='
> > >
> > > Ein clientseitig eingebautes Objekt, welches mit `Base64'
> > > referenziert
> > > werden könnte, gibt es nicht. Hier den URI-Teil mit Base64 zu
> > > codieren hiesse zudem, dem MUA Base64 im Klartext vorzuwerfen (nebst
> > > Zeichendeklaration im Klartext, den dieser dann wieder Base64
> > > codiert,
> > > wodurch beim Empfänger wieder Base64 im Klartext angekommt. Zwar
> > > lassen sich so auch "verschlüsselte" E-Mail-Nachrichten versenden,
> > > die
> > > Vorgehensweise erscheint mir aber für den Alltag wenig sinnvoll :)
>
> Quatsch, das ist ein Parameter Namens Subject der an die mailto URL
> angefügt wird.
>
> Die Interpretation des Subjektes in Base64 ist Sache des MUAs.
Eben.
> subject= '=?UTF-8?B?' + Base64.encode(subject) + '?=';
> '&Subject=' + encodeURIComponent(subject);
>
> ist ein Parameter nach RFC2368 der RFC2047 mässig kodiert ist.
Nein, Du missverstehst den RFC.
> > > Im übrigen unterstützen einige WUAs/MUAs den subject-Parameter in
> > > `mailto:' URIs nicht.
>
> Das ist so nicht richtig.
Doch, ist es.
> Die MUAs brauchen das auch nicht.
Hat auch niemand behauptet. Nur die E-Mail hat dann mitunter keinen
vordefinierten Betreff, d.h. die Verwendung des Parameters führt zu
inkonsistentem Verhalten. Darauf war hinzuweisen.
> Alle Parameter bis auf den Body werden als "Parameter: Wert(\r)\n" in den
> Mailtext geschrieben.
Sofern der WUA/MUA das unterstützt. Die Unterstützung von vordefiniertem
Message Body ist noch schlechter als die von vordefiniertem Subject-Header
und anderen Headern.
> Aus &Subject=blabulber wird dann "Subject: blabulber\n" im Mailtest.
Wobei "Mailtext" natürlich den Message Header und nicht den Message Body
meint. Das ist klar (wobei der Trenner nicht \n, sondern \r\n ist), hier
aber irrelevant.
> Wenn ich also das Subjekt nach RFC 2047 'B' kodiere wird es auch als
> solches eingebaut. Wenn nicht sind es Schrottteile die die RFC2368 nicht
> kennen oder ignorieren.
Nein, bis zum Beweis des Gegenteils interpretierst Du den RFC falsch. Von
"permitted" bis "MUST" ist es ein sehr weiter Weg. Und von da bis zur
konformen Implementation und Kompatibilität fast noch weiter.
> Selbst M$ kriegt das hin.
Werde ich morgen auch nochmal mit Outlook 2003 testen. Iceweasel (Firefox)
3.5.3 in Kombination mit Icedove (Thunderbird) 2.0.22 unterstützt es
jedenfalls für das Subject mit Quoted-Printable-Codierung; er unterstützt es
aber auch ohne, d.h.
window.location = "mailto:foo@example?subject=" +
encodeURIComponent("\u0431");
generiert ebenso eine Vorlage für eine E-Mail an foo@example mit Betreff
б
(U+0431, CYRILLIC SMALL LETTER BE) wie es
window.location = "mailto:foo@example?subject="
+ encodeURIComponent(
"=?UTF8?Q?"
+ encodeURIComponent("\u0431").replace(/%/g, "=")
+ "?=");
tut. (An dem Beispiel kann man übrigens auch sehen, dass QP deutlich
geeigneter als Base64 für Subject-Header ist).
PointedEars
Sam Kang
> Werde ich morgen auch nochmal mit Outlook 2003 testen. Iceweasel (Firefox)
> 3.5.3 in Kombination mit Icedove (Thunderbird) 2.0.22 unterstützt es
> jedenfalls für das Subject mit Quoted-Printable-Codierung; er unterstützt es
> aber auch ohne, d.h.
>
> window.location = "mailto:foo@example?subject=" +
> encodeURIComponent("\u0431");
>
window.location = "mailto:foo@example?subject=" +
encodeURIComponent("test =?UTF-8?B?Y2Ev0IvQuNGA0LjQu9C40YbQsA==?=");
funktioniert auch, wobei dein Trick mit 'Q' encoding und ersetzen des '%'
eleganter ist.
Ich wolle die MUAs zwingen UTF-8 zu nutzen was natürlich Wunschdenken ist.
Ich hoffe nur das der OP sich über diese Komplexität bewusst wird und lieber
einen Formmailer einsetzt.