javascript, window.open, mailto und kyrillische Texte

Holger Jeromin schrieb am 29.10.2009 16:50:

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?

Korrektur: *compiliert* denn Firefox 1.5 syntaktisch korrekten Quelltext
zu Bytecode wie du behauptet hast?

--
Mit freundlichen Grüßen
Holger Jeromin

Holger Jeromin wrote:

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_P0S uDfxNi4Z9xuSNmDnFDT8htZD6SsgK_cFq_nV2Q72OV4_Docr6d 4-
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

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!

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:somebody (AT) example (DOT) 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)

Sam Kang wrote:

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

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.

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 Microsoft kriegt das hin.


Sam

-- Fortgeschrittene Inkompetenz ist nicht zu Unterscheiden von Boshaftigkeit.
(J. Porter Clark)

Sam Kang wrote:

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 Microsoft 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

Thomas 'PointedEars' Lahn schrieb:

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.

Sam


--
Fortgeschrittene Inkompetenz ist nicht zu Unterscheiden von Boshaftigkeit.
(J. Porter Clark)