Zeichensatz-Chaos bei MIME-Type text/html

Michael Landenberger

unread,

Jun 20, 2012, 5:58:58 PM6/20/12

to

Hallo,

angenommen, eine Mail enthalte mehrere Alternative-Parts
(multipart/alternative), davon sei einer vom Typ text/html. Wie geht ein
RFC-gemäß arbeitender Mailclient mit folgenden Situationen um:

1. Der Content-Type-Header des text/html-Parts enthalte eine
Zeichensatzdeklaration (charset=xxxx). Ist diese zu berücksichtigen und
der Part entsprechend zu decodieren? Oder kann das Decodieren
unterbleiben, weil HTML-Content in der Regel eine eigene
Zeichensatzdeklaration (<meta http-equiv="Content-Type"
content="text/html; charset=xxxx">) enthält?

2. Der Content-Type-Header des text/html-Parts enthalte eine
Zeichensatzdeklaration (charset=xxxx). Diese weicht jedoch von der
Zeichensatzdeklaration im entsprechenden Meta-Tag des HTML-Contents ab.
Wie muss ein Mailclient damit umgehen?

3. Der Content-Type-Header des text/html-Parts enthält eine
Zeichensatzdeklaration (charset=xxxx), der HTML-Content jedoch keine.
Was ist zu tun, wenn eine Decodierung gemäß Zeichensatzdeklaration durch
den Mailclient dazu führt, dass der decodierte HTML-Quelltext Umlaute
und Sonderzeichen enthält (anstelle von ä etc.)? Schließlich muss
man damit rechnen, dass solche Zeichen im HTML-Quelltext in einem
HTML-fähigen Anzeigefenster nicht korrekt angezeigt werden.

Gruß

Michael

Andreas Prilop

unread,

Jun 21, 2012, 1:39:26 PM6/21/12

to

On Wed, 20 Jun 2012, Michael Landenberger wrote:

> angenommen, eine Mail enthalte mehrere Alternative-Parts
> (multipart/alternative), davon sei einer vom Typ text/html.
>

> 1. Der Content-Type-Header des text/html-Parts enthalte eine
> Zeichensatzdeklaration (charset=xxxx). Ist diese zu berücksichtigen
> und der Part entsprechend zu decodieren?
>

> 2. Der Content-Type-Header des text/html-Parts enthalte eine
> Zeichensatzdeklaration (charset=xxxx). Diese weicht jedoch von der
> Zeichensatzdeklaration im entsprechenden Meta-Tag des HTML-Contents ab.
>

> 3. Der Content-Type-Header des text/html-Parts enthält eine
> Zeichensatzdeklaration (charset=xxxx), der HTML-Content jedoch keine.

Deine Frage hat eigentlich nichts mit “mailreader” zu tun,
sondern gilt für HTML-Dokumente auf Webservern genauso.

Die Codierung (charset-Paramter) wird im “richtigen” Header
angegeben. Ist diese tatsächlich vorhanden, dann ist jedwede
META-Angabe im Body irrelevant und vom Browser zu ignorieren.
Browser ignorieren sie auch tatsächlich, was Du selbst auf
Deinem Server testen magst.

Als Spezialität des Internet Explorer gilt, dass für diesen
ein BOM (Byte Order Mark) absolute Priorität noch vor dem
HTTP-Header hat.

--
Solange Tölpel wie Hauke ‘?’ Reddmann durchs Usenet stolpern‚
ist kein Umlaut sicher.

Michael Landenberger

unread,

Jun 29, 2012, 7:55:21 PM6/29/12

to

Am 21.06.2012 19:39, schrieb Andreas Prilop:

> Deine Frage hat eigentlich nichts mit “mailreader” zu tun,
> sondern gilt für HTML-Dokumente auf Webservern genauso.

In diesem Fall betrifft sie aber einen (selbstprogrammierten) Mailclient.

> Die Codierung (charset-Paramter) wird im “richtigen” Header
> angegeben. Ist diese tatsächlich vorhanden, dann ist jedwede
> META-Angabe im Body irrelevant und vom Browser zu ignorieren.

Ich habe besagten Mailclient jetzt genau so programmiert, worauf er die
meisten HTML-Mails korrekt anzeigt. Probleme hat er jedoch mit der
HTML-Darstellung einer Mail mit folgendem Inhalt (nur relevante Zeilen
zitiert):

------------ Attachment-Header ------------
Content-Type: text/html;charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
--------- Ende Attachment-Header ----------

---------- HTML-Attachment-Body -----------
(...)
<head>
<title>eBay Research</title>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dutf-8">
(...)
</head>
<body>
Klicken Sie auf die Schaltfl=E4che „An Umfrage teilnehmen“, um =
uns Ihre Meinung zum Verkaufen bei eBay mitzuteilen, oder f=FCgen Sie den f=
olgenden Link in die Adresszeile Ihres Webbrowsers ein:
(...)
</body>
(...)
------- Ende HTML-Attachment-Body ---------

Wie man sieht, wird im Content-Type-Header des text/html-Attachments der
Zeichensatz ISO 8859-1 und quoted-printable-Encoding deklariert. Lt.
deiner Antwort ist gesamte HTML-Part dementsprechend zu decodieren und
das Meta-Tag im HTML-Quelltext zu ignorieren. Wird diese Anweisung auf
den HTML-Part angewandt, werden folgende quoted-printable-codierte Zeilen...

----------
| Klicken Sie auf die Schaltfl=E4che „An Umfrage
| teilnehmen“, um uns Ihre Meinung zum Verkaufen bei eBay
| mitzuteilen, oder f=FCgen Sie den folgenden Link in die Adresszeile
| Ihres Webbrowsers ein:
----------

...in diesen Text umgewandelt:

----------
| Klicken Sie auf die Schaltfläche „An Umfrage
| teilnehmen“, um uns Ihre Meinung zum Verkaufen bei eBay
| mitzuteilen, oder fügen Sie den folgenden Link in die Adresszeile
| Ihres Webbrowsers ein:
----------

Das sieht zunächst plausibel aus, ist es aber nicht. Grund: im Meta-Tag
des HTML-Codes wird als HTML-Zeichensatz UTF-8 deklariert (siehe
"HTML-Attachment-Body"). Der HTML-Renderer richtet sich danach und
versucht, den (bereits quoted-printable-decodierten) HTML-Quelltext mit
UTF-8 zu decodieren. Das geht bei den im Quelltext vorhandenen Umlauten
"ä" und "ü" prompt schief, denn diese Umlaute sind nach der
quoted-printable-Decodierung nicht mehr korrekt UTF-8-codiert. Bei einer
korrekten UTF-8-Codierung müsste statt "ä" ein "Ã¤" und statt "ü" ein
"Ã¼" im Quelltext stehen.

Mein Mailclient, der sich stur an die Zeichensatzdeklaration im Header
hält und die Deklaration im Meta-Tag des HTML-Contents ignoriert,
liefert eine falsche Darstellung. Thunderbird und Outlook stellen die
Mail jedoch trotz der widersprüchlichen Deklaration korrekt dar. Wie
machen die das?

Gruß

Michael

Peter J. Holzer

unread,

Jun 30, 2012, 5:53:57 AM6/30/12

to

Doch, ist es.

> Grund: im Meta-Tag des HTML-Codes wird als HTML-Zeichensatz UTF-8
> deklariert (siehe "HTML-Attachment-Body").

Wie Du oben schon geschrieben hast:

> deiner Antwort ist gesamte HTML-Part dementsprechend zu decodieren und
> das Meta-Tag im HTML-Quelltext zu ignorieren.

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

> Der HTML-Renderer richtet sich danach und versucht, den (bereits
> quoted-printable-decodierten) HTML-Quelltext mit UTF-8 zu decodieren.

Das darf er eben nicht, denn "das Meta-Tag im HTML-Quelltext [ist] zu
ignorieren".

Wenn im Content-Type-Header ein charset-Parameter vorhanden ist, hat
dieser Vorrang vor einem eventuell vorhandenen META-Tag. Siehe
http://www.w3.org/TR/html401/charset.html#h-5.2.2 (das bezieht sich zwar
explizit auf HTTP, sollte aber auch für andere MIME-Messages gelten).

> Das geht bei den im Quelltext vorhandenen Umlauten "ä" und "ü" prompt
> schief, denn diese Umlaute sind nach der quoted-printable-Decodierung
> nicht mehr korrekt UTF-8-codiert.

Sie sind auch ver der quoted-printable-Decodierung nicht korrekt

UTF-8-codiert.

> Bei einer korrekten UTF-8-Codierung müsste statt "ä" ein "Ã¤" und
> statt "ü" ein "Ã¼" im Quelltext stehen.

Nur, wenn Du der Meinung bist, dass ISO-8859-1 die einzig wahre und
gottgegebene Kodierung ist. Es ist wenig sinnvoll, hier von Zeichen zu
reden. Richtig wäre die Formulierung:

Bei einer korrekten UTF-8-Codierung müssten statt 0xE4 die Bytes
0xC3 0xA4 und statt 0xFC die Bytes 0xC3 0xBC im Quelltext stehen.

Das Byte 0xC3 ist eben kein "Ã" sondern in UTF-8 ein Teil des Zeichens
"ä" bzw. "ü" (in CP 850 wäre 0xC3 ein Blockgrafikzeichen ("├") und in
EBCDIC wäre es ein "C")

> Mein Mailclient, der sich stur an die Zeichensatzdeklaration im Header
> hält und die Deklaration im Meta-Tag des HTML-Contents ignoriert,
> liefert eine falsche Darstellung.

Nein, das tut er offensichtlich nicht. Denn würde er sich an die
Zeichensatzdeklaration im Header halten dann würde er =E4 -> 0xE4 -> ä
dekodieren und daher richtig als ä darstellen. Du schreibst aber selbst,
dass er das nicht tut, sondern versucht 0xE4 entgegen der Deklaration im
Header als UTF-8 zu interpretieren, was natürlich nicht funktioniert.

> Thunderbird und Outlook stellen die Mail jedoch trotz der
> widersprüchlichen Deklaration korrekt dar. Wie machen die das?

Arno Welzel

unread,

Jun 30, 2012, 2:03:37 PM6/30/12

to

Michael Landenberger, 30.06.2012 01:55:

Dann ist er kaputt. Der Header hat Vorrang vor jeglicher META-Angabe im
Dokument.

> "ä" und "ü" prompt schief, denn diese Umlaute sind nach der
> quoted-printable-Decodierung nicht mehr korrekt UTF-8-codiert. Bei einer
> korrekten UTF-8-Codierung müsste statt "ä" ein "Ã¤" und statt "ü" ein
> "Ã¼" im Quelltext stehen.
>
> Mein Mailclient, der sich stur an die Zeichensatzdeklaration im Header
> hält und die Deklaration im Meta-Tag des HTML-Contents ignoriert,
> liefert eine falsche Darstellung. Thunderbird und Outlook stellen die

Woher weisst Du,d ass dein Mailclient die META-Angabe ignoriert?

> Mail jedoch trotz der widersprüchlichen Deklaration korrekt dar. Wie
> machen die das?

Indem sie standardkonform die META-Angabe ignorieren, weil ja bereits im
Content-Type die Angaben vorliegen.

--
Arno Welzel
http://arnowelzel.de
http://de-rec-fahrrad.de

Michael Landenberger

unread,

Jul 1, 2012, 5:19:52 AM7/1/12

to

Am 30.06.2012 11:53, schrieb Peter J. Holzer:

> Wie Du oben schon geschrieben hast:
>
>> deiner Antwort ist gesamte HTML-Part dementsprechend zu decodieren und
>> das Meta-Tag im HTML-Quelltext zu ignorieren.
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
>
>> Der HTML-Renderer richtet sich danach und versucht, den (bereits
>> quoted-printable-decodierten) HTML-Quelltext mit UTF-8 zu decodieren.
>
> Das darf er eben nicht, denn "das Meta-Tag im HTML-Quelltext [ist] zu
> ignorieren".

HTML-Renderer und Mailclient können 2 völlig verschiedene Programme
sein. Beispielsweise kann man den HTML-Content (der ja nichts weiter als
ein Anhang ist) aus dem Mailclient als .HTM-Datei exportieren und diese
dann in einem separaten Browser betrachten. Der Browser kennt den
Content-Type-Header überhaupt nicht, weil der ebenso wie bei beim Export
jedes anderen MIME-Types nicht mit exportiert wird. In diesem Fall ist
die Einhaltung der von dir genannten Vorschrift schlicht unmöglich.

Mir ist es auch außer bei den Mails eines einzigen Absenders (PayPal)
noch nie aufgefallen, dass eine vorschriftsmäßige Decodierung gemäß
Content-Type-Header (also unter Ignorierung des Content-Type-MetaTags im
HTML-Quelltext) zu ungültigen Zeichen wie z. B. uncodierten Umlauten
führt (uncodierte Umlaute haben in HTML-Quelltext eigentlich nichts zu
suchen, selbst dann nicht, wenn dieser gar keine eigene
Zeichensatzdeklaration enthält).

Irgendwas ist da faul. Ich vermute, dass PayPal Mist gebaut hat.
Allerdings bügeln Thunderbird und andere Mailclients diesen Mist
offenbar wieder aus. Ich wüsste jetzt gerne, wie sie das machen.

>> Bei einer korrekten UTF-8-Codierung müsste statt "ä" ein "Ã¤" und
>> statt "ü" ein "Ã¼" im Quelltext stehen.
>
> Nur, wenn Du der Meinung bist, dass ISO-8859-1 die einzig wahre und
> gottgegebene Kodierung ist. Es ist wenig sinnvoll, hier von Zeichen zu
> reden. Richtig wäre die Formulierung:
>
> Bei einer korrekten UTF-8-Codierung müssten statt 0xE4 die Bytes
> 0xC3 0xA4 und statt 0xFC die Bytes 0xC3 0xBC im Quelltext stehen.
>
> Das Byte 0xC3 ist eben kein "Ã" sondern in UTF-8 ein Teil des Zeichens
> "ä" bzw. "ü" (in CP 850 wäre 0xC3 ein Blockgrafikzeichen ("├") und in
> EBCDIC wäre es ein "C")

Danke für die Richtigstellung. Aber es wurde hoffentlich klar, was ich
gemeint habe. Die Umlaute stehen nach der Quoted-Printable-Decodierung
als uncodierte Zeichen im HTML-Quelltext. Das verstößt sowohl gegen die
Zeichensatzdeklaration im Meta-Tag (die zwar vom Mailclient selbst zu
ignorieren ist, nicht jedoch von externen Programmen, die vom
Content-Type-Header der Mail nichts wissen können) als auch gegen
HTML-Konventionen, nach denen Umlaute als "ä", "ü" usw. zu
notieren sind.

>> Thunderbird und Outlook stellen die Mail jedoch trotz der
>> widersprüchlichen Deklaration korrekt dar. Wie machen die das?
>
> Indem sie sich strikt an den Header halten und die Deklaration im
> Meta-Tag ignorieren.

Es mag ja sein, dass sich TB und Outlook daran halten. Aber das Ergebnis
der Einhaltung dieser Vorschrift ist HTML-Quelltext mit ungültigen
Zeichen. Diesen Quelltext korrekt darzustellen ist nur mit Tricks
möglich. Welche Tricks sind das? Wird beim Vorhandensein von uncodierten
Umlauten geraten, welches Zeichen bzw. welcher Zeichensatz da vorliegen
könnte?

Gruß

Michael

Michael Landenberger

unread,

Jul 1, 2012, 5:43:48 AM7/1/12

to

Am 30.06.2012 20:03, schrieb Arno Welzel:

> Michael Landenberger, 30.06.2012 01:55:

>> Das sieht zunächst plausibel aus, ist es aber nicht. Grund: im Meta-Tag
>> des HTML-Codes wird als HTML-Zeichensatz UTF-8 deklariert (siehe
>> "HTML-Attachment-Body"). Der HTML-Renderer richtet sich danach und
>> versucht, den (bereits quoted-printable-decodierten) HTML-Quelltext mit
>> UTF-8 zu decodieren. Das geht bei den im Quelltext vorhandenen Umlauten
>
> Dann ist er kaputt. Der Header hat Vorrang vor jeglicher META-Angabe im
> Dokument.

Siehe meine Antwort an Peter. Der Renderer muss nicht unbedingt
Bestandteil eines Mailclients sein. Man kann den HTML-Anhang einer Mail
auch als .HTM exportieren und dann in einem fremden Programm anzeigen
lassen. Dieses Fremdprogramm weiß nichts von einem Content-Type-Header
(weil der in der exportierten .HTM-Datei nicht enthalten ist) und
richtet sich daher nach der Zeichensatzdeklaration im Meta-Tag.

Wäre der HMTL-Content einer Mail ausschließlich zur Darstellung
derselben innerhalb des Mailclients gedacht, wäre eine
Zeichensatzdeklaration im Meta-Tag ja auch überflüssig, denn sie wird ja
sowieso ignoriert. Sie ist aber in der Regel trotzdem vorhanden. Warum?

>> Mein Mailclient, der sich stur an die Zeichensatzdeklaration im Header
>> hält und die Deklaration im Meta-Tag des HTML-Contents ignoriert,
>> liefert eine falsche Darstellung. Thunderbird und Outlook stellen die
>
> Woher weisst Du,d ass dein Mailclient die META-Angabe ignoriert?

Der Mailclient war zunächst so programmiert, dass er prüft, ob im
HTML-Content ein Content-Type-Meta-Tag enthalten ist. Wenn ja, hat er
dieses auf Übereinstimmung mit der Zeichensatzdeklaration im
Content-Type-Header überprüft. Bei Übereinstimmung hat der den
HTML-Content gar nicht decodiert, sondern dies dem HTML-Renderer (im
Moment ist das noch ein externer Browser) überlassen. Der wiederum hat
die Zeichensatzdeklaration im Meta-Tag ausgewertet und alles war gut.
Dieses Verhalten trat übrigens bei allen mir bisher untergekommenen
HTML-Mails in Kraft, mit nur einer einzigen Ausnahme. Grund: bei allen
Mails war im Content-Type-Header von text/html-Anhängen entweder gar
kein Zeichensatz deklariert oder dieser stimmte mit der Deklaration im
HTML-Meta-Tag überein. Einzige Ausnahme bilden bisher Mails von PayPal,
bei dem im Header des text/html-Anhangs ISO-8859-1 und quoted-printable
deklariert ist, im HTML-Meta-Tag jedoch UTF-8.

Nun habe ich den Client so umprogrammiert, dass er HTML-Content
grundsätzlich gemäß Content-Type-Header decodiert und dann den so
decodierten HTML-Quelltext 1:1 an den Renderer weiterreicht. Da der
Renderer aber nichts von der Zeichensatzdeklaration des
text/html-Anhangs weiß, bleibt ihm nichts anderes übrig, als sich nach
dem HTML-Meta-Tag zu richten. Aber auch das klappte bisher bei allen
Mails - mit Ausnahme der Paypal-Mails. Das sind die einzigen HTML-Mails,
die mir bisher untergekommen sind, bei denen sich Content-Type- und
Meta-Tag-Zeichensatzdeklaration unterscheiden.

>> Mail jedoch trotz der widersprüchlichen Deklaration korrekt dar. Wie
>> machen die das?
>
> Indem sie standardkonform die META-Angabe ignorieren, weil ja bereits im
> Content-Type die Angaben vorliegen.

Wie macht das ein Mailclient wie z. B. Outlook Express, der ja zum
Rendern von HTML den Internet Explorer (also einen externen Renderer)
verwendet? Gibt es eine Möglichkeit, dem Internet-Explorer-ActiveX zu
sagen, dass es die Zeichensatzdeklaration im Meta-Tag ignorieren soll?
Und wie schafft es ein HTML-Renderer (egal ob intern oder extern),
uncodierte Umlaute richtig darzustellen, obwohl uncodierte Umlaute in
HTML-Quelltext nicht zulässig sind?

Gruß

Michael

Thomas 'PointedEars' Lahn

unread,

Jul 1, 2012, 6:40:47 AM7/1/12

to

Michael Landenberger wrote:

> Am 30.06.2012 11:53, schrieb Peter J. Holzer:
>> Wie Du oben schon geschrieben hast:
>>> deiner Antwort ist gesamte HTML-Part dementsprechend zu decodieren und
>>> das Meta-Tag im HTML-Quelltext zu ignorieren.
>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>> Der HTML-Renderer richtet sich danach und versucht, den (bereits
>>> quoted-printable-decodierten) HTML-Quelltext mit UTF-8 zu decodieren.
>>
>> Das darf er eben nicht, denn "das Meta-Tag im HTML-Quelltext [ist] zu
>> ignorieren".
>
> HTML-Renderer und Mailclient können 2 völlig verschiedene Programme
> sein. Beispielsweise kann man den HTML-Content (der ja nichts weiter als
> ein Anhang ist) aus dem Mailclient als .HTM-Datei exportieren und diese
> dann in einem separaten Browser betrachten. Der Browser kennt den
> Content-Type-Header überhaupt nicht, weil der ebenso wie bei beim Export
> jedes anderen MIME-Types nicht mit exportiert wird. In diesem Fall ist
> die Einhaltung der von dir genannten Vorschrift schlicht unmöglich.

Nein, ist sie nicht. Die Vorschrift lautet *vollständig* "Das Meta-Element
zur Deklaration der Zeichencodierung ist zu ignorieren, *wenn* ein BOM oder
ein externes Protokoll etwas anderes definiert."

<http://www.w3.org/TR/REC-html40/charset.html#h-5.2.2>
<http://www.w3.org/TR/html5/the-meta-element.html#charset>

Das "externe Protokoll" ist in diesem Fall MIME (RFC 2045 bis 2049). Wenn
es *fehlt* (und auch der BOM fehlt oder nicht unterstützt wird), wenn also
z. B. das Attachment als Datei im Dateisystem gespeichert und von einem
externen Programm per file:// angezeigt wird, dann MUSS das Meta-Element
beachtet werden, aber es DARF *nur dann* beachtet werden. (Aus diesem Grund
halte ich es nach wie vor für sinnvoll, die Zeichendeklaration auch dann ins
HTML-Dokument zu schreiben, wenn der Header dasselbe definiert. YMMV.)

> Mir ist es auch außer bei den Mails eines einzigen Absenders (PayPal)
> noch nie aufgefallen, dass eine vorschriftsmäßige Decodierung gemäß
> Content-Type-Header (also unter Ignorierung des Content-Type-MetaTags im
> HTML-Quelltext) zu ungültigen Zeichen wie z. B. uncodierten Umlauten
> führt

Weshalb auch? Das war gar nicht das Problem, sondern der *Fehler*, dass bei
einer abweichenden Deklaration das Meta-Element Vorrang vor dem Header hat,
obwohl es umgekehrt sein sollte.

> (uncodierte Umlaute haben in HTML-Quelltext eigentlich nichts zu suchen,
> selbst dann nicht, wenn dieser gar keine eigene Zeichensatzdeklaration
> enthält).

Was sollen "uncodierte Umlaute" sein? Solltest Du damit "nicht per Referenz
maskierte Umlaute" meinen: Das ist fahcsal. Der Basiszeichensatz (Document
Character Set) von HTML ist der von UCS-2, quasi-äquivalent zu Unicode.
Wird eine geeignete Codierung verwendet, dürfen also selbstverständlich auch
nicht per Referenz (Zeichenreferenz oder Character Entity Reference)
maskierte Umlaute (und andere Nicht-ASCII-Zeichen) vorkommen:

<http://www.w3.org/TR/REC-html40/charset.html#h-5.1>

Meine (neuen) HTML-Dokumente codiere ich mit UTF-8, deklariere sie
entsprechend, und spare es mir, Umlaute und andere weithin kompatible und
per (angepasster) Tastatur leicht eingebbare Unicode-Zeichen jenseits U+007F
zu maskieren; somit auch, statt 2 Bytes für ein "ä" (C3 A4) gleich 6 Bytes
(immerhin das Dreifache, rechne das mal hoch) für ein "ä" (26 61 75 6D
6C 3B) zu verbraten und den Inhalt zudem schlechter wartbar zu machen.
ASCII war vorgestern.

> Irgendwas ist da faul.

Ja, und zwar Dein Verständnis von HTML und MIME.

> Ich vermute, dass PayPal Mist gebaut hat.

Das vermute ich auch.

> Allerdings bügeln Thunderbird und andere Mailclients diesen Mist
> offenbar wieder aus. Ich wüsste jetzt gerne, wie sie das machen.

Heuristik. Zum Beispiel können bestimmte Oktetts in Unicode-Codierungen
nicht alleinstehend vorkommen. Es liegt dann z. B. nahe, einen
fälschlicherweise als UTF-8-codiert deklarierten Text als ISO-8859-x-
codierten Text aufzufassen, in dem dieses Oktett alleinstehend vorkommen
kann; den Wert von x definiert dann üblicherweise eine Benutzereinstellung.
Für weiteres: UTSL.

>>> Bei einer korrekten UTF-8-Codierung müsste statt "ä" ein "Ã¤" und
>>> statt "ü" ein "Ã¼" im Quelltext stehen.
>>
>> Nur, wenn Du der Meinung bist, dass ISO-8859-1 die einzig wahre und
>> gottgegebene Kodierung ist. Es ist wenig sinnvoll, hier von Zeichen zu
>> reden. Richtig wäre die Formulierung:
>>
>> Bei einer korrekten UTF-8-Codierung müssten statt 0xE4 die Bytes
>> 0xC3 0xA4 und statt 0xFC die Bytes 0xC3 0xBC im Quelltext stehen.
>>
>> Das Byte 0xC3 ist eben kein "Ã" sondern in UTF-8 ein Teil des Zeichens
>> "ä" bzw. "ü" (in CP 850 wäre 0xC3 ein Blockgrafikzeichen ("├") und in
>> EBCDIC wäre es ein "C")
>
> Danke für die Richtigstellung. Aber es wurde hoffentlich klar, was ich
> gemeint habe. Die Umlaute stehen nach der Quoted-Printable-Decodierung
> als uncodierte Zeichen im HTML-Quelltext. Das verstößt sowohl gegen die
> Zeichensatzdeklaration im Meta-Tag (die zwar vom Mailclient selbst zu
> ignorieren ist, nicht jedoch von externen Programmen, die vom
> Content-Type-Header der Mail nichts wissen können) als auch gegen
> HTML-Konventionen, nach denen Umlaute als "ä", "ü" usw. zu
> notieren sind.

Das ist grober Unfug.

>>> Thunderbird und Outlook stellen die Mail jedoch trotz der
>>> widersprüchlichen Deklaration korrekt dar. Wie machen die das?
>>
>> Indem sie sich strikt an den Header halten und die Deklaration im
>> Meta-Tag ignorieren.
>
> Es mag ja sein, dass sich TB und Outlook daran halten. Aber das Ergebnis
> der Einhaltung dieser Vorschrift ist HTML-Quelltext mit ungültigen
> Zeichen.

Ja, das Problem liegt wieder einmal auf Layer 8.

> Diesen Quelltext korrekt darzustellen ist nur mit Tricks möglich.

Nein, es ist einfach die *Zeichen*-Codierung zu deklarieren, die auch
verwendet wurde, und zwar *vor* der *Transfer*-Codierung z. B. mit QP.

> Welche Tricks sind das? Wird beim Vorhandensein von uncodierten
> Umlauten geraten, welches Zeichen bzw. welcher Zeichensatz da vorliegen
> könnte?

Ex falso quodlibet.

PointedEars
--
DER [Browser] soll sich um sowas kuemmern, nicht die MARKUP language,
mit der nur sematische Informationen gegeben werden sollen, keine
Layoutbeschreibung (das galt zumindest, bevor Netscape und Microsoft
in Wettstreit traten, wer das Prinzip nachhaltiger vergewaltigen darf,
der eindeutig zugunsten von Microsoft ausging) -- BGKS

Thomas 'PointedEars' Lahn

unread,

Jul 1, 2012, 6:50:20 AM7/1/12

to

Michael Landenberger wrote:

> Am 30.06.2012 20:03, schrieb Arno Welzel:
>> Michael Landenberger, 30.06.2012 01:55:
>>> Das sieht zunächst plausibel aus, ist es aber nicht. Grund: im Meta-Tag
>>> des HTML-Codes wird als HTML-Zeichensatz UTF-8 deklariert (siehe
>>> "HTML-Attachment-Body"). Der HTML-Renderer richtet sich danach und
>>> versucht, den (bereits quoted-printable-decodierten) HTML-Quelltext mit
>>> UTF-8 zu decodieren. Das geht bei den im Quelltext vorhandenen Umlauten
>>
>> Dann ist er kaputt. Der Header hat Vorrang vor jeglicher META-Angabe im
>> Dokument.
>
> Siehe meine Antwort an Peter. Der Renderer muss nicht unbedingt

> Bestandteil eines Mailclients sein. [Fehlschluss]

Siehe andere Anwort. Dass der Header Vorrang hat, heisst _nicht_, dass
nichts mehr geht, wenn er fehlt, sondern es greift dann einfach der nächste
Fallback (BOM, META und wenn das alles nichts hilft, schliesslich Heuristik;
in dieser Reihenfolge).

X-Post & F'up2 <dciwam/>

PointedEars
--
Prototype.js was written by people who don't know javascript for people
who don't know javascript. People who don't know javascript are not
the best source of advice on designing systems that use javascript.
-- Richard Cornford, cljs, <f806at$ail$1$8300...@news.demon.co.uk>

Arno Welzel

unread,

Jul 1, 2012, 7:02:50 AM7/1/12

to

Michael Landenberger, 01.07.2012 11:43:

> Am 30.06.2012 20:03, schrieb Arno Welzel:
>
>> Michael Landenberger, 30.06.2012 01:55:
>
>>> Das sieht zunächst plausibel aus, ist es aber nicht. Grund: im Meta-Tag
>>> des HTML-Codes wird als HTML-Zeichensatz UTF-8 deklariert (siehe
>>> "HTML-Attachment-Body"). Der HTML-Renderer richtet sich danach und
>>> versucht, den (bereits quoted-printable-decodierten) HTML-Quelltext mit
>>> UTF-8 zu decodieren. Das geht bei den im Quelltext vorhandenen Umlauten
>>
>> Dann ist er kaputt. Der Header hat Vorrang vor jeglicher META-Angabe im
>> Dokument.
>
> Siehe meine Antwort an Peter. Der Renderer muss nicht unbedingt
> Bestandteil eines Mailclients sein. Man kann den HTML-Anhang einer Mail
> auch als .HTM exportieren und dann in einem fremden Programm anzeigen
> lassen. Dieses Fremdprogramm weiß nichts von einem Content-Type-Header
> (weil der in der exportierten .HTM-Datei nicht enthalten ist) und
> richtet sich daher nach der Zeichensatzdeklaration im Meta-Tag.

Dann ist die ganze Konstruktion kaputt. Wenn der Mail-Client anhand des
MIME-Headers weiss, dass das Dokument also ISO-8859-1 zu interpretieren
ist, sollte er die entsprechende META-Angabe beim Export löschen oder
korrigieren.

> Wäre der HMTL-Content einer Mail ausschließlich zur Darstellung
> derselben innerhalb des Mailclients gedacht, wäre eine
> Zeichensatzdeklaration im Meta-Tag ja auch überflüssig, denn sie wird ja
> sowieso ignoriert. Sie ist aber in der Regel trotzdem vorhanden. Warum?

Das musst Du den Absender fragen.

>>> Mein Mailclient, der sich stur an die Zeichensatzdeklaration im Header
>>> hält und die Deklaration im Meta-Tag des HTML-Contents ignoriert,
>>> liefert eine falsche Darstellung. Thunderbird und Outlook stellen die
>>
>> Woher weisst Du,d ass dein Mailclient die META-Angabe ignoriert?
>

[...]

> Nun habe ich den Client so umprogrammiert, dass er HTML-Content
> grundsätzlich gemäß Content-Type-Header decodiert und dann den so
> decodierten HTML-Quelltext 1:1 an den Renderer weiterreicht. Da der

Ach so - Du hast ihn selbst gebaut.

[Thunderbird richtet sich nur nach dem MIME-Header]

>>> Mail jedoch trotz der widersprüchlichen Deklaration korrekt dar. Wie
>>> machen die das?
>>
>> Indem sie standardkonform die META-Angabe ignorieren, weil ja bereits im
>> Content-Type die Angaben vorliegen.
>
> Wie macht das ein Mailclient wie z. B. Outlook Express, der ja zum
> Rendern von HTML den Internet Explorer (also einen externen Renderer)
> verwendet? Gibt es eine Möglichkeit, dem Internet-Explorer-ActiveX zu
> sagen, dass es die Zeichensatzdeklaration im Meta-Tag ignorieren soll?

Das wäre technisch vermutlich machbar. Ob Outlook Express das tut, weiss
ich aber nicht. Es kann auch sein, dass der IE mit merkt, dass die
verwendeten Zeichen nicht zu UTF-8 passen und dann trotzdem richtig
darstellt.

> Und wie schafft es ein HTML-Renderer (egal ob intern oder extern),
> uncodierte Umlaute richtig darzustellen, obwohl uncodierte Umlaute in
> HTML-Quelltext nicht zulässig sind?

Wenn Du damit meinst, dass man z.B. "ä" statt "ä" schreibt - das
ist sehr wohl zulässig. Genau dafür gibt es ja die entsprechenden
Angaben im MIME- oder HTTP-Header bzw. im META-Element, damit der Client
weiss, wie er diese Zeichen darzustellen hat.

Thomas 'PointedEars' Lahn

unread,

Jul 1, 2012, 7:04:46 AM7/1/12

to

Michael Landenberger wrote:

> Nun habe ich den Client so umprogrammiert, dass er HTML-Content
> grundsätzlich gemäß Content-Type-Header decodiert und dann den so
> decodierten HTML-Quelltext 1:1 an den Renderer weiterreicht. Da der
> Renderer aber nichts von der Zeichensatzdeklaration des
> text/html-Anhangs weiß, bleibt ihm nichts anderes übrig, als sich nach
> dem HTML-Meta-Tag zu richten. Aber auch das klappte bisher bei allen
> Mails - mit Ausnahme der Paypal-Mails. Das sind die einzigen HTML-Mails,
> die mir bisher untergekommen sind, bei denen sich Content-Type- und
> Meta-Tag-Zeichensatzdeklaration unterscheiden.

Dein Mailclient kümmert sich in dem Fall um Dinge, die ihn nicht zu
interessieren haben. Er hat die *Transfer*codierung (Headerfeld `Content-
Transfer-Encoding') zu decodieren (z. B. Quoted-Printable) und dann das
Ergebnis an die Layout-Engine weiterzureichen.

>>> Mail jedoch trotz der widersprüchlichen Deklaration korrekt dar. Wie
>>> machen die das?
>>
>> Indem sie standardkonform die META-Angabe ignorieren, weil ja bereits im
>> Content-Type die Angaben vorliegen.
>
> Wie macht das ein Mailclient wie z. B. Outlook Express, der ja zum
> Rendern von HTML den Internet Explorer (also einen externen Renderer)
> verwendet? Gibt es eine Möglichkeit, dem Internet-Explorer-ActiveX zu
> sagen, dass es die Zeichensatzdeklaration im Meta-Tag ignorieren soll?

Keine Ahnung, ist IMHO auch in beiden Gruppen, in die gecrosspostet wurde,
off-topic.

Vermutung: Es werden die META-Elemente analysiert und ggf. die Deklarationen
dort durch Angaben aus dem `Content-Type'-Headerfeld des entsprechenden
Teils der Multipart-Nachricht ersetzt oder um sie ergänzt. Noch einfacher
wäre das Voranstellen eines BOM, aber das muss die Layout-Engine dann auch
unterstützen.

UTSL.

> Und wie schafft es ein HTML-Renderer (egal ob intern oder extern),
> uncodierte Umlaute richtig darzustellen,

Es gibt keine "uncodierten Umlaute". Jedes Zeichen in einem Text liegt in
einer bestimmten Codierung vor, und sei es auch nur US-ASCII.

> obwohl [unmaskierte] Umlaute in HTML-Quelltext nicht zulässig sind?

Siehe andere Antwort. Sie sind zulässig.

X-Post & F'up2 <dciwam/>

PointedEars
--

> In [einem Popup] soll sich ein Link befinden, der im Hauptfenster
> ausgeführt werden soll. Habt ihr ne Ahnung, wie man das anstellt?
Links werden niemals ausgeführt, denn es sind keine Hunde, mit denen man
Gassi geht. (Georg Maaß in dcljs <aop009$ooab4$1...@ID-3551.news.dfncis.de>)

Michael Landenberger

unread,

Jul 1, 2012, 11:07:31 AM7/1/12

to

Am 01.07.2012 13:02, schrieb Arno Welzel:

> Dann ist die ganze Konstruktion kaputt. Wenn der Mail-Client anhand des
> MIME-Headers weiss, dass das Dokument also ISO-8859-1 zu interpretieren
> ist, sollte er die entsprechende META-Angabe beim Export löschen oder
> korrigieren.

Einen Mailclient, der den Inhalt einer angehängten Datei beim Export
verändert, halte ich für noch kaputter. Das gilt insbesondere dann, wenn
dieses Verhalten den Fehler eines anderen, mutmaßlich tatsächlich
kaputten Mailclients (nämlich des Absende-Clients) kompensieren soll.
Folglich werde ich lieber mit einigen wenigen, falsch dargestellten
HTML-Mails leben als meinem Mailclienten das Herumdoktern an
Dateianhängen anzugewöhnen.

> Das musst Du den Absender fragen.

Paypal irgend etwas technisches fragen? Was erwartest du da für eine
Antwort? ;-)

> Ach so - Du hast ihn selbst gebaut.

Jau ;-)

>> Und wie schafft es ein HTML-Renderer (egal ob intern oder extern),
>> uncodierte Umlaute richtig darzustellen, obwohl uncodierte Umlaute in
>> HTML-Quelltext nicht zulässig sind?
>
> Wenn Du damit meinst, dass man z.B. "ä" statt "ä" schreibt - das
> ist sehr wohl zulässig. Genau dafür gibt es ja die entsprechenden
> Angaben im MIME- oder HTTP-Header bzw. im META-Element, damit der Client
> weiss, wie er diese Zeichen darzustellen hat.

Eine Zeichensatzdeklaration im HTTP-Header ist als nicht existent zu
betrachten, wenn er wegen eines vorhandenen MIME-Headers ignoriert
werden muss. Also müssen Umlaute nach der Decodierung gemäß MIME-Header
maskiert sein (im vorliegenden Fall sind sie das aber leider nicht).

Gibt es (z. B. nach einem Export in eine .HTM-Datei) keinen MIME-Header
mehr, muss stattdessen der HTTP-Header berücksichtigt werden. In diesem
Fall müssen Nicht-ASCII-Zeichen gemäß dem im HTTP-Header deklarierten
Zeichensatz codiert sein. Handelt es sich bei diesem Zeichensatz um
UTF-8, haben uncodierte und unmaskierte Umlaute im HTML-Quelltext nichts
mehr zu suchen (auch diese Vorgabe ist bei den Paypal-Mails nicht erfüllt).

Die Paypal-Mail ist also vermutlich kaputt. Ich gehe davon aus, dass TB
und Outlook dann mit Heuristik zu Werke gehen, um den HTML-Content der
Mail trotzdem lesbar darstellen zu können. Ich werde mich jetzt daran
machen, für meinen Mailclient auch eine entsprechende Heuristik zu
entwickeln.

Gruß

Michael

Peter J. Holzer

unread,

Jul 1, 2012, 12:47:12 PM7/1/12

to

On 2012-07-01 09:19, Michael Landenberger <spameim...@arcor.de> wrote:
> Am 30.06.2012 11:53, schrieb Peter J. Holzer:
>
>> Wie Du oben schon geschrieben hast:
>>
>>> deiner Antwort ist gesamte HTML-Part dementsprechend zu decodieren und
>>> das Meta-Tag im HTML-Quelltext zu ignorieren.
>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>
>>
>>> Der HTML-Renderer richtet sich danach und versucht, den (bereits
>>> quoted-printable-decodierten) HTML-Quelltext mit UTF-8 zu decodieren.
>>
>> Das darf er eben nicht, denn "das Meta-Tag im HTML-Quelltext [ist] zu
>> ignorieren".
>
> HTML-Renderer und Mailclient können 2 völlig verschiedene Programme
> sein. Beispielsweise kann man den HTML-Content (der ja nichts weiter als
> ein Anhang ist) aus dem Mailclient als .HTM-Datei exportieren und diese
> dann in einem separaten Browser betrachten.

Dann muss der Mail-Client eine Möglichkeit haben, dem Browser das
korrekte Encoding mitzuteilen.

> Der Browser kennt den
> Content-Type-Header überhaupt nicht, weil der ebenso wie bei beim Export
> jedes anderen MIME-Types nicht mit exportiert wird.

Da Du der Autor des Mailers bist, liegt es an Dir, das vorzusehen. Über
fehlende Features kannst Du Dich nur bei Software beklagen, die andere
geschrieben haben.

> In diesem Fall ist
> die Einhaltung der von dir genannten Vorschrift schlicht unmöglich.

Unmöglich ist es keinesfalls. Ich verwende z.B. den w3c (einen
textbasierten Browser), um text/html in text/plain umzuwandeln, so dass
ich text/html-Mails im mutt (einem textbasierten Mailer ohne eingebauten
Support für text/html) lesen kann. Der mutt kann zwar das charset
exportieren aber der w3c hat keine Option für das charset. Daher ruft
der mutt den w3c nicht direkt auf, sondern ein kleines Shell-Script, das
das html-File erst mittels iconv in utf-8 umwandelt und dann den w3c
aufruft.

> Mir ist es auch außer bei den Mails eines einzigen Absenders (PayPal)
> noch nie aufgefallen, dass eine vorschriftsmäßige Decodierung gemäß
> Content-Type-Header (also unter Ignorierung des Content-Type-MetaTags im
> HTML-Quelltext) zu ungültigen Zeichen wie z. B. uncodierten Umlauten
> führt (uncodierte Umlaute haben in HTML-Quelltext eigentlich nichts zu
> suchen, selbst dann nicht, wenn dieser gar keine eigene
> Zeichensatzdeklaration enthält).

Es führt ja nicht zu ungültigen Zeichen. Die Zeichen sind vollkommen in
Ordnung. Wenn man das Byte 0xE4 nach ISO-8859-1 dekodiert, kommt da
volllkommen richtig das Zeichen "ä" (U+00E4 LATIN SMALL LETTER A WITH
DIAERESIS) heraus. Deine Ansicht, dass Umlaute durch Character
References kodiert werden müssten, ist falsch.

> Irgendwas ist da faul. Ich vermute, dass PayPal Mist gebaut hat.

Jein. Natürlich ist es unsinnig, im Content-Type ein anderes charset
anzugeben als im Content-Type. Es ist aber eindeutig festgelegt, welches
charset in diesem Fall Vorrang hat, und wenn man sich an daran hält,
wird die Nachricht richtig dekodiert - sie ist also technisch korrekt
und zeigt nur einen Bug in Deinem Mailer auf.

> Allerdings bügeln Thunderbird und andere Mailclients diesen Mist
> offenbar wieder aus. Ich wüsste jetzt gerne, wie sie das machen.

Indem sie die Nachricht so dekodieren, wie es vorgeschrieben ist, also
mit dem charset aus dem Content-Type Header, nicht mit dem charset aus
dem META-Element.

>>> Bei einer korrekten UTF-8-Codierung müsste statt "ä" ein "Ã¤" und
>>> statt "ü" ein "Ã¼" im Quelltext stehen.
>>
>> Nur, wenn Du der Meinung bist, dass ISO-8859-1 die einzig wahre und
>> gottgegebene Kodierung ist. Es ist wenig sinnvoll, hier von Zeichen zu
>> reden. Richtig wäre die Formulierung:
>>
>> Bei einer korrekten UTF-8-Codierung müssten statt 0xE4 die Bytes
>> 0xC3 0xA4 und statt 0xFC die Bytes 0xC3 0xBC im Quelltext stehen.
>>
>> Das Byte 0xC3 ist eben kein "Ã" sondern in UTF-8 ein Teil des Zeichens
>> "ä" bzw. "ü" (in CP 850 wäre 0xC3 ein Blockgrafikzeichen ("├") und in
>> EBCDIC wäre es ein "C")
>
> Danke für die Richtigstellung. Aber es wurde hoffentlich klar, was ich
> gemeint habe.

Das Thema ist schwierig genug, wenn man sich korrekt und eindeutig
ausdrückt. Es wird noch viel schwieriger, wenn man sich schwammig
ausdrückt. Und meiner Erfahrung nach haben Leute, die sich hier
schwammig ausdrücken, auch meistens ein Verständnisproblem. Das scheint
mir auch bei Dir vorzuliegen, wenn Du von "unkodierten Umlauten"
schreibst, oder davon, dass Du die bereits dekodierte Nachricht
"unverändert an den Browser übergibst".

> Die Umlaute stehen nach der Quoted-Printable-Decodierung als
> uncodierte Zeichen im HTML-Quelltext.

Falsch. Nach der Quoted-Printable-Decodierung stehen sie
ISO-8859-1-kodiert im Quelltext. Das entspricht dem charset-Parameter in
Content-Type-Header.

> Das verstößt sowohl gegen die Zeichensatzdeklaration im Meta-Tag

Ja.

> (die zwar vom Mailclient selbst zu ignorieren ist,

Richtig.

> nicht jedoch von externen Programmen, die vom Content-Type-Header der
> Mail nichts wissen können)

Irrelevant. Das HTML-Dokument ist Teil einer Mail und nur innerhalb
dieser Mail zu interpretieren. Es könnte z.B. auch Inline-Images mit
cid-URLs enthalten. Wenn Dein Mailer das HTML-Dokument einem externen
Programm zugänglich machen möchte, dann ist Dein Programm dafür
verantwortlich, eine entsprechende Konvertierung vorzunehmen. Das kann
bedeuten, ein META-Element auszutauschen, es kann bedeuten, alle
Inline-Images in ein temporäres Directory zu speichern und die cid-URLs
durch file-URLs zu ersetzen, und vielleicht noch mehr.

> als auch gegen HTML-Konventionen, nach denen Umlaute als "ä",
> "ü" usw. zu notieren sind.

Falsch.

>>> Thunderbird und Outlook stellen die Mail jedoch trotz der
>>> widersprüchlichen Deklaration korrekt dar. Wie machen die das?
>>
>> Indem sie sich strikt an den Header halten und die Deklaration im
>> Meta-Tag ignorieren.
>
> Es mag ja sein, dass sich TB und Outlook daran halten. Aber das Ergebnis
> der Einhaltung dieser Vorschrift ist HTML-Quelltext mit ungültigen
> Zeichen.

Nein. Nach der Dekodierung wurde aus dem Byte 0xE4 das
Zeichen "ä" (U+00E4 LATIN SMALL LETTER A WITH DIAERESIS). Das ist nicht
nur nicht ungültig, sondern genau das Zeichen, das Du haben willst.

> Diesen Quelltext korrekt darzustellen ist nur mit Tricks
> möglich. Welche Tricks sind das? Wird beim Vorhandensein von uncodierten
> Umlauten geraten, welches Zeichen bzw. welcher Zeichensatz da vorliegen
> könnte?

Das sind keine Tricks notwendig. Der HTML-Parser bekommt einen
Bytestrom zusammen mit einem charset-Parameter (und anderem Kontext,
der uns hier nicht interessieren braucht). Da er das charset bereits
kennt, kann er den Bytestrom einfach dekodieren.

Tricks sind nur notwendig, wenn das charset noch nicht bekannt ist.
Dann muss der Parser erst mal nach einem META-Tag suchen oder andere
Heuristiken anwenden, um das charset zu erraten.

(Möglicherweise nimmst Du an, dass TB und Outlook den HTML-Teil einem
externen Programm übergeben, so wie Dein Mailer das macht. Tun sie
nicht. TB baut auf der Gecko-Engine auf (ebenso wie Firefox) und Outlook
verwendet ebenfalls einen internen HTML-Renderer (bin mir aber nicht
sicher, ob das Trident ist). Jedes moderne GUI-Toolkit kommt mit einer
HTML-Komponente).

Peter J. Holzer

unread,

Jul 1, 2012, 1:14:50 PM7/1/12

to

["Followup-To:" header set to de.comm.infosystems.www.authoring.misc.]

On 2012-07-01 09:43, Michael Landenberger <spameim...@arcor.de> wrote:
> Nun habe ich den Client so umprogrammiert, dass er HTML-Content
> grundsätzlich gemäß Content-Type-Header decodiert und dann den so
> decodierten HTML-Quelltext 1:1 an den Renderer weiterreicht.

Du hast vorhin geschrieben, dass Dein Renderer ein externes Programm
ist und dass Du dan Quelltext über das Filesystem ("ein .HTM-File")
übergibst. Dann ist das aber unmöglich. Nachdem Du den Quelltext dekodiert
hast, ist er keine Folge von Bytes mehr, sondern eine Folge von Zeichen.
Ein File ist aber immer eine Folge von Bytes. Um den HTML-Text in ein
File zu schreiben, musst Du ihn wieder encodieren, d.h. Du musst Dich
entscheiden, ob Du das Zeichen "ä" als ein Byte 0xE4 oder als zwei Bytes
0xC3 0xA4 oder irgendwie anders auf die Platte schreibst.

>>> Mail jedoch trotz der widersprüchlichen Deklaration korrekt dar. Wie
>>> machen die das?
>>
>> Indem sie standardkonform die META-Angabe ignorieren, weil ja bereits im
>> Content-Type die Angaben vorliegen.
>
> Wie macht das ein Mailclient wie z. B. Outlook Express, der ja zum
> Rendern von HTML den Internet Explorer (also einen externen Renderer)
> verwendet?

Tut er das? Glaube ich nicht. Der verwendet nur die gleiche
HTML-Komponente.

> Gibt es eine Möglichkeit, dem Internet-Explorer-ActiveX zu sagen, dass
> es die Zeichensatzdeklaration im Meta-Tag ignorieren soll?

Ja.

> Und wie schafft es ein HTML-Renderer (egal ob intern oder extern),
> uncodierte Umlaute richtig darzustellen,

Es gibt keine unkodierten Umlaute. Du meinst Umlaute, die in ISO-8859-1,
UTF-8, etc. kodiert sind und nicht als Character References.

> obwohl uncodierte Umlaute in HTML-Quelltext nicht zulässig sind?

Sie sind zulässig. Sonst bräuchte man ja keinen charset-Parameter.

Peter J. Holzer

unread,

Jul 1, 2012, 1:23:46 PM7/1/12

to

["Followup-To:" header set to de.comm.infosystems.www.authoring.misc.]

On 2012-07-01 15:07, Michael Landenberger <spameim...@arcor.de> wrote:
> Am 01.07.2012 13:02, schrieb Arno Welzel:
>> Dann ist die ganze Konstruktion kaputt. Wenn der Mail-Client anhand des
>> MIME-Headers weiss, dass das Dokument also ISO-8859-1 zu interpretieren
>> ist, sollte er die entsprechende META-Angabe beim Export löschen oder
>> korrigieren.
>
> Einen Mailclient, der den Inhalt einer angehängten Datei beim Export
> verändert, halte ich für noch kaputter. Das gilt insbesondere dann, wenn
> dieses Verhalten den Fehler eines anderen, mutmaßlich tatsächlich
> kaputten Mailclients (nämlich des Absende-Clients) kompensieren soll.
> Folglich werde ich lieber mit einigen wenigen, falsch dargestellten
> HTML-Mails leben als meinem Mailclienten das Herumdoktern an
> Dateianhängen anzugewöhnen.

Es steht Dir natürlich frei, Deine Bugs als Features zu deklarieren:

http://thegeekwhisperer.com/2009/09/24/bug-vs-feature/

>>> Und wie schafft es ein HTML-Renderer (egal ob intern oder extern),
>>> uncodierte Umlaute richtig darzustellen, obwohl uncodierte Umlaute in
>>> HTML-Quelltext nicht zulässig sind?
>>
>> Wenn Du damit meinst, dass man z.B. "ä" statt "ä" schreibt - das
>> ist sehr wohl zulässig. Genau dafür gibt es ja die entsprechenden
>> Angaben im MIME- oder HTTP-Header bzw. im META-Element, damit der Client
>> weiss, wie er diese Zeichen darzustellen hat.
>
> Eine Zeichensatzdeklaration im HTTP-Header ist als nicht existent zu
> betrachten, wenn er wegen eines vorhandenen MIME-Headers ignoriert
> werden muss.

Du verwechselst HTTP und HTML.

Thomas 'PointedEars' Lahn

unread,

Jul 1, 2012, 1:33:05 PM7/1/12

to

Michael Landenberger wrote:

> Am 01.07.2012 13:02, schrieb Arno Welzel:
>> Dann ist die ganze Konstruktion kaputt. Wenn der Mail-Client anhand des
>> MIME-Headers weiss, dass das Dokument also ISO-8859-1 zu interpretieren
>> ist, sollte er die entsprechende META-Angabe beim Export löschen oder
>> korrigieren.
>
> Einen Mailclient, der den Inhalt einer angehängten Datei beim Export
> verändert, halte ich für noch kaputter.

<http://www.w3.org/TR/REC-html40/charset.html#h-5.2.2>

“To sum up, conforming user agents must observe the following priorities
when determining a document's character encoding (from highest priority to
lowest):

1. An HTTP "charset" parameter in a "Content-Type" field.
2. A META declaration with "http-equiv" set to "Content-Type" and a value
set for "charset".
3. The charset attribute set on an element that designates an external
resource.

In addition to this list of priorities, the user agent may use heuristics
and user settings. For example, many user agents use a heuristic to
distinguish the various encodings used for Japanese text. Also, user agents
typically have a user-definable, local default character encoding which they
apply in the absence of other indicators.

User agents may provide a mechanism that allows users to override incorrect
"charset" information. However, if a user agent offers such a mechanism, it
should only offer it for browsing and not for editing, to avoid the creation
of Web pages marked with an incorrect "charset" parameter.”

> Das gilt insbesondere dann, wenn dieses Verhalten den Fehler eines
> anderen, mutmaßlich tatsächlich kaputten Mailclients (nämlich des Absende-
> Clients) kompensieren soll. Folglich werde ich lieber mit einigen wenigen,
> falsch dargestellten HTML-Mails leben als meinem Mailclienten das
> Herumdoktern an Dateianhängen anzugewöhnen.

"Be conservative in what you do, be liberal in what you accept from others."

<http://en.wikipedia.org/wiki/Robustness_principle>

>>> Und wie schafft es ein HTML-Renderer (egal ob intern oder extern),
>>> uncodierte Umlaute richtig darzustellen, obwohl uncodierte Umlaute in
>>> HTML-Quelltext nicht zulässig sind?
>>
>> Wenn Du damit meinst, dass man z.B. "ä" statt "ä" schreibt - das
>> ist sehr wohl zulässig. Genau dafür gibt es ja die entsprechenden
>> Angaben im MIME- oder HTTP-Header bzw. im META-Element, damit der Client
>> weiss, wie er diese Zeichen darzustellen hat.
>
> Eine Zeichensatzdeklaration im HTTP-Header ist als nicht existent zu
> betrachten, wenn er wegen eines vorhandenen MIME-Headers ignoriert
> werden muss.

Diese Aussage ergibt keinen Sinn. `Content-Type' *ist* ein (mögliches)
MIME-Headerfeld, und es gibt es sowohl bei HTTP-Requests/Responses (RFC
1945/2616) als auch bei E-Mail (und auch bei NetNews-Nachrichten wie dieser,
siehe RFC 5536), da dies alles Internet-Nachrichten (RFC 5322) sind.

> Also müssen Umlaute nach der Decodierung gemäß MIME-Header
> maskiert sein

Nochmal: Sie müssen es _nicht_.

> (im vorliegenden Fall sind sie das aber leider nicht).

Das heisst, das `Content-Type'-Headerfeld des entsprechenden Teils der
Multipart-Nachricht oder (wenn dieses fehlt) das `Content-Type'-Headerfeld
der Nachricht sollte die verwendete Zeichencodierung angeben, es sei denn,
es handelt sich um einen Text, der nur Zeichen aus US-ASCII enthält.

> Die Paypal-Mail ist also vermutlich kaputt.

Deine Vermutungen, offensichtlich basierend auf einem falschen Verständnis
von Internet-Protokollen, bringen uns hier nicht weiter.

Talk is cheap. Show me the code.
-- Linus Torvals

Aber bitte nur dort, wo es on-topic ist. Und lass bitte das sinnfreie
Crossposten ohne F'up2.

F'up2 de.comm.software.mailreader.misc (I stand corrected: <news:de-
newusers-infos/de-newsgruppen/20120...@msgid.krell.zikzak.de>)

PointedEars
--
realism: HTML 4.01 Strict
evangelism: XHTML 1.0 Strict
madness: XHTML 1.1 as application/xhtml+xml
-- Bjoern Hoehrmann

Thomas 'PointedEars' Lahn

unread,

Jul 1, 2012, 1:40:46 PM7/1/12

to

Michael Landenberger wrote:

> Am 01.07.2012 13:04, schrieb Thomas 'PointedEars' Lahn:
>> Dein Mailclient kümmert sich in dem Fall um Dinge, die ihn nicht zu
>> interessieren haben. Er hat die *Transfer*codierung (Headerfeld
>> `Content- Transfer-Encoding') zu decodieren (z. B. Quoted-Printable) und
>> dann das Ergebnis an die Layout-Engine weiterzureichen.
>

> Ich kann nicht nachvollziehen, warum immer noch nicht deutlich wurde,
> dass mein Mailclient genau das tut ;-)

Ich bin sicher, dass ich dazu noch viel mehr geschrieben habe. Dein
Mailclient macht anscheinend Dinge, die er nicht tun sollte (Maskierung von
Umlauten), und unterlässt dafür Dinge, die er sinnvollerweise tun sollte
(Mitliefern von persistenter Information über die Zeichencodierung der
Ressource).

>> Keine Ahnung, ist IMHO auch in beiden Gruppen, in die gecrosspostet
>> wurde, off-topic.
>

> Für das Crossposting kann ich nix, denn ich habe in
> de.comm.software.mailreader.misc gepostet.

Unter anderem. Siehe das Newsgroups-Headerfeld z. B. in
<news:a56tje...@mid.uni-berlin.de>, <news:a5aj1r...@mid.uni-berlin.de>
und <news:a5akeo...@mid.uni-berlin.de>. Ja, das sind Postings von *Dir*.
Man muss nicht jedes Crossposting mitmachen, zumindest kann man irgendwann
mal ein `Followup-To'-Headerfeld mitsenden.

> Genau dorthin werde ich jetzt auch wieder umleiten.

Udiags. (Wie ich jetzt weiss.)

PointedEars
--
Man kann mit JavaScript eine große Zahl von Roundtrips eliminieren und
damit die Usability erhöhen. Allerdings übersteigen die Möglichkeiten
von JavaScript die zerebralen Fähigkeiten der meisten Webmaster bei
Weitem. -- Johann Burkard in dag°

Thomas 'PointedEars' Lahn

unread,

Jul 1, 2012, 1:46:34 PM7/1/12

to

Peter J. Holzer wrote:

> Michael Landenberger wrote:
>> In diesem Fall ist die Einhaltung der von dir genannten Vorschrift
>> schlicht unmöglich.
>
> Unmöglich ist es keinesfalls. Ich verwende z.B. den w3c (einen

^^^

> textbasierten Browser), um text/html in text/plain umzuwandeln,

Du meinst vermutlich _w3m_ :)

>> Irgendwas ist da faul. Ich vermute, dass PayPal Mist gebaut hat.
>
> Jein. Natürlich ist es unsinnig, im Content-Type ein anderes charset
> anzugeben als im Content-Type.

Wie meinen? :)

> […]

Full ACK.

F'up2 de.comm.software.mailreader.misc

PointedEars
--
Wenn es dort funzt, dann ist für Altlasten einfach eine Upgrade-Aufforderung
einzubauen. Du kannst einer Mücke nicht beibringen, einen Haufen zu machen
wie ein Elefant. Wer so große Häufchen haben will, soll sich gefälligst
einen Elefant zulegen. -- Georg Maaß in dcljs

Michael Landenberger

unread,

Jul 1, 2012, 1:51:58 PM7/1/12

to

Am 01.07.2012 18:47, schrieb Peter J. Holzer:

> On 2012-07-01 09:19, Michael Landenberger <spameim...@arcor.de> wrote:

>> HTML-Renderer und Mailclient können 2 völlig verschiedene Programme
>> sein. Beispielsweise kann man den HTML-Content (der ja nichts weiter als
>> ein Anhang ist) aus dem Mailclient als .HTM-Datei exportieren und diese
>> dann in einem separaten Browser betrachten.
>
> Dann muss der Mail-Client eine Möglichkeit haben, dem Browser das
> korrekte Encoding mitzuteilen.

Eine solche Möglichkeit sehe vielleicht dann, wenn der Mailclient
entweder selbst rendert oder *intern* ein Browser-Control (z. B. das
IE-ActiveX-Control) benutzt, um HTML zu rendern. Bei einem Export eines
HTML-Anhangs gibt es aber keine solche Möglichkeit, es sei denn, der
Mailclient manipuliert den HTML-Quelltext, bevor er ihn exportiert.
Einen Mailclient, der den Inhalt von Dateianhängen beim Exportieren
manipuliert, möchte ich aber nicht.

> Da Du der Autor des Mailers bist, liegt es an Dir, das vorzusehen. Über
> fehlende Features kannst Du Dich nur bei Software beklagen, die andere
> geschrieben haben.

Ich beklage mich nicht über fehlende Features (ich schreibe einen
eigenen Client vor allem deshalb, damit ich die von mir benötigten
Features jederzeit einbauen kann). Ich möchte vielmehr wissen, wie
andere Mailclients mit derartigen Konstellationen klarkommen. Wie es
aussieht, werde ich auf diese Frage hier aber vermutlich keine Antwort
bekommen. Ich werde also entweder den Quellcode eines
Open-Source-Mailers analysieren oder mir eigene Routinen dafür ausdenken
müssen.

>> Mir ist es auch außer bei den Mails eines einzigen Absenders (PayPal)
>> noch nie aufgefallen, dass eine vorschriftsmäßige Decodierung gemäß
>> Content-Type-Header (also unter Ignorierung des Content-Type-MetaTags im
>> HTML-Quelltext) zu ungültigen Zeichen wie z. B. uncodierten Umlauten
>> führt (uncodierte Umlaute haben in HTML-Quelltext eigentlich nichts zu
>> suchen, selbst dann nicht, wenn dieser gar keine eigene
>> Zeichensatzdeklaration enthält).
>
> Es führt ja nicht zu ungültigen Zeichen. Die Zeichen sind vollkommen in
> Ordnung. Wenn man das Byte 0xE4 nach ISO-8859-1 dekodiert, kommt da
> volllkommen richtig das Zeichen "ä" (U+00E4 LATIN SMALL LETTER A WITH
> DIAERESIS) heraus. Deine Ansicht, dass Umlaute durch Character
> References kodiert werden müssten, ist falsch.

Natürlich ist es vollkommen in Ordnung, wenn der
Quoted-Printable-Decoder aus "=E4" ein "ä" macht. Dieses Verhalten
stelle ich auch überhaupt nicht in Frage. Aber leider führt dieser
"Dienst nach Vorschrift" des Decoders dazu, dass er uncodierte bzw.
unmaskierte "ä" auch in solchen HTML-Quellcode einbaut, wo solche
Zeichen fehl am Platze sind. Aber auch dafür kann der Decoder nix, denn
er decodiert ja nur. Es ist dagegen nicht seine Aufgabe zu prüfen, ob
der von ihm erzeugte HTML-Quelltext auch valide ist. Jedenfalls macht
der Decoder in meinem Mailer in dieser Hinsicht alles richtig.

Im hier zur Debatte stehenden Fall wird der Decoder aber bereits mit
invalidem HTML gefüttert, welches der *Absender* verbrochen hat. Dieses
invalide HTML zeigen TB und Outlook aber korrekt an. Inzwischen bin ich
mir ziemlich sicher, dass das nur dank einer Heuristik möglich ist. Ich
sehe ansonsten keine andere Möglichkeit, bei fehlender [1] oder falscher
[2] Zeichensatzdeklaration unmaskierte Sonderzeichen in HTML-Quelltext
korrekt darzustellen.

[1] HTML-Darstellung innerhalb des Mailreaders: regelkonform wird nur
der MIME-Header berücksichtigt, das HTML-Meta-Tag nicht. Das ist
gleichbedeutend mit einer fehlenden Zeichensatzdeklaration im
HTML-Quelltext. Sonderzeichen im HTML-Quelltext müssen dann maskiert
sein. Sind sie es nicht, handelt es sich um invalides HTML.

[2] HTML-Darstellung in einem externen Browser: der MIME-Header ist hier
nicht bekannt, weil er nicht in die exportierte .HTM-Datei geschrieben
wird. Also wertet der Browser hier das entsprechende HTML-Meta-Tag aus.
Die Zeichensatzdeklaration im Meta-Tag ist dann falsch, wenn in dieser
"UTF-8" als Zeichensatz deklariert ist, der Quelltext aber trotzdem
uncodierte Nicht-ASCII-Zeichen enthält.

> Jein. Natürlich ist es unsinnig, im Content-Type ein anderes charset
> anzugeben als im Content-Type. Es ist aber eindeutig festgelegt, welches
> charset in diesem Fall Vorrang hat, und wenn man sich an daran hält,
> wird die Nachricht richtig dekodiert - sie ist also technisch korrekt
> und zeigt nur einen Bug in Deinem Mailer auf.

Widerspruch. Mein Mailer berücksichtigt inzwischen *regelkonform*
ausschließlich die Deklaration im MIME-Header und decodiert den
HTML-Content entsprechend. Die Deklaration im entsprechenden
HTML-Meta-Tag ignoriert er. Im hier zur Debatte stehenden Fall kommt
aber trotzdem invalides HTML dabei heraus, weil der *Absender* seinen
Encoder vor dem Versand mit invalidem HTML gefüttert hat.

> Irrelevant. Das HTML-Dokument ist Teil einer Mail und nur innerhalb
> dieser Mail zu interpretieren.

Ach hier liegt mein Denkfehler. Es ist also nicht zulässig, HTML aus
einer Mail zu exportieren? Ich fände diese Möglichkeit manchmal durchaus
nützlich. Und wenn der Export nicht zulässig ist: warum enthält
HTML-Quellcode, der nur für die Darstellung innerhalb eines Mailreaders
bestimmt ist, überhaupt eine Zeichensatzdeklaration, obwohl diese doch
zu ignorieren und stattdessen der im MIME-Header deklarierte Zeichensatz
zu verwenden ist?

> Nein. Nach der Dekodierung wurde aus dem Byte 0xE4 das
> Zeichen "ä" (U+00E4 LATIN SMALL LETTER A WITH DIAERESIS). Das ist nicht
> nur nicht ungültig, sondern genau das Zeichen, das Du haben willst.

Nein. In HTML-Quelltext ganz ohne Zeichensatzdeklaration (gilt u. a. bei
interner Darstellung = HTML-Zeichensatz wird ignoriert) oder mit
UTF-8-Zeichensatzdeklaration möchte ich sowas nicht haben. Ich bin
sicher, du auch nicht ;-)

Gruß

Michael

Michael Landenberger

unread,

Jul 1, 2012, 2:02:26 PM7/1/12

to

Am 01.07.2012 19:40, schrieb Thomas 'PointedEars' Lahn:

> Dein

> Mailclient macht anscheinend Dinge, die er nicht tun sollte

Nein, macht er nicht (mehr).

> (Maskierung von
> Umlauten),

Ich wüsste nicht, wo ich geschrieben habe, dass mein Mailclient Umlaute
maskiert (auch das tut er nicht).

> und unterlässt dafür Dinge, die er sinnvollerweise tun sollte
> (Mitliefern von persistenter Information über die Zeichencodierung der
> Ressource).

Wenn du mir verrätst, wie man eine solche Information in ein
HTML-Dokument schreibt, *ohne* das Dokument selbst dabei zu verändern,
dann werde ich das gerne umsetzen.

>> Für das Crossposting kann ich nix, denn ich habe in
>> de.comm.software.mailreader.misc gepostet.
>
> Unter anderem.

Ich meinte mein OP. Das habe ich *ausschließlich* nach
de.comm.software.mailreader.misc gepostet. Die Crosspostings haben
andere eingeführt. Ich habe nur den Fehler gemacht, das zu übersehen.
Das wird mir aber nicht nochmal passieren, weswegen ich auch diesen
Beitrag wieder nach dcsmm posten und Follow-Ups ausschließlich dorthin
umleiten werden.

Gruß

Michael

Michael Landenberger

unread,

Jul 1, 2012, 2:17:41 PM7/1/12

to

Am 01.07.2012 19:14, schrieb Peter J. Holzer:

> Du hast vorhin geschrieben, dass Dein Renderer ein externes Programm
> ist und dass Du dan Quelltext über das Filesystem ("ein .HTM-File")
> übergibst. Dann ist das aber unmöglich. Nachdem Du den Quelltext dekodiert
> hast, ist er keine Folge von Bytes mehr, sondern eine Folge von Zeichen.
> Ein File ist aber immer eine Folge von Bytes.

Zeichen sind Bytes ;)

> Um den HTML-Text in ein
> File zu schreiben, musst Du ihn wieder encodieren,

Nö, warum? Einen Base64-encodierten JPG-Anhang encodiere ich auch nicht
wieder, bevor ich ihn in eine JPEG-Datei exportiere, denn andernfalls
könnte kein JPEG-Viewer mit der erzeugten Datei etwas anfangen.

> d.h. Du musst Dich
> entscheiden, ob Du das Zeichen "ä" als ein Byte 0xE4 oder als zwei Bytes
> 0xC3 0xA4 oder irgendwie anders auf die Platte schreibst.

Ich behandle HTML-Attachments genauso wie jedes andere Attachment auch:
ich decodiere sie gemäß MIME-Header und schreibe das Ergebnis auf die
Platte. Im Falle eines text/html-Anhangs entstehen dabei normalerweise
HTML-Dateien, die valides und von jedem Browser lesbares HTML enthalten.
Nur im Fall der Paypal-Mails war das bisher anders, aber nicht deshalb,
weil mein Programm Fehler macht, sondern weil der Absender einen Fehler
gemacht hat (er hat seinen Mailclienten mit invalidem HTML gefüttert).
Es ist aber nicht Sache meines Mailprogramms, ein Attachment so
"aufzubereiten", dass absenderseitige Fehler ausgebügelt werden.
Vielmehr müssen Attachments gleich welchen Formats beim Export
bytegetreu auf der Platte landen. Mir ist auch kein Mailreader bekannt,
bei dem das anders wäre.

>> Wie macht das ein Mailclient wie z. B. Outlook Express, der ja zum
>> Rendern von HTML den Internet Explorer (also einen externen Renderer)
>> verwendet?
>
> Tut er das? Glaube ich nicht. Der verwendet nur die gleiche
> HTML-Komponente.

Und die ist nicht Bestandteil von Outlook Express, sondern gehört zum
Internet Explorer, also einem externen Programm. Wäre der Internet
Explorer nicht installiert, könnte OE keine HTML-Mails anzeigen.

xpost und fup2 dcsmm

Gruß

Michael

Thomas 'PointedEars' Lahn

unread,

Jul 1, 2012, 3:48:05 PM7/1/12

to

Michael Landenberger wrote:

> Am 01.07.2012 19:14, schrieb Peter J. Holzer:
>> Du hast vorhin geschrieben, dass Dein Renderer ein externes Programm
>> ist und dass Du dan Quelltext über das Filesystem ("ein .HTM-File")
>> übergibst. Dann ist das aber unmöglich. Nachdem Du den Quelltext
>> dekodiert hast, ist er keine Folge von Bytes mehr, sondern eine Folge von
>> Zeichen. Ein File ist aber immer eine Folge von Bytes.
>
> Zeichen sind Bytes ;)

Nein, das ist (D)ein grundsätzliches Missverständnis. Es ist zu
unterscheiden zwischen einem Zeichen eines Zeichensatzes und seiner
Codierung (nein, das hat mit HTML nichts zu tun).

>> Um den HTML-Text in ein File zu schreiben, musst Du ihn wieder
>> encodieren,
>

> Nö, warum? Einen Base64-encodierten JPG-Anhang […]

Äpfel und Birnen. Es ging um HTML-*Text*. Damit Zeichen eines Textes
gespeichert werden können, muss dafür eine bestimmte Zeichencodierung
gewählt werden, d. h. die Zeichen müssen anhand einer Code-Tabelle in Code
Sequenzen umgewandelt werden. Diese sind entweder Byte-Folgen oder Folgen
von Byte-Paaren.

>> d.h. Du musst Dich entscheiden, ob Du das Zeichen "ä" als ein Byte 0xE4
>> oder als zwei Bytes 0xC3 0xA4 oder irgendwie anders auf die Platte
>> schreibst.

ACK.

> Ich behandle HTML-Attachments genauso wie jedes andere Attachment auch:
> ich decodiere sie gemäß MIME-Header

^^^^^^^^^^^^^^^^^
Das heisst konkret?

> und schreibe das Ergebnis auf die Platte.

> Im Falle eines text/html-Anhangs entstehen dabei normalerweise
> HTML-Dateien, die valides und von jedem Browser lesbares HTML enthalten.

Nein. Ob es sich um ein syntaktisch korrektes HTML-Dokument handelt, steht
auf einem ganz anderen Blatt. Auf einem dritten steht, ob der Browser,
mithin dessen Markup-Parser es verarbeiten kann und auf einem vierten, wie
das Ergebnis dieses Prozesses aussieht.

>>> Wie macht das ein Mailclient wie z. B. Outlook Express, der ja zum
>>> Rendern von HTML den Internet Explorer (also einen externen Renderer)
>>> verwendet?
>> Tut er das? Glaube ich nicht. Der verwendet nur die gleiche
>> HTML-Komponente.
>
> Und die ist nicht Bestandteil von Outlook Express, sondern gehört zum
> Internet Explorer, also einem externen Programm.

Nein, es handelt sich um eine gemeinsam genutzte Software*komponente*. Sie
wird auch von anderen Programmen genutzt, z. B. seit spätestens Windows 2000
auch von der Systemsteuerung (per HTAs).

> Wäre der Internet Explorer nicht installiert, könnte OE keine HTML-Mails
> anzeigen.

Fhcsal, denn mit an Sicherheit grenzender Wahrscheinlichkeit liefert das OE-
Setup ebenfalls MSHTML mit. Bloss gehört OE zum IE-Setup (jedenfalls war
das bisher so) und deshalb liefert das IE-Setup bereits MSHTML mit.

PointedEars
--
ich benutze den Befehl BOQuery, um Daten aus meiner Datenbank zu lesen.
Dieser funktioniert im IE 6 auch meistens. Aber auf manchen Rechnern bei
uns in der Firma funktioniert er nicht. [...] Was muß ich installieren?
(Reiner Wahnsiedler in dcljs <ardkdn$d0q$07$1...@news.t-online.com>)

Thomas 'PointedEars' Lahn

unread,

Jul 1, 2012, 3:56:04 PM7/1/12

to

Michael Landenberger wrote:

> Thomas 'PointedEars' Lahn:

>> (Maskierung von Umlauten),
>
> Ich wüsste nicht, wo ich geschrieben habe, dass mein Mailclient Umlaute
> maskiert (auch das tut er nicht).

Du erwähntest mehrfach die *scheinbar* notwendige "Codierung" von "ä"
mittels "ä".

>> und unterlässt dafür Dinge, die er sinnvollerweise tun sollte
>> (Mitliefern von persistenter Information über die Zeichencodierung der
>> Ressource).
>
> Wenn du mir verrätst, wie man eine solche Information in ein
> HTML-Dokument schreibt, *ohne* das Dokument selbst dabei zu verändern,
> dann werde ich das gerne umsetzen.

Wie Du inzwischen wissen solltest: Falls das HTML-Dokument nicht die
richtige Meta-Information über die Zeichencodierung bereitstellt (per BOM
oder META-Element), ist es nicht möglich, diese Meta-Information ohne
Veränderung des Dokuments zu speichern, es sei denn, das Dateisystem bietet
diese Möglichkeit. (Mir ist kein solches Dateisystem bekannt.) Deshalb
gibt es die Möglichkeit der Zeichendeklaration mittels META-Element.
Nutze sie, falls es in Deinem Fall nichts Besseres gibt.

--
PointedEars

Please do not Cc: me. / Bitte keine Kopien per E-Mail.

Arno Welzel

unread,

Jul 1, 2012, 5:14:02 PM7/1/12

to

Michael Landenberger, 01.07.2012 17:07:

> Am 01.07.2012 13:02, schrieb Arno Welzel:
>
>> Dann ist die ganze Konstruktion kaputt. Wenn der Mail-Client anhand des
>> MIME-Headers weiss, dass das Dokument also ISO-8859-1 zu interpretieren
>> ist, sollte er die entsprechende META-Angabe beim Export löschen oder
>> korrigieren.
>
> Einen Mailclient, der den Inhalt einer angehängten Datei beim Export
> verändert, halte ich für noch kaputter. Das gilt insbesondere dann, wenn
> dieses Verhalten den Fehler eines anderen, mutmaßlich tatsächlich
> kaputten Mailclients (nämlich des Absende-Clients) kompensieren soll.
> Folglich werde ich lieber mit einigen wenigen, falsch dargestellten
> HTML-Mails leben als meinem Mailclienten das Herumdoktern an
> Dateianhängen anzugewöhnen.

Wir reden hier über HTML, dass den *Inhalt* der Mail darstellt, keinen
Dateianhang im klassischen Sinn.

Wie gehst Du damit um, wenn ein HTML-Dokument als UTF-8 ankommt, aber
keinen META-Header dazu enthält, sondern nur ein MIME-Header dafür
vorhanden ist? Beim Export wird die Information dann einfach verworfen
und der Benutzer hat halt Pech gehabt und der Absender hat Mist gebaut,
obwohl die Angabe eines META-Headers nirgends zwingend vorgeschrieben ist?

[...]

>> Wenn Du damit meinst, dass man z.B. "ä" statt "ä" schreibt - das
>> ist sehr wohl zulässig. Genau dafür gibt es ja die entsprechenden
>> Angaben im MIME- oder HTTP-Header bzw. im META-Element, damit der Client
>> weiss, wie er diese Zeichen darzustellen hat.
>
> Eine Zeichensatzdeklaration im HTTP-Header ist als nicht existent zu
> betrachten, wenn er wegen eines vorhandenen MIME-Headers ignoriert
> werden muss. Also müssen Umlaute nach der Decodierung gemäß MIME-Header
> maskiert sein (im vorliegenden Fall sind sie das aber leider nicht).

Mit "HTTP-Header" meine ich *nicht* den Header im HTML-Dokument, sondern
den Header, den ein *Webserver* an den Browser schickt. Die Angaben im
MIME-Header sind analog anzusehen.

> Gibt es (z. B. nach einem Export in eine .HTM-Datei) keinen MIME-Header
> mehr, muss stattdessen der HTTP-Header berücksichtigt werden. In diesem

Du meinst wohl META-Element.

> Fall müssen Nicht-ASCII-Zeichen gemäß dem im HTTP-Header deklarierten
> Zeichensatz codiert sein. Handelt es sich bei diesem Zeichensatz um
> UTF-8, haben uncodierte und unmaskierte Umlaute im HTML-Quelltext nichts
> mehr zu suchen (auch diese Vorgabe ist bei den Paypal-Mails nicht erfüllt).

Genau deswegen ist es kurzsichtig, bei der Anzeige die MIME-Angaben zu
verwenden, beim Export dieser angezeigten Daten in eine Datei den Inhalt
einfach 1:1 als Datei abzuspeichern.

> Die Paypal-Mail ist also vermutlich kaputt. Ich gehe davon aus, dass TB
> und Outlook dann mit Heuristik zu Werke gehen, um den HTML-Content der
> Mail trotzdem lesbar darstellen zu können. Ich werde mich jetzt daran
> machen, für meinen Mailclient auch eine entsprechende Heuristik zu
> entwickeln.

Nein TB und Outlook machen einfach das, was vorgegeben ist: Sie beachten
nur die Angabe im MIME-Header, die die Angabe im META-Element innerhalb
des Dokumentes überschreibt.

Arno Welzel

unread,

Jul 1, 2012, 5:24:41 PM7/1/12

to

Michael Landenberger, 01.07.2012 20:17:

> Am 01.07.2012 19:14, schrieb Peter J. Holzer:
>

[...]

>> d.h. Du musst Dich
>> entscheiden, ob Du das Zeichen "ä" als ein Byte 0xE4 oder als zwei Bytes
>> 0xC3 0xA4 oder irgendwie anders auf die Platte schreibst.
>
> Ich behandle HTML-Attachments genauso wie jedes andere Attachment auch:
> ich decodiere sie gemäß MIME-Header und schreibe das Ergebnis auf die

D.h. Du schaust in "Content-Transfer-Encoding", um daraus wieder Oktette
zu basteln. Und was machst Du mit der charset-Angabe im Content-Type?
Wegwerfen, weil das ja ganz sicher als META-Angabe im HTML-Dokument
enthalten ist?

> Platte. Im Falle eines text/html-Anhangs entstehen dabei normalerweise
> HTML-Dateien, die valides und von jedem Browser lesbares HTML enthalten.

Valide - nicht unbedingt. Und korrekt darstellbar nur dann, wenn ein
korrektes META-Element enthalten ist oder der verwendete Zeichensatz
zufällig auch ohne Angabe dazu für den Browser heuristisch erkennbar ist.

> Nur im Fall der Paypal-Mails war das bisher anders, aber nicht deshalb,
> weil mein Programm Fehler macht, sondern weil der Absender einen Fehler
> gemacht hat (er hat seinen Mailclienten mit invalidem HTML gefüttert).
> Es ist aber nicht Sache meines Mailprogramms, ein Attachment so
> "aufzubereiten", dass absenderseitige Fehler ausgebügelt werden.
> Vielmehr müssen Attachments gleich welchen Formats beim Export
> bytegetreu auf der Platte landen. Mir ist auch kein Mailreader bekannt,
> bei dem das anders wäre.

Wenn man in Thunderbird eine E-Mail im HTML-Format als HTML-Datei
speichert, landet nicht der HTML-Teil unverändert als Datei auf der
Festplatte. Der HTML-Teil wird auch gar nicht als Anhang dargestellt,
sondern als *Inhalt* der E-Mail.

Message has been deleted

Michael Landenberger

unread,

Jul 1, 2012, 7:58:40 PM7/1/12

to

Am 01.07.2012 21:56, schrieb Thomas 'PointedEars' Lahn:

> Michael Landenberger wrote:
>
>> Thomas 'PointedEars' Lahn:
>>> (Maskierung von Umlauten),
>>
>> Ich wüsste nicht, wo ich geschrieben habe, dass mein Mailclient Umlaute
>> maskiert (auch das tut er nicht).
>
> Du erwähntest mehrfach die *scheinbar* notwendige "Codierung" von "ä"
> mittels "ä".

Das heißt aber noch lange nicht, dass ich das umgesetzt hätte.

>>> und unterlässt dafür Dinge, die er sinnvollerweise tun sollte
>>> (Mitliefern von persistenter Information über die Zeichencodierung der
>>> Ressource).
>>
>> Wenn du mir verrätst, wie man eine solche Information in ein
>> HTML-Dokument schreibt, *ohne* das Dokument selbst dabei zu verändern,
>> dann werde ich das gerne umsetzen.
>
> Wie Du inzwischen wissen solltest: Falls das HTML-Dokument nicht die
> richtige Meta-Information über die Zeichencodierung bereitstellt

Das HTML-Dokument stellt sehr wohl eine Meta-Information über die
Zeichencodierung bereit. Diese muss aber ignoriert werden, sofern das
HTML-Dokument im Mailreader selbst verarbeitet wird und es eine
Zeichensatzdeklaration im MIME-Header gibt. Wird das HTML-Dokument
jedoch in eine Datei exportiert und in einem externen Renderer
verarbeitet, enthält es keine MIME-Header mehr, sondern nur noch die
Meta-Information. In diesem Fall darf die Meta-Information nicht
ignoriert werden.

Leider ist das alles aber nicht das Hauptproblem. Das Hauptproblem ist
(kaputter) HTML-Quelltext, der unabhängig davon, ob die Meta-Information
beachtet oder ignoriert wird, ungültige Zeichen enthält. Wird die
Meta-Information *nicht* beachtet (wie es bei mailreader-interner
Verarbeitung gefordert wird), ist der HTML-Quelltext so zu behandeln,
als enthielte er *keine* Zeichensatzdeklaration. Dann dürfen aber auch
keine unmaskierten Umlaute enthalten sein. Wird die Meta-Information
dagegen beachtet (das ist nach einem Export und anschließender
Darstellung in einem externen Browser der Fall) und enthält diese
Information eine UTF-8-Zeichensatzdeklaration, dann darf der
HTML-Quelltext ebenfalls keine uncodierten Umlaute enthalten. Da die
Paypal-Mails in *beiden* Fällen gegen diese Regeln verstoßen, ist der in
ihnen enthaltene HTML-Quelltext kaputt, während sich mein Mailreader
vollkommen korrekt verhält. Ihm fehlte lediglich die Heuristik, mit der
er den fehlerhaften HTML-Quelltext reparieren kann.

Inzwischen bin ich aber schon etwas weiter. Ich habe meinen Mailclient
inzwischen so umprogrammiert, dass er zur Darstellung von HTML-Mails
keinen externen Browser mehr benötigt, d. h. er kann HTML-Mails
inzwischen auch selbst darstellen und muss HTML-Mails nicht mehr auf dem
Umweg über eine exportierte Datei in einem externen Browser öffnen. Zur
internen HTML-Darstellung verwende ich besagtes
Internet-Explorer-ActiveX-Control.

Da der Mailclient nun zwischen interner Darstellung und Dateiexport
unterscheiden kann, kann er den HTML-Quelltext auch auf 2 verschiedene
Arten aufbereiten. Bei der Übergabe von HTML-Content an das intern
verwendete ActiveX-Control (und nur dann!) entfernt der Client evtl.
vorhandene Meta-Tags mit Zeichensatzdeklarationen. Dadurch stellt er
sicher, dass bei der *internen* HTML-Darstellung tatsächlich nur die
Zeichensatzdeklaration im MIME-Header berücksichtigt wird. Beim Export
in eine .HTM-Datei lässt er die Meta-Tags dagegen unangetastet. Ein
*externer* Browser kann daher für die Darstellung von exportiertem HTML
die Zeichensatzdeklaration im Meta-Tag verwenden. Außerdem erfüllt der
Mailclient nach wie vor meine Forderung nach einem bytegetreuen Export
von Dateianhängen.

Und glücklicherweise ist es nun so, dass zumindest das intern verwendete
IE-ActiveX-Control offenbar Heuristiken enthält, durch die auch falsch
deklarierte Sonderzeichen richtig dargestellt werden. Folge: selbst die
unmaskierten Umlaute in den (kaputten) Paypal-Mails werden richtig
dargestellt. Das korrekt encodierte HTML in allen anderen HTML-Mails
natürlich sowieso, aber das war auch schon bisher der Fall.

Und schon ist mein Problem aus der Welt ;-) Ob ich allerdings weiterhin
ein IE-ActiveX zur HTML-Darstellung verwenden möchte, muss ich erst noch
sehen.

Gruß

Michael

Michael Landenberger

unread,

Jul 1, 2012, 8:11:20 PM7/1/12

to

Am 01.07.2012 23:24, schrieb Arno Welzel:

> Michael Landenberger, 01.07.2012 20:17:

>> Ich behandle HTML-Attachments genauso wie jedes andere Attachment auch:
>> ich decodiere sie gemäß MIME-Header und schreibe das Ergebnis auf die
>
> D.h. Du schaust in "Content-Transfer-Encoding",

Des MIME-Headers!

> um daraus wieder Oktette
> zu basteln. Und was machst Du mit der charset-Angabe im Content-Type?

Welchem Content-Type? Dem im HTML-Quelltext? Ja, den beachte ich nicht.
Beim Export einer Datei gleich welchen Typs ist mir der Dateiinhalt
grundsätzlich wurscht. Ich decodiere die Daten gemäß MIME-Header und
exportiere sie dann völlig wertfrei auf die Festplatte.

> Wenn man in Thunderbird eine E-Mail im HTML-Format als HTML-Datei
> speichert, landet nicht der HTML-Teil unverändert als Datei auf der
> Festplatte. Der HTML-Teil wird auch gar nicht als Anhang dargestellt,
> sondern als *Inhalt* der E-Mail.

Tja, bei meinem Mailclient ist das eben anders. Grundsätzlich stellt er
den HTML-Teil zwar auch als Inhalt der Mail dar (im Gegensatz zu
Thunderbird aber nicht automatisch, sondern nur auf ausdrücklichen
Wunsch des Benutzers). Wer möchte, kann den HTML-Teil der Mail aber wie
jeden anderen Mail-Anhang auch als Datei speichern oder in einem
externen Programm öffnen. In diesem Fall wird *nur* der HMTL-Teil der
E-Mail ohne irgendwelche Zusätze wie z. B. MIME-Header gespeichert bzw.
geöffnet. Diese Möglichkeit ist aber nicht neu und auch nicht meine
Erfindung: es gibt sie z. B. auch bei Outlook Express.

Die komplette Mail incl. HTML zu speichern geht aber natürlich auch. In
diesem Fall landet der komplette Mail-Quelltext incl. Header und Body
als .EML-Datei auf der Festplatte.

Gruß

Michael

Michael Landenberger

unread,

Jul 1, 2012, 8:25:00 PM7/1/12

to

Am 01.07.2012 22:02, schrieb Ralf Döblitz:

> Bullshit, lies doch *endlich* mal die einschlägigen Standards.

Gerne. Welche sollen das sein?

> In HTML
> muß man gar kein Charset deklarieren, denn es ist ein Default vorge-
> geben. Und der lautet *nicht* ASCII.

Wie lautet er dann?

> Daher ist es auch überhaupt kein
> Problem, wenn man die "Sonderzeichen" in genau diesem default charset in
> ein HTML-Dokument reinschreibt.

Leider sehen das die von mir verwendeten Browser anders. Zumindest
scheinen sie 8bit-Zeichen in HTML-Quelltext *ohne*
Zeichensatzdeklaration nicht dem von dir erwähnten ominösen
"Default-Zeichensatz" zuordnen zu können. Stattdessen malen sie für
jeden unmaskierten Umlaut ein hübsches schwarzes Kästchen auf die Seite.

Fügt man in den HTML-Quelltext dagegen z. B. eine
ISO-8859-1-Zeichensatzdeklaration ein, erscheinen wie von Zauberhand die
korrekten Umlaute. Leider darf diese Methode bei der Darstellung von
HTML-Mails nicht angewandt werden, denn da ist ja der MIME-Header zu
beachten und HTML-Meta-Tags zu ignorieren.

> Also ist es offensichtlich AUfgabe des MUA, das Meta-Tag rauszuwerfen

Diese Aufgabe hat der MUA allenfalls dann, wenn er das HTML intern
darstellt. Exportiert er es jedoch in eine Datei (zwecks Darstellung mit
einem externen Programm), darf er die Tags keinesfalls verändern. Ein
MUA, der Anhänge beim Exportieren verändert, ist kaputt. Außerdem
braucht ein externes Programm die Meta-Tags zur korrekten Darstellung.
Auch aus diesem Grund darf sie der MUA beim Export nicht verändern.

> und durch ein passendes, das die Daten aus dem MIME-header enthält zu
> ersetzen - denn genau dafür ist eben jenes Meta-Tag da.

Diese Aussage sehe ich als falsch an. Entweder die
Zeichensatzdeklaration bleibt unverändert drin (beim Export in eine
Datei) oder sie wird nicht verändert, sondern komplett rausgeschmissen
(für die interne Darstellung). Ein Ersatz durch eine andere Deklaration
ist in keinem von beiden Fällen nötig.

Gruß

Michael

Michael Landenberger

unread,

Jul 1, 2012, 8:39:45 PM7/1/12

to

Am 01.07.2012 23:14, schrieb Arno Welzel:

> Wir reden hier über HTML, dass den *Inhalt* der Mail darstellt, keinen
> Dateianhang im klassischen Sinn.

Da HTML-Content in Mails aber in aller Regel sämtliche Eigenschaften
eines klassischen Dateianhangs aufweist, behandle ich ihn auch als
solchen. Damit bin ich nicht allein. Es gibt auch noch andere
Mailclients, die ebenso verfahren.

> Wie gehst Du damit um, wenn ein HTML-Dokument als UTF-8 ankommt, aber
> keinen META-Header dazu enthält, sondern nur ein MIME-Header dafür
> vorhanden ist?

Ich decodiere das Dokument wie ein UTF-8-Dokument und verfüttere es
anschließend an den HTML-Renderer.

> Beim Export wird die Information dann einfach verworfen

Ja. Wenn das HTML-Dokument selbst keine Zeichensatzdeklaration enthält,
dann fügt mein MUA auch keine nachträglich hinzu. Er hellt ja auch
unterbelichtete JPEG-Anhänge nicht auf und korrigiert auch keine
Rechtschreibfehler in angehängten Word-Docs.

> Nein TB und Outlook machen einfach das, was vorgegeben ist: Sie beachten
> nur die Angabe im MIME-Header, die die Angabe im META-Element innerhalb
> des Dokumentes überschreibt.

Ich glaube nicht, dass sie das tun. Die Forderung lautet ja, die Angabe
im Meta-Element zu ignorieren, wenn ein entsprechender MIME-Header
vorhanden ist. Also wird das Meta-Element vermutlich nicht
überschrieben, sondern schlicht rausgeschmissen (genau das macht mein
MUA mittlerweile auch). Diese Methode ist aber *nur* bei interner
Darstellung zulässig, weil dabei der (veränderte) HTML-Quelltext in
keinem externen Programm verarbeitet werden muss. Sobald man den
HTML-Quelltext exportiert, darf er nicht mehr verändert werden. D. h.
das Meta-Element bleibt drin und der MIME-Header wird nicht in die
exportierte Datei geschrieben. Genau so verfährt mein MUA inzwischen und
bisher gab es dadurch keine Probleme.

xpost & fup2 de.comm.software.mailreader.misc

Gruß

Michael

Arno Welzel

unread,

Jul 2, 2012, 5:05:32 AM7/2/12

to

Am 02.07.2012 02:39, schrieb Michael Landenberger:

> Am 01.07.2012 23:14, schrieb Arno Welzel:
>
>> Wir reden hier über HTML, dass den *Inhalt* der Mail darstellt, keinen
>> Dateianhang im klassischen Sinn.
>
> Da HTML-Content in Mails aber in aller Regel sämtliche Eigenschaften
> eines klassischen Dateianhangs aufweist, behandle ich ihn auch als
> solchen. Damit bin ich nicht allein. Es gibt auch noch andere
> Mailclients, die ebenso verfahren.
>
>> Wie gehst Du damit um, wenn ein HTML-Dokument als UTF-8 ankommt, aber
>> keinen META-Header dazu enthält, sondern nur ein MIME-Header dafür
>> vorhanden ist?
>
> Ich decodiere das Dokument wie ein UTF-8-Dokument und verfüttere es
> anschließend an den HTML-Renderer.

"Decodieren wie ein UTF-8-Dokument"?

Du meinst vermutlich, dass Du entsprechend dem Transport-Encoding den
Inhalt des HTML-Teils wiederherstellst. Denn ob das, was Du da vor Dir
hast, UTF-8 ist oder nicht, ist für diesen Schritt komplett irrelevant.
Ein Anhang mit Transport-Encoding "base64" wird nicht anders decodiert,
nur weil der Inhalt UTF-8 ist, sondern entscheidend ist die Art, wie man
aus base64 wieder Oktette macht.

Sehr wohl muss dann aber der HTML-Renderer wissen, welcher Zeichensatz
für das Dokument gilt - und wenn da keine META-Angabe vorhanden ist oder
diese der MIME-Angabe widerspricht, ist die Anzeige eben ggf. fehlerhaft.

>> Beim Export wird die Information dann einfach verworfen
>
> Ja. Wenn das HTML-Dokument selbst keine Zeichensatzdeklaration enthält,
> dann fügt mein MUA auch keine nachträglich hinzu. Er hellt ja auch
> unterbelichtete JPEG-Anhänge nicht auf und korrigiert auch keine
> Rechtschreibfehler in angehängten Word-Docs.

Das ist auch nicht das selbe.

>> Nein TB und Outlook machen einfach das, was vorgegeben ist: Sie beachten
>> nur die Angabe im MIME-Header, die die Angabe im META-Element innerhalb
>> des Dokumentes überschreibt.
>
> Ich glaube nicht, dass sie das tun. Die Forderung lautet ja, die Angabe
> im Meta-Element zu ignorieren, wenn ein entsprechender MIME-Header
> vorhanden ist. Also wird das Meta-Element vermutlich nicht

Eben - genau das tut TB ja auch. Du kannst es gerne ausprobieren.

> überschrieben, sondern schlicht rausgeschmissen (genau das macht mein
> MUA mittlerweile auch). Diese Methode ist aber *nur* bei interner
> Darstellung zulässig, weil dabei der (veränderte) HTML-Quelltext in
> keinem externen Programm verarbeitet werden muss. Sobald man den

Das tut TB wiederum nicht - leicht nachstellbar mit Strg+U in der
Ansicht einer Mail im HTML-Format. TB teilt dem HTML-Renderer halt den
zu verwendenden Zeichensatz mit, wodurch dieser die META-Angabe ignoriert.

> HTML-Quelltext exportiert, darf er nicht mehr verändert werden. D. h.
> das Meta-Element bleibt drin und der MIME-Header wird nicht in die
> exportierte Datei geschrieben. Genau so verfährt mein MUA inzwischen und
> bisher gab es dadurch keine Probleme.

Wenn Du das META-Element ohnehin schon anfasst - was wäre daran so
schlimm, das mit dem Inhalt des MIME-Headers zu überschreiben, wenn dort
ein abweichender Zeichensatz angegeben ist? Das würde den Nutzern des
Programms viel Nerven ersparen, wenn sie Mails bekommen, wo der
MIME-Header etwas andere vorgibt, als die META-Angabe.

Arno Welzel

unread,

Jul 2, 2012, 5:13:08 AM7/2/12

to

Am 02.07.2012 02:11, schrieb Michael Landenberger:
> Am 01.07.2012 23:24, schrieb Arno Welzel:
>
>> Michael Landenberger, 01.07.2012 20:17:
>
>>> Ich behandle HTML-Attachments genauso wie jedes andere Attachment auch:
>>> ich decodiere sie gemäß MIME-Header und schreibe das Ergebnis auf die
>>
>> D.h. Du schaust in "Content-Transfer-Encoding",
>
> Des MIME-Headers!
>
>> um daraus wieder Oktette
>> zu basteln. Und was machst Du mit der charset-Angabe im Content-Type?
>
> Welchem Content-Type? Dem im HTML-Quelltext? Ja, den beachte ich nicht.

Nein, den im MIME-Header.

> Beim Export einer Datei gleich welchen Typs ist mir der Dateiinhalt
> grundsätzlich wurscht. Ich decodiere die Daten gemäß MIME-Header und
> exportiere sie dann völlig wertfrei auf die Festplatte.

Und das funktioniert eben nur, solange ein META-Header im HTML-Dokument ist.

Gut - man kann sich auf den Standpunkt stellen, dass das nicht das
Problem des Clients ist, wenn gespeicherte HTML-Datein nicht mehr
korrekt darstellbar sind, weil der Absender die META-Angabe vergessen
oder falsch gesetzt hat. Schön ist das trotzdem nicht - und als
Programmautor darf man ggf. den Anwendern erstmal erklären, warum die
Umlaute in der gespeicherten Datei falsch sind, wenn sie doch im
Mailclient noch korrekt angezeigt wurden.

Michael Landenberger

unread,

Jul 2, 2012, 8:04:26 AM7/2/12

to

Am 02.07.2012 11:13, schrieb Arno Welzel:

> Am 02.07.2012 02:11, schrieb Michael Landenberger:

>> Beim Export einer Datei gleich welchen Typs ist mir der Dateiinhalt
>> grundsätzlich wurscht. Ich decodiere die Daten gemäß MIME-Header und
>> exportiere sie dann völlig wertfrei auf die Festplatte.
>
> Und das funktioniert eben nur, solange ein META-Header im HTML-Dokument
> ist.

Es lassen sich durchaus auch HTML-Dateien ohne Meta-Header exportieren.
Die werden im Browser sogar korrekt dargestellt, solange sie keine bzw.
nur maskierte 8bit-Zeichen enthalten.

> Gut - man kann sich auf den Standpunkt stellen, dass das nicht das
> Problem des Clients ist, wenn gespeicherte HTML-Datein nicht mehr
> korrekt darstellbar sind, weil der Absender die META-Angabe vergessen
> oder falsch gesetzt hat.

Genau auf diesen Standpunkt stelle ich mich auch. Wie geschrieben, muss
ein MUA beim Datei-Export auch keine unterbelichteten JPEGs aufhellen
oder Rechtschreibfehler in Word-Docs korrigieren. Das ist einfach nicht
das Problem des MUA.

> Schön ist das trotzdem nicht - und als
> Programmautor darf man ggf. den Anwendern erstmal erklären, warum die
> Umlaute in der gespeicherten Datei falsch sind, wenn sie doch im
> Mailclient noch korrekt angezeigt wurden.

Glücklicherweise habe ich bisher außer von PayPal keine Mails erhalten,
bei denen man beim Exportieren kaputtes HTML erhält (die Paypal-Mails
enthalten HTML mit UTF-8-Deklaration, aber uncodierten Umlauten im
Quelltext). Und irgendwo muss die Toleranz eines Mailclients gegenüber
schrottigem Content auch eine Grenze haben. Mir reicht es jedenfalls,
dass mein Mailclient auch die Paypal-Mails wenigstens dann korrekt
darstellt, wenn er sie mittels des eingebetteten IE-ActiveX-Controls
selbst rendert. Und da das HTML dabei auch nicht exportiert werden muss,
kann es der MUA ganz nach Bedarf verändern (was sich bei interner
Darstellung sowieso kaum vermeiden lässt, denn es muss ja nicht nur der
Zeichensatz durch die MIME-Deklaration ersetzt, sondern ggf. auch die
Verweise auf eingebettete Bilder und andere Elemente an deren lokalen
Speicherort angepasst werden).

Nachdem ich meinem MUA die interne HTML-Darstellung hinzugefügt habe,
ist der Export von HTML auch deutlich unwichtiger geworden.

Gruß

Michael

Michael Landenberger

unread,

Jul 2, 2012, 8:22:11 AM7/2/12

to

Am 02.07.2012 11:05, schrieb Arno Welzel:

> Am 02.07.2012 02:39, schrieb Michael Landenberger:

>>> Wie gehst Du damit um, wenn ein HTML-Dokument als UTF-8 ankommt, aber
>>> keinen META-Header dazu enthält, sondern nur ein MIME-Header dafür
>>> vorhanden ist?
>>
>> Ich decodiere das Dokument wie ein UTF-8-Dokument und verfüttere es
>> anschließend an den HTML-Renderer.
>
> "Decodieren wie ein UTF-8-Dokument"?

Um Missverständnisse zu vermeiden, sollte immer klargestellt werden,
*welche* Zeichensatzdeklaration gemeint ist. Ich bin davon ausgegangen,
dass du die MIME-Zeichensatzdeklaration meinst. Und wenn in den
MIME-Headern UTF-8 als Zeichensatz deklariert ist, decodiere ich das
zugehörige Dokument eben als UTF-8. Ein evtl. vorhandenes HTML-Meta-Tag
ignoriere ich dabei. Allerdings lasse ich das Meta-Tag zumindest beim
Dateiexport drin und verändere es nicht. Nur bei der internen
Darstellung entferne ich es aus dem Quelltext, damit wirklich nur die
MIME-Zeichensatzdeklaration zum Tragen kommt.

> Sehr wohl muss dann aber der HTML-Renderer wissen, welcher Zeichensatz
> für das Dokument gilt - und wenn da keine META-Angabe vorhanden ist oder
> diese der MIME-Angabe widerspricht, ist die Anzeige eben ggf. fehlerhaft.

Bisher hat es gut funktioniert, wenn ich das HTML zunächst gemäß
MIME-Header decodiere, anschließend ein evtl. vorhandenes Meta-Tag aus
dem decodierten HTML rausschmeiße (bei vorhandener MIME-Deklaration soll
die Deklaration im Meta-Tag ja ignoriert werden) und das Ergebnis dann
an den HTML-Renderer verfüttere. Damit hatte ich bisher noch keine
Darstellungsprobleme, auch mit dem kaputten HTML in den Paypal-Mails
nicht. Sollte ich das erste Mal auf Probleme stoßen, werde ich mein
Programm dahingehend ändern, dass es HTML-Meta-Tags nicht rausschmeißt,
sondern mit der Zeichensatz-Information aus dem MIME-Header überschreibt.

> Wenn Du das META-Element ohnehin schon anfasst - was wäre daran so
> schlimm, das mit dem Inhalt des MIME-Headers zu überschreiben, wenn dort
> ein abweichender Zeichensatz angegeben ist?

Das wäre nicht schlimm, nur aufwendiger. Ich hatte es schon mit
HTML-Mails mit den unterschiedlichsten Formaten in den Meta-Tags zu tun.
Mal steht "<meta http-equiv..." ganz vorne im Tag, mal steht es in der
Mitte oder auch hinten. Mal sind die Feldnamen und Werte innerhalb des
Tags in Anführungszeichen eingeschlossen, ein anderes Mal wieder nicht.
Manche Meta-Tags enthalten Leerzeichen vor und hinter
Gleichheitszeichen, andere wieder nicht. Das alles beim Parsing zu
berücksichtigen, ist aufwendiger als das komplette Tag einfach
rauszuschmeißen. Auf Dauer werde ich aber vermutlich nicht darum
herumkommen.

> Das würde den Nutzern des
> Programms viel Nerven ersparen, wenn sie Mails bekommen, wo der
> MIME-Header etwas andere vorgibt, als die META-Angabe.

Das ist zwar richtig, aber solche Mails sind nach meiner Erfahrung recht
selten. Trotzdem werde ich natürlich zukünftig auch diese Fälle
berücksichtigen. Im Moment gibt es aber noch andere, wichtigere
Baustellen in meinem Mailclient ;-)

Gruß

Michael

Arno Welzel

unread,

Jul 2, 2012, 11:17:48 AM7/2/12

to

Am 02.07.2012 14:22, schrieb Michael Landenberger:

> Am 02.07.2012 11:05, schrieb Arno Welzel:
>
>> Am 02.07.2012 02:39, schrieb Michael Landenberger:
>
>>>> Wie gehst Du damit um, wenn ein HTML-Dokument als UTF-8 ankommt, aber
>>>> keinen META-Header dazu enthält, sondern nur ein MIME-Header dafür
>>>> vorhanden ist?
>>>
>>> Ich decodiere das Dokument wie ein UTF-8-Dokument und verfüttere es
>>> anschließend an den HTML-Renderer.
>>
>> "Decodieren wie ein UTF-8-Dokument"?
>
> Um Missverständnisse zu vermeiden, sollte immer klargestellt werden,
> *welche* Zeichensatzdeklaration gemeint ist. Ich bin davon ausgegangen,
> dass du die MIME-Zeichensatzdeklaration meinst. Und wenn in den
> MIME-Headern UTF-8 als Zeichensatz deklariert ist, decodiere ich das
> zugehörige Dokument eben als UTF-8. Ein evtl. vorhandenes HTML-Meta-Tag

Wieso hängt die Art der Dekodierung vom Zeichensatz ab?

Also - im MIME-Header steht z.B.:

Content-Transfer-Encoding: quoted-printable

Dann ist der entsprechende Inhalt eben als quoted-printable zu lesen.
Irgendwelche Umformungen. Ein "=E4" wir dann zu einem Oktett mit dem
Wert 0xE4 - egal, ob im Content-Type als Zeichensatz dann ISO-8859-1
oder UTF-8 angegeben ist.

> ignoriere ich dabei. Allerdings lasse ich das Meta-Tag zumindest beim
> Dateiexport drin und verändere es nicht. Nur bei der internen
> Darstellung entferne ich es aus dem Quelltext, damit wirklich nur die
> MIME-Zeichensatzdeklaration zum Tragen kommt.

Und woher weiss der Renderer dann, welcher Zeichensatz verwendet werden
soll? Gibst Du diese Angabe aus dem Content-Type auf andere Weise weiter?

>> Sehr wohl muss dann aber der HTML-Renderer wissen, welcher Zeichensatz
>> für das Dokument gilt - und wenn da keine META-Angabe vorhanden ist oder
>> diese der MIME-Angabe widerspricht, ist die Anzeige eben ggf. fehlerhaft.
>
> Bisher hat es gut funktioniert, wenn ich das HTML zunächst gemäß
> MIME-Header decodiere, anschließend ein evtl. vorhandenes Meta-Tag aus
> dem decodierten HTML rausschmeiße (bei vorhandener MIME-Deklaration soll
> die Deklaration im Meta-Tag ja ignoriert werden) und das Ergebnis dann

Ja - bei vorhandener MIME-Deklaration soll der, der das Ding *anzeigt*,
den META-Header ignorieren. Was Du aber faktisch machst, Du schmeisst
offenbar *jede* Art von Zeichensatzangabe raus.

> an den HTML-Renderer verfüttere. Damit hatte ich bisher noch keine
> Darstellungsprobleme, auch mit dem kaputten HTML in den Paypal-Mails
> nicht. Sollte ich das erste Mal auf Probleme stoßen, werde ich mein
> Programm dahingehend ändern, dass es HTML-Meta-Tags nicht rausschmeißt,
> sondern mit der Zeichensatz-Information aus dem MIME-Header überschreibt.

Das wirst Du aufgrund der Heuristik der Browser beim Fehlen jeglicher
Zeichensatzangabe vermutlich nicht so schnell erleben - die zeigen UTF-8
notfalls auch ohne BOM und META-Angabe noch korrekt an, weil sie auf
typische Bytefolgen in UTF-8 prüfung oder ISO-8859-2 anhand der
Häufigkeit bestimmter Codepunkte, die es zwar in ISO-8859-1 auch gibt,
aber dort nur selten verwendet werden.

>> Wenn Du das META-Element ohnehin schon anfasst - was wäre daran so
>> schlimm, das mit dem Inhalt des MIME-Headers zu überschreiben, wenn dort
>> ein abweichender Zeichensatz angegeben ist?
>
> Das wäre nicht schlimm, nur aufwendiger. Ich hatte es schon mit
> HTML-Mails mit den unterschiedlichsten Formaten in den Meta-Tags zu tun.
> Mal steht "<meta http-equiv..." ganz vorne im Tag, mal steht es in der
> Mitte oder auch hinten. Mal sind die Feldnamen und Werte innerhalb des
> Tags in Anführungszeichen eingeschlossen, ein anderes Mal wieder nicht.
> Manche Meta-Tags enthalten Leerzeichen vor und hinter
> Gleichheitszeichen, andere wieder nicht. Das alles beim Parsing zu
> berücksichtigen, ist aufwendiger als das komplette Tag einfach
> rauszuschmeißen. Auf Dauer werde ich aber vermutlich nicht darum
> herumkommen.

Du musst das Tag doch nicht parsen - einfach rauswerfen und durch ein
Eigenes mit den Angaben aus dem MIME-Content-Type-Header ersetzen,
wenigstens für die Anzeige.

>> Das würde den Nutzern des
>> Programms viel Nerven ersparen, wenn sie Mails bekommen, wo der
>> MIME-Header etwas andere vorgibt, als die META-Angabe.
>
> Das ist zwar richtig, aber solche Mails sind nach meiner Erfahrung recht
> selten. Trotzdem werde ich natürlich zukünftig auch diese Fälle
> berücksichtigen. Im Moment gibt es aber noch andere, wichtigere
> Baustellen in meinem Mailclient ;-)

Aber immerhin hast Du jetzt eine Vorstellung davon bekommen, wie komplex
selbst manche scheinbar einfach zu lösenden Aufgaben werden können ;-)

Thomas 'PointedEars' Lahn

unread,

Jul 2, 2012, 1:14:24 PM7/2/12

to

Michael Landenberger wrote:

> Am 01.07.2012 21:56, schrieb Thomas 'PointedEars' Lahn:
>> Michael Landenberger wrote:
>>> Thomas 'PointedEars' Lahn:
>>>> (Maskierung von Umlauten),
>>> Ich wüsste nicht, wo ich geschrieben habe, dass mein Mailclient Umlaute
>>> maskiert (auch das tut er nicht).
>> Du erwähntest mehrfach die *scheinbar* notwendige "Codierung" von "ä"
>> mittels "ä".
>
> Das heißt aber noch lange nicht, dass ich das umgesetzt hätte.

Gut.

>>>> und unterlässt dafür Dinge, die er sinnvollerweise tun sollte
>>>> (Mitliefern von persistenter Information über die Zeichencodierung der
>>>> Ressource).
>>>
>>> Wenn du mir verrätst, wie man eine solche Information in ein
>>> HTML-Dokument schreibt, *ohne* das Dokument selbst dabei zu verändern,
>>> dann werde ich das gerne umsetzen.
>>
>> Wie Du inzwischen wissen solltest: Falls das HTML-Dokument nicht die
>> richtige Meta-Information über die Zeichencodierung bereitstellt
>
> Das HTML-Dokument stellt sehr wohl eine Meta-Information über die

> Zeichencodierung bereit. Diese muss aber ignoriert werden, […]

Du könntest meine Postings zur Abwechslung mal vollständig lesen. Ich habe
lediglich Deine Frage beantwortet. Wenn Dich die Antwort nicht interessiert
und Du (mir) stattdessen immer wieder das erzählen willst, was (mir) bereits
(hinlänglich) bekannt ist, stell keine Fragen.

> […]

> Leider ist das alles aber nicht das Hauptproblem. Das Hauptproblem ist
> (kaputter) HTML-Quelltext, der unabhängig davon, ob die Meta-Information
> beachtet oder ignoriert wird, ungültige Zeichen enthält.

Es gibt keine ungültigen Zeichen. Es gibt nur Codesequenzen, die in einer
Zeichencodierung keinem Codepunkt und damit auch keinem Zeichen zugeordnet
werden können. Dafür kann es zwei Ursachen geben: Entweder passt die
Codesequenz nicht zur vorgegebenen Codierung, oder die angenommene Codierung
passt nicht zur Codesequenz.

> Wird die Meta-Information *nicht* beachtet (wie es bei mailreader-interner
> Verarbeitung gefordert wird), ist der HTML-Quelltext so zu behandeln,
> als enthielte er *keine* Zeichensatzdeklaration.

Fhcsal.

> Dann dürfen aber auch keine unmaskierten Umlaute enthalten sein.

Ex falso quodlibet.

> Inzwischen bin ich aber schon etwas weiter. Ich habe meinen Mailclient
> inzwischen so umprogrammiert, dass er zur Darstellung von HTML-Mails
> keinen externen Browser mehr benötigt, d. h. er kann HTML-Mails
> inzwischen auch selbst darstellen und muss HTML-Mails nicht mehr auf dem
> Umweg über eine exportierte Datei in einem externen Browser öffnen.
> Zur internen HTML-Darstellung verwende ich besagtes
> Internet-Explorer-ActiveX-Control.

Vielen Dank fuer die Einhaltung aller Sicherheitsvorschriften. [dsf 7.1]

> […]

> Und glücklicherweise ist es nun so, dass zumindest das intern verwendete
> IE-ActiveX-Control offenbar Heuristiken enthält, durch die auch falsch
> deklarierte Sonderzeichen richtig dargestellt werden. Folge: selbst die
> unmaskierten Umlaute in den (kaputten) Paypal-Mails werden richtig
> dargestellt. Das korrekt encodierte HTML in allen anderen HTML-Mails
> natürlich sowieso, aber das war auch schon bisher der Fall.
>
> Und schon ist mein Problem aus der Welt ;-) Ob ich allerdings weiterhin
> ein IE-ActiveX zur HTML-Darstellung verwenden möchte, muss ich erst noch
> sehen.

Dir sollte klar sein, dass das Problem so nur *scheinbar* gelöst ist.

Thomas 'PointedEars' Lahn

unread,

Jul 2, 2012, 1:16:17 PM7/2/12

to

Michael Landenberger wrote:

> Am 02.07.2012 11:13, schrieb Arno Welzel:
>> Am 02.07.2012 02:11, schrieb Michael Landenberger:
>>> Beim Export einer Datei gleich welchen Typs ist mir der Dateiinhalt
>>> grundsätzlich wurscht. Ich decodiere die Daten gemäß MIME-Header und
>>> exportiere sie dann völlig wertfrei auf die Festplatte.
>>
>> Und das funktioniert eben nur, solange ein META-Header im HTML-Dokument
>> ist.
>
> Es lassen sich durchaus auch HTML-Dateien ohne Meta-Header exportieren.
> Die werden im Browser sogar korrekt dargestellt, solange sie keine bzw.
> nur maskierte 8bit-Zeichen enthalten.

Du kannst Dir auch ein Loch ins Knie schlagen, einen Kaktus reinsetzen, den
mit Essig giessen, und hoffen, dass er wächst.

kopfschüttelnd,

Thomas 'PointedEars' Lahn

unread,

Jul 2, 2012, 1:28:36 PM7/2/12

to

Ralf Döblitz wrote:

> Michael Landenberger <spameim...@arcor.de> schrieb:
> [...]

>> [1] HTML-Darstellung innerhalb des Mailreaders: regelkonform wird nur
>> der MIME-Header berücksichtigt, das HTML-Meta-Tag nicht. Das ist
>> gleichbedeutend mit einer fehlenden Zeichensatzdeklaration im
>> HTML-Quelltext. Sonderzeichen im HTML-Quelltext müssen dann maskiert
>> sein. Sind sie es nicht, handelt es sich um invalides HTML.
>

> Bullshit, lies doch *endlich* mal die einschlägigen Standards. In HTML

> muß man gar kein Charset deklarieren, denn es ist ein Default vorge-

> geben. Und der lautet *nicht* ASCII. Daher ist es auch überhaupt kein

> Problem, wenn man die "Sonderzeichen" in genau diesem default charset in
> ein HTML-Dokument reinschreibt.

Du irrst:

,-<http://www.w3.org/TR/REC-html40/charset.html#h-5.2.2>
|
| The HTTP protocol ([RFC2616], section 3.7.1) mentions ISO-8859-1 as a
| default character encoding when the "charset" parameter is absent from the
| "Content-Type" header field. In practice, this recommendation has proved
| useless because some servers don't allow a "charset" parameter to be sent,
| and others may not be configured to send the parameter. Therefore, user
| agents must not assume any default value for the "charset" parameter.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Das entsprechende Kapitel ist normativ und das "MUST NOT" daher verbindlich.

In <http://www.w3.org/TR/html5/the-meta-element.html#charset> finde ich
nichts Gegenteiliges (normativ wäre es ohnehin nicht).

Eine von HTTP/1.1 abweichende Definition gilt es für XML-Dokumenttypen:
<http://www.w3.org/TR/REC-xml/#dt-character>

>> [2] HTML-Darstellung in einem externen Browser: der MIME-Header ist hier
>> nicht bekannt, weil er nicht in die exportierte .HTM-Datei geschrieben
>> wird. Also wertet der Browser hier das entsprechende HTML-Meta-Tag aus.
>> Die Zeichensatzdeklaration im Meta-Tag ist dann falsch, wenn in dieser
>> "UTF-8" als Zeichensatz deklariert ist, der Quelltext aber trotzdem
>> uncodierte Nicht-ASCII-Zeichen enthält.
>

> Also ist es offensichtlich AUfgabe des MUA, das Meta-Tag rauszuwerfen

> und durch ein passendes, das die Daten aus dem MIME-header enthält zu
> ersetzen - denn genau dafür ist eben jenes Meta-Tag da.

ACK.

Michael Landenberger

unread,

Jul 2, 2012, 2:37:53 PM7/2/12

to

Am 02.07.2012 17:17, schrieb Arno Welzel:

> Wieso hängt die Art der Dekodierung vom Zeichensatz ab?

Weil auch ein Zeichensatz wie z. B. UTF-8 decodiert werden muss. Oder
willst du Hexcodes wie z. B. "C3A4" (UTF-8 Code für "ä") in deiner Mail
lesen? Nein, du möchtest da ein "ä" lesen. Also muss C3A4 in "ä"
umgewandelt werden. Wenn "Decodierung" dafür der falsche Ausdruck ist,
dann bitte ich um Entschuldigung und wäre dir dankbar, wenn du mir den
richtigen Ausdruck nennen könntest.

> Also - im MIME-Header steht z.B.:
>
> Content-Transfer-Encoding: quoted-printable
>
> Dann ist der entsprechende Inhalt eben als quoted-printable zu lesen.

Selbstverständlich. Bei Quoted-Printable-Decodierung in Verbindung mit
UTF-Zeichensatz steht dann eben statt eines "ä" ein "=C3=A4" im
Quelltext. Daraus macht der Quoted-Printable-Decoder zunächst 2 Zeichen
mit den Byte-Repräsentationen 0xC3 und 0xB4. Anschließend verwandelt der
UTF-8-Decoder diese beiden Zeichen in ein "ä".

> Und woher weiss der Renderer dann, welcher Zeichensatz verwendet werden
> soll? Gibst Du diese Angabe aus dem Content-Type auf andere Weise weiter?

Nein, bisher noch nicht. Ich habe das jetzt aber mal mit der (kaputten)
Paypal-Mail versucht. So sieht es aus, wenn ich dem Renderer *keine*
Zeichensatzinformation mitgebe:
<http://www.alice-dsl.net/landenberger/bilder/HTML_ohne_Zeichensatz.png>

Das rot eingekreiste "ö" wird korrekt dargestellt. Das aber habe ich der
Heuristik des Renderers zu verdanken, denn das, was im Quelltext steht,
ist falsch: da steht das "ö" ebenso wie andere Sonderzeichen als
unmaskiertes "ö" und nicht als "ö".

Und so sieht es aus, wenn ich dem HTML-Renderer die
Zeichensatzinformation aus dem MIME-Header (UTF-8) mitgebe:
<http://www.alice-dsl.net/landenberger/bilder/HTML_mit_MIME_Zeichensatz.png>

Im Gegensatz zum ersten Beispiel wird das "ö" hier nicht mehr richtig
angezeigt, sondern durch einen Platzhalter ersetzt. Der Grund dafür ist
einfach: der Renderer bekommt jetzt eine Zeichensatzinformation und
richtet sich danach. Dementsprechend interpretiert er das Dokument als
UTF-8-Dokument. In einem solchen erwartet er aber keine unmaskierten
Sonderzeichen, sondern geht davon aus, dass Umlaute wie "ö" als
UTF-8-Bytecode codiert sind. Da das unmaskierte "ö" (Bytecode 0xF6) kein
gültiger UTF8-Code ist, kann der Renderer damit nichts anfangen und
zeigt stattdessen einen Platzhalter an.

Und damit auch klar wird, warum die Paypal-Mail kaputt ist, hier noch
ein paar Quelltext-Auszüge daraus:

----------------- Header -----------------
(...)
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
(...)
------------------------------------------

------------- HTML-Meta-Tags -------------
<head>

<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dutf-8" />
(...)
------------------------------------------

------------ Seitenquelltext -------------
(...)
Unvergessliche Momente stehen bevor.=20

Halten Sie sie in wundersch=F6nen Farben=20

und exzellenten HD-Videos fest.
(...)
------------------------------------------

Mein Mailer behandelt diese Mail wie folgt:
zunächst wird der Quelltext gemäß MIME-Header Quoted-printable
decodiert. Dadurch wird u. a. aus dem Wort "wundersch=F6nen" das Wort
"wunderschönen" (=F6 wird gemäß Quoted-printable-Codierung zu "ö"). Nun
ist also ein unmaskierter Umlaut im Quelltext enthalten.

Anschließend wird der so decodierte Quelltext an den Renderer
verfüttert. Dabei wird dem Renderer gleichzeitig die
Zeichensatzinformation aus dem MIME-Header (UTF-8) übermittelt. Also
interpretiert der Renderer den Quelltext als UTF-8-Dokument. In
UTF-8-Dokumenten gibt es aber keine unmaskierten "ö", denn der
zugehörige Bytecode 0xF6 ist kein gültiger UTF-8-Code. Folge: das "ö"
wird nicht korrekt angezeigt, sondern durch einen Platzhalter ersetzt.

Füttere ich den Renderer dagegen mit dem decodierten Quelltext, *ohne*
ihm eine Zeichensatz-Information zu übermitteln, muss er den verwendeten
Zeichensatz raten. Er stößt auf das "ö" im Quelltext und tippt anhand
dessen auf ISO-8859-1 (das ist wirklich nur geraten, denn eine derartige
Deklaration gibt es weder im MIME-Header noch im Meta-Tag!). Zufällig
liegt er mit ISO-8859-1 richtig und kann das "ö" richtig darstellen.

>> Bisher hat es gut funktioniert, wenn ich das HTML zunächst gemäß
>> MIME-Header decodiere, anschließend ein evtl. vorhandenes Meta-Tag aus
>> dem decodierten HTML rausschmeiße (bei vorhandener MIME-Deklaration soll
>> die Deklaration im Meta-Tag ja ignoriert werden) und das Ergebnis dann
>
> Ja - bei vorhandener MIME-Deklaration soll der, der das Ding *anzeigt*,
> den META-Header ignorieren. Was Du aber faktisch machst, Du schmeisst
> offenbar *jede* Art von Zeichensatzangabe raus.

Nein, das mache ich nicht. Ich schmeiße nur das Meta-Tag aus dem
HTML-Quellcode raus, weil das ja sowieso ignoriert werden soll. Die
Zeichensatzinformation im MIME-Header berücksichtige ich dagegen.

> Du musst das Tag doch nicht parsen - einfach rauswerfen und durch ein
> Eigenes mit den Angaben aus dem MIME-Content-Type-Header ersetzen,
> wenigstens für die Anzeige.

Ja, genau so habe ich es gemacht. Das Ergebnis zeigt der zweite der
beiden weiter oben verlinkten Screenshots :-(

> Aber immerhin hast Du jetzt eine Vorstellung davon bekommen, wie komplex
> selbst manche scheinbar einfach zu lösenden Aufgaben werden können ;-)

Ein wahres Wort gelassen ausgesprochen ;-)

Gruß

Michael

Peter J. Holzer

unread,

Jul 2, 2012, 3:00:48 PM7/2/12

to

On 2012-07-02 15:17, Arno Welzel <use...@arnowelzel.de> wrote:
> Am 02.07.2012 14:22, schrieb Michael Landenberger:
>> Am 02.07.2012 11:05, schrieb Arno Welzel:
>>> Am 02.07.2012 02:39, schrieb Michael Landenberger:
>>>>> Wie gehst Du damit um, wenn ein HTML-Dokument als UTF-8 ankommt, aber
>>>>> keinen META-Header dazu enthält, sondern nur ein MIME-Header dafür
>>>>> vorhanden ist?
>>>>
>>>> Ich decodiere das Dokument wie ein UTF-8-Dokument und verfüttere es
>>>> anschließend an den HTML-Renderer.
>>>
>>> "Decodieren wie ein UTF-8-Dokument"?
>>
>> Um Missverständnisse zu vermeiden, sollte immer klargestellt werden,
>> *welche* Zeichensatzdeklaration gemeint ist. Ich bin davon ausgegangen,
>> dass du die MIME-Zeichensatzdeklaration meinst. Und wenn in den
>> MIME-Headern UTF-8 als Zeichensatz deklariert ist, decodiere ich das
>> zugehörige Dokument eben als UTF-8. Ein evtl. vorhandenes HTML-Meta-Tag
>
> Wieso hängt die Art der Dekodierung vom Zeichensatz ab?

Es gibt (mindestens) zwei Dekodierungen.

> Also - im MIME-Header steht z.B.:
>
> Content-Transfer-Encoding: quoted-printable
>
> Dann ist der entsprechende Inhalt eben als quoted-printable zu lesen.
> Irgendwelche Umformungen. Ein "=E4" wir dann zu einem Oktett mit dem
> Wert 0xE4 - egal, ob im Content-Type als Zeichensatz dann ISO-8859-1
> oder UTF-8 angegeben ist.

ACK. Hier wird das Content-Transfer-Encoding dekodiert.

Das Ergebnis ist ein Bytestrom.

Um daraus einen Zeichenstrom zu machen, muss man das Character-Encoding
dekodieren, also aus einem oder mehreren Bytes wieder ein Zeichen
machen. Dieses Encoding entnimmt man dem charset-Parameter des
Content-Type Headers.

(Ob es sinnvoll ist, diese Dekodierung vom Parsen des HTML-Dokuments zu
trennen, ist eine andere Frage. Das hängt wohl hauptsächlich vom API des
HTML-Parsers ab)

>> ignoriere ich dabei. Allerdings lasse ich das Meta-Tag zumindest beim
>> Dateiexport drin und verändere es nicht. Nur bei der internen
>> Darstellung entferne ich es aus dem Quelltext, damit wirklich nur die
>> MIME-Zeichensatzdeklaration zum Tragen kommt.
>
> Und woher weiss der Renderer dann, welcher Zeichensatz verwendet werden
> soll? Gibst Du diese Angabe aus dem Content-Type auf andere Weise weiter?

Peter J. Holzer

unread,

Jul 2, 2012, 3:08:25 PM7/2/12

to

On 2012-07-01 17:46, Thomas 'PointedEars' Lahn <Point...@web.de> wrote:
> Peter J. Holzer wrote:
>> Michael Landenberger wrote:
>>> In diesem Fall ist die Einhaltung der von dir genannten Vorschrift
>>> schlicht unmöglich.
>>
>> Unmöglich ist es keinesfalls. Ich verwende z.B. den w3c (einen
> ^^^
>> textbasierten Browser), um text/html in text/plain umzuwandeln,
>
> Du meinst vermutlich _w3m_ :)

Ja.

>>> Irgendwas ist da faul. Ich vermute, dass PayPal Mist gebaut hat.
>>
>> Jein. Natürlich ist es unsinnig, im Content-Type ein anderes charset
>> anzugeben als im Content-Type.
>
> Wie meinen? :)

Ups. Natürlich ist es unsinnig, im Content-Type META-Element ein anderes
charset anzugeben als im Content-Type MIME-Header[1].

Sorry, gestern war's heiß. (Und heute ist es nicht viel kühler)

hp

[1] Durchkoppeln wäre hier dem Verständnis abträglich.

Peter J. Holzer

unread,

Jul 2, 2012, 3:19:31 PM7/2/12

to

On 2012-07-01 18:17, Michael Landenberger <spameim...@arcor.de> wrote:
> Am 01.07.2012 19:14, schrieb Peter J. Holzer:
>> Du hast vorhin geschrieben, dass Dein Renderer ein externes Programm
>> ist und dass Du dan Quelltext über das Filesystem ("ein .HTM-File")
>> übergibst. Dann ist das aber unmöglich. Nachdem Du den Quelltext
>> dekodiert hast, ist er keine Folge von Bytes mehr, sondern eine Folge
>> von Zeichen. Ein File ist aber immer eine Folge von Bytes.
>
> Zeichen sind Bytes ;)
>
>> Um den HTML-Text in ein
>> File zu schreiben, musst Du ihn wieder encodieren,
>
> Nö, warum? Einen Base64-encodierten JPG-Anhang encodiere ich auch nicht
> wieder, bevor ich ihn in eine JPEG-Datei exportiere, denn andernfalls
> könnte kein JPEG-Viewer mit der erzeugten Datei etwas anfangen.

Du verwechselst die Kodierungsebenen. Base64 bzw. Quoted-Printable ist
Content-Transfer-Encoding. Dabei wird ein Bytestrom so kodiert, dass er
in einer syntaktisch korrekten RFC-5322-E-Mail transportiert werden
kann. Ob dieser Bytestrom ein Text oder Bild ist, ist auf dieser Ebene
egal. Details (Ob der Text jetzt in iso-88591- oder utf-8 kodiert ist,
oder das Bild im JPEG- oder GIF Format) sind noch viel egaler. Für
diesen (En/De)koder sind das einfach nur Bytes.

Wenn Du den Bytestrom, der beim Base64- bzw. Quoted-Printable-Dekoder
rauskommt, nach ISO-8859-1 oder UTF-8 dekodierst, dann bekommst Du
Zeichen. Und Zeichen kannst Du nicht in ein File schreiben, weil File
aus Bytes besteht und nicht aus Zeichen.

Das gleiche gilt auch für Bilder: Wenn Du den Bytestrom nach JPEG oder
GIF dekodierst, bekommst Du Pixel. Die kannst Du auch nicht direkt auf
die Platte schreiben. Wenn Du das an einen externen JPEG-Viewer
übergeben willst, musst Du die Pixel wieder im JPEG-Format kodieren.

hp

Arno Welzel

unread,

Jul 2, 2012, 4:37:36 PM7/2/12

to

Peter J. Holzer, 02.07.2012 21:00:

> On 2012-07-02 15:17, Arno Welzel <use...@arnowelzel.de> wrote:
>> Am 02.07.2012 14:22, schrieb Michael Landenberger:

[...]

>>> Um Missverständnisse zu vermeiden, sollte immer klargestellt werden,
>>> *welche* Zeichensatzdeklaration gemeint ist. Ich bin davon ausgegangen,
>>> dass du die MIME-Zeichensatzdeklaration meinst. Und wenn in den
>>> MIME-Headern UTF-8 als Zeichensatz deklariert ist, decodiere ich das
>>> zugehörige Dokument eben als UTF-8. Ein evtl. vorhandenes HTML-Meta-Tag
>>
>> Wieso hängt die Art der Dekodierung vom Zeichensatz ab?
>
> Es gibt (mindestens) zwei Dekodierungen.

Nein, eine - entsprechend dem Transfer-Encoding. Was danach noch mit den
Daten passiert, ist nicht mehr "Dekodierung" sondern bestenfalls
Umwandlung - etwa von UTF-8 nach ISO-8859-1. Deswegen heisst die Angabe
im Content-Type auch nicht "character encoding" sondern "charset".

[...]

>> Und woher weiss der Renderer dann, welcher Zeichensatz verwendet werden
>> soll? Gibst Du diese Angabe aus dem Content-Type auf andere Weise weiter?
>
> Falls er wirklich den Bytestrom zu einem Zeichenstrom dekodiert (in dem
> dann z.B. ein Euro-Zeichen als U+20AC repräsentiert ist), dann wird
> diese Angabe nicht mehr benötigt, da dieser Teil der Verarbeitung ja
> bereits gemacht wurde.

Woher weiss der Renderer, wie die Zeichen jenseits von ASCII
darzustellen sind?

Message has been deleted

Arno Welzel

unread,

Jul 3, 2012, 6:11:55 AM7/3/12

to

Am 02.07.2012 20:37, schrieb Michael Landenberger:
> Am 02.07.2012 17:17, schrieb Arno Welzel:
>
>> Wieso hängt die Art der Dekodierung vom Zeichensatz ab?
>
> Weil auch ein Zeichensatz wie z. B. UTF-8 decodiert werden muss. Oder
> willst du Hexcodes wie z. B. "C3A4" (UTF-8 Code für "ä") in deiner Mail
> lesen? Nein, du möchtest da ein "ä" lesen. Also muss C3A4 in "ä"
> umgewandelt werden. Wenn "Decodierung" dafür der falsche Ausdruck ist,
> dann bitte ich um Entschuldigung und wäre dir dankbar, wenn du mir den
> richtigen Ausdruck nennen könntest.
>
>> Also - im MIME-Header steht z.B.:
>>
>> Content-Transfer-Encoding: quoted-printable
>>
>> Dann ist der entsprechende Inhalt eben als quoted-printable zu lesen.
>
> Selbstverständlich. Bei Quoted-Printable-Decodierung in Verbindung mit
> UTF-Zeichensatz steht dann eben statt eines "ä" ein "=C3=A4" im
> Quelltext. Daraus macht der Quoted-Printable-Decoder zunächst 2 Zeichen
> mit den Byte-Repräsentationen 0xC3 und 0xB4. Anschließend verwandelt der
> UTF-8-Decoder diese beiden Zeichen in ein "ä".

Die Bytfolge 0xC3, 0xA4 *ist* schon ein "ä", dargestellt als UTF-8. Was
soll daran noch dekodiert werden? Der Render kann das genau so verwenden
und als "ä" darstellen, wenn er weiß, dass es sich um UTF-8 handelt.

[META-Angabe mit Daten aus MIME-Header befüllen]

>> Du musst das Tag doch nicht parsen - einfach rauswerfen und durch ein
>> Eigenes mit den Angaben aus dem MIME-Content-Type-Header ersetzen,
>> wenigstens für die Anzeige.
>
> Ja, genau so habe ich es gemacht. Das Ergebnis zeigt der zweite der
> beiden weiter oben verlinkten Screenshots :-(

Ja - hier ist es besonder dumm gelaufen, weil die META-Angabe richtig
ist, der MIME-Header aber nicht, weil man offenbar davon ausgegangen
ist, dass im Zweifelsfall nur der HTML-Teil beachtet wird, ungeachtet
der Angabe im MIME-Header.

Als beste Näherung würde ich daher den META-Header, falls vorhanden,
einfach unverändert drin lassen und falls er fehlt - und nur dann, die
Content-Type-Angabe aus dem MIME-Header als META-Element ergänzen.

Das widerspricht zwar klar dem Standard, dürfte aber dennoch in den
meisten Fälle erfolgreich sein, da dort, wo das HTML-Dokument erstellt
wird, am ehesten der korrekte Zeichensatz bekannt ist und auch korrekt
als META-Element eingetragen wird.

Michael Landenberger

unread,

Jul 3, 2012, 11:37:45 AM7/3/12

to

Am 03.07.2012 12:11, schrieb Arno Welzel:

> Die Bytfolge 0xC3, 0xA4 *ist* schon ein "ä", dargestellt als UTF-8. Was
> soll daran noch dekodiert werden?

Sofern das (Windows-)Steuerelement, das das "ä" darstellen soll, ein
anderes Format als UTF-8 erwartet, muss der Text vor der Anzeige in
dieses andere Format umgewandelt werden. Beispielsweise kann ein
Control, das ANSI-Text erwartet, mit 0xC3 0xA4 nichts anfangen. Damit es
ein "ä" anzeigt, muss man ihm stattdessen ein 0xF6 liefern.

Auf das IE-Control trifft das allerdings nicht zu, das kann man direkt
mit UTF-8 füttern (man muss ihm nur sagen, dass es UTF-8 ist, womit es
gefüttert wurde). Wie es das dann intern verarbeitet, kann ich nicht sagen.

Den MIME-Typ text/plain zeigt mein Mailclient allerdings selbst an,
wobei das dafür verwendete Control ANSI-Text erwartet. Liegt der Text in
UTF-8 vor, muss er also wie oben beschrieben in ANSI umgewandelt werden,
bevor man ihn an das Anzeige-Control weiterreicht. Auch beim Export in
eine ANSI-Textdatei ist eine solche Umwandlung nötig. Diesen Vorgang
habe ich als "(UTF-8-)Decodierung" bezeichnet. Sorry, wenn das die
falsche Bezeichnung gewesen sein sollte.

Gruß

Michael

Message has been deleted

Arno Welzel

unread,

Jul 3, 2012, 11:45:28 PM7/3/12

to

Michael Landenberger, 03.07.2012 17:37:

> Am 03.07.2012 12:11, schrieb Arno Welzel:
>
>> Die Bytfolge 0xC3, 0xA4 *ist* schon ein "ä", dargestellt als UTF-8. Was
>> soll daran noch dekodiert werden?
>
> Sofern das (Windows-)Steuerelement, das das "ä" darstellen soll, ein
> anderes Format als UTF-8 erwartet, muss der Text vor der Anzeige in
> dieses andere Format umgewandelt werden. Beispielsweise kann ein
> Control, das ANSI-Text erwartet, mit 0xC3 0xA4 nichts anfangen. Damit es
> ein "ä" anzeigt, muss man ihm stattdessen ein 0xF6 liefern.

Und Du tust Dir diesen Stress wirklich an? Dir ist bewusst, dass es
ausser ANSI noch sehr viele andere Zeichensätze gibt, die Du ebenfalls
alle umwandeln müsstest? Da wäre die Ergänzung des META-Elements doch
etwas weniger aufwendig.

Arno Welzel

unread,

Jul 3, 2012, 11:49:26 PM7/3/12

to

Ralf Döblitz, 03.07.2012 08:12:

> Arno Welzel <use...@arnowelzel.de> schrieb:

>> Peter J. Holzer, 02.07.2012 21:00:

> [...]

>>> Falls er wirklich den Bytestrom zu einem Zeichenstrom dekodiert (in dem
>>> dann z.B. ein Euro-Zeichen als U+20AC repräsentiert ist), dann wird
>>> diese Angabe nicht mehr benötigt, da dieser Teil der Verarbeitung ja
>>> bereits gemacht wurde.
>>
>> Woher weiss der Renderer, wie die Zeichen jenseits von ASCII
>> darzustellen sind?
>

> Etnweder er weiß es oder er muß ein Ersatzsymbol verwenden. Eine

Ich meine ohne Angabe des verwendeten Zeichensatzes.

> Zurodnung von Codepunkten ist nicht mehr notwendig (falls es dir darum
> ging), da die Zeichen ja im internen Format des Renderers vorliegen, die
> Dekodierung des Bytestroms liefert ja den Zeichenstrom in einer für die
> nachfolgende Software bekannten Darstellung (typisch irgendeine Unicode-
> Darstellung, sonst könnte man ja keinen konformen Renderer bauen).

Nein, sie liegen nicht im "internen Format des Renderers" vor, sondern
entsprechend dem angegebenen Zeichensatz/Codierung, der dem Renderer
auch mitgeteilt werden muss - entweder über das META-Element oder falls
das Dokument per HTTP geliefert wird mit dem entsprechenden HTTP-Header.
Einzig für XHTML kann man von UTF-8 als Standard ausgehen, wenn nichts
anderes angegeben ist.

Michael Landenberger

unread,

Jul 4, 2012, 4:24:47 AM7/4/12

to

Am 04.07.2012 05:45, schrieb Arno Welzel:

> Dir ist bewusst, dass es
> ausser ANSI noch sehr viele andere Zeichensätze gibt, die Du ebenfalls
> alle umwandeln müsstest?

Natürlich ist mir das bewusst. Ich beschränke mich aber zunächst auf die
für mich wichtigsten. Mein Mailclient ist ja kein kommerzielles
Programm, das weltweit verteilt werden soll, sondern der einzige Nutzer
auf absehbare Zeit werde ich selbst sein. Und da tun's auch die
hierzulande gebräuchlichsten Zeichensätze. Sollte ich irgendwann eine
Mail bekommen, deren Zeichensatz mein Programm noch nicht unterstützt,
füge ich die Unterstützung einfach hinzu. Das ist eben der Vorteil von
Do it yourself ;-)

> Da wäre die Ergänzung des META-Elements doch
> etwas weniger aufwendig.

Wie ich schon schrieb, muss mein Mailclient bei HTML nichts umwandeln.
Stattdessen macht er genau das, was du schreibst: er teilt dem
HTML-Renderer per Meta-Element mit, mit welchem Zeichensatz er gerade
gefüttert wird. Der Renderer kümmert sich dann um die Darstellung.

Allerdings kann mein Mailprogramm auch plain text darstellen. Das tut es
aber nicht in einem HTML-Renderer, sondern in einem stinknormalen
Text-Steuerelement. Und dieses Steuerelement verlangt nunmal nach
ANSI-Text. Ein Meta-Element, mit dem man das Steuerelement anweisen
könnte, einen anderen Zeichensatz zu verarbeiten, gibt es bei plain text
auch nicht. Also muss sich mein Programm wohl oder übel selbst um die
Umwandlung kümmmern.

Gruß

Michael

Peter J. Holzer

unread,

Jul 4, 2012, 9:47:43 AM7/4/12

to

On 2012-07-02 22:06, Heiko Schlenker <hsc...@gmx.de> wrote:
> * Michael Landenberger <spameim...@arcor.de> schrieb:

>> Am 02.07.2012 17:17, schrieb Arno Welzel:
>>
>>> Wieso hängt die Art der Dekodierung vom Zeichensatz ab?
>>
>> Weil auch ein Zeichensatz wie z. B. UTF-8 decodiert werden muss.
>

> Achtung, Missverständnisgefahr. UTF-8 ist kein Zeichensatz, sondern
> eine Kodierung des Unicode-Zeichensatzes.

Korrekt.

Aber der Parameter heißt nun einmal "charset", auch wenn in irgendeinem
MIME-RFC sogar drinsteht, dass die Namenswahl unglücklich war
("char-encoding" o.ä. wäre vermutlich besser gewesen).

In der Praxis macht es aber wenig Unterschied: Der Parameter gibt an,
wie Folgen von Bytes in Folgen von (abstrakten) Zeichen umgewandelt
werden müssen. Ob das nun direkt (ISO-8859-15: 0xA4 -> EURO SIGN) oder
über einen Zwischenschritt (UTF-8: 0xE2 0x82 0xAC -> Unicode: U+20AC ->
EURO SIGN) geschieht, ist egal (vor allem, weil die Implementation das
sowieso so machen kann, wie sie will, es muss nur am Schluss das
richtige Zeichen angezeigt werden.

Peter J. Holzer

unread,

Jul 4, 2012, 10:37:30 AM7/4/12

to

On 2012-07-03 10:11, Arno Welzel <use...@arnowelzel.de> wrote:
> Am 02.07.2012 20:37, schrieb Michael Landenberger:
>> Am 02.07.2012 17:17, schrieb Arno Welzel:
>>
>>> Wieso hängt die Art der Dekodierung vom Zeichensatz ab?
>>
>> Weil auch ein Zeichensatz wie z. B. UTF-8 decodiert werden muss. Oder
>> willst du Hexcodes wie z. B. "C3A4" (UTF-8 Code für "ä") in deiner Mail
>> lesen? Nein, du möchtest da ein "ä" lesen. Also muss C3A4 in "ä"
>> umgewandelt werden. Wenn "Decodierung" dafür der falsche Ausdruck ist,
>> dann bitte ich um Entschuldigung und wäre dir dankbar, wenn du mir den
>> richtigen Ausdruck nennen könntest.
>>
>>> Also - im MIME-Header steht z.B.:
>>>
>>> Content-Transfer-Encoding: quoted-printable
>>>
>>> Dann ist der entsprechende Inhalt eben als quoted-printable zu lesen.
>>
>> Selbstverständlich. Bei Quoted-Printable-Decodierung in Verbindung mit
>> UTF-Zeichensatz steht dann eben statt eines "ä" ein "=C3=A4" im
>> Quelltext. Daraus macht der Quoted-Printable-Decoder zunächst 2 Zeichen
>> mit den Byte-Repräsentationen 0xC3 und 0xB4. Anschließend verwandelt der
>> UTF-8-Decoder diese beiden Zeichen in ein "ä".
>
> Die Bytfolge 0xC3, 0xA4 *ist* schon ein "ä", dargestellt als UTF-8.

Nein, das ist zunächst einmal einfach nur die Byte-Folge 0xC3 0xA4. Zu
einem "ä" wird es erst dadurch, dass eine Applikation es als "ä"
interpretiert, also z.B. die korrekten Glyphe darstellt, es als
lateinischen Buchstaben erkennt, etc.

Typischerweise muss dazu aus diesen beiden Bytes ein Wert des Typs
"Zeichen" gemacht werden. Wenn Zeichen also applikationsintern als
Unicode-Codepoints dargestellt werden (heutzutage eine plausible
Annahme), dann muss muss aus der Bytefolge der Codepoint berechnet
werden, in C z.B. so:

wchar_t decode_utf8 (unsigned char *p) {
if (*p < 0x80) {
return *p++;
} elsif (*p < 0xE0) {
wchar_t c;
c = *p++ & 0x1F;
c <<= 6;
c |= *p++ & 0x3F;
return c;
}
...
}

(grob vereinfacht und ohne Fehlerbehandlung).

Diesen Vorgang nennt man "dekodieren".

In Einzelfällen kann sich eine Applikation das dekodieren sparen und die
Bytestrings einfach opak durchschleusen - aber wenn sie irgendwas mit
dem Text machen will (was man bei einem MUA annehmen kann), dann braucht
die Applikation Zeichen und keine Bytes.

> Was soll daran noch dekodiert werden? Der Render kann das genau so
> verwenden und als "ä" darstellen, wenn er weiß, dass es sich um UTF-8
> handelt.

In dem Fall dekodiert es halt der Renderer. Egal: Irgendein Teil der
Applikation muss dekodieren, sonst kommt kein "ä" auf den Schirm.

> [META-Angabe mit Daten aus MIME-Header befüllen]
>>> Du musst das Tag doch nicht parsen - einfach rauswerfen und durch ein
>>> Eigenes mit den Angaben aus dem MIME-Content-Type-Header ersetzen,
>>> wenigstens für die Anzeige.
>>
>> Ja, genau so habe ich es gemacht. Das Ergebnis zeigt der zweite der
>> beiden weiter oben verlinkten Screenshots :-(
>
> Ja - hier ist es besonder dumm gelaufen, weil die META-Angabe richtig
> ist, der MIME-Header aber nicht,

Wie bitte? Es war doch genau umgekehrt! Oder gab es da noch eine zweite
Message, von der ich nichts mitbekommen habe?

Peter J. Holzer

unread,

Jul 4, 2012, 10:43:13 AM7/4/12

to

On 2012-07-03 15:37, Michael Landenberger <spameim...@arcor.de> wrote:
> Den MIME-Typ text/plain zeigt mein Mailclient allerdings selbst an,
> wobei das dafür verwendete Control ANSI-Text erwartet.

Wir schreiben das Jahr 2012, und Windows unterstützt m.W. seit NT4.0
(Mitte der 90er-Jahre) Unicode. Warum beschränkst Du Dich auf CP1252?

Peter J. Holzer

unread,

Jul 4, 2012, 11:10:39 AM7/4/12

to

On 2012-07-02 20:37, Arno Welzel <use...@arnowelzel.de> wrote:
> Peter J. Holzer, 02.07.2012 21:00:
>> On 2012-07-02 15:17, Arno Welzel <use...@arnowelzel.de> wrote:
>>> Am 02.07.2012 14:22, schrieb Michael Landenberger:
> [...]
>>>> Um Missverständnisse zu vermeiden, sollte immer klargestellt werden,
>>>> *welche* Zeichensatzdeklaration gemeint ist. Ich bin davon ausgegangen,
>>>> dass du die MIME-Zeichensatzdeklaration meinst. Und wenn in den
>>>> MIME-Headern UTF-8 als Zeichensatz deklariert ist, decodiere ich das
>>>> zugehörige Dokument eben als UTF-8. Ein evtl. vorhandenes HTML-Meta-Tag
>>>
>>> Wieso hängt die Art der Dekodierung vom Zeichensatz ab?
>>
>> Es gibt (mindestens) zwei Dekodierungen.
>
> Nein, eine - entsprechend dem Transfer-Encoding. Was danach noch mit den
> Daten passiert, ist nicht mehr "Dekodierung" sondern bestenfalls
> Umwandlung - etwa von UTF-8 nach ISO-8859-1. Deswegen heisst die Angabe
> im Content-Type auch nicht "character encoding" sondern "charset".

Das ist eher Zufall. In RFC 2045 wird darauf auch Bezug genommen:

| For example, some communities use the term
| "character encoding" for what MIME calls a "character set",

wobei die Formulierung "some communities" ein bisschen euphemistisch
ist. Außerhalb von MIME ist m.E. der Ausdruck "character encoding"
deutlich weiter verbreitet, und "character set" hat eine andere
Bedeutung. Siehe dazu auch Heikos Posting.

Es ist in der IT leider so, dass es meistens für das gleiche Konzept
mehrere Bezeichnungen gibt und die gleiche Bezeichnung oft für
verschiedene Konzepte verwendet wird. (ist in anderen Fachgebieten aber
auch so).

> [...]
>>> Und woher weiss der Renderer dann, welcher Zeichensatz verwendet werden
>>> soll? Gibst Du diese Angabe aus dem Content-Type auf andere Weise weiter?
>>
>> Falls er wirklich den Bytestrom zu einem Zeichenstrom dekodiert (in dem
>> dann z.B. ein Euro-Zeichen als U+20AC repräsentiert ist), dann wird
>> diese Angabe nicht mehr benötigt, da dieser Teil der Verarbeitung ja
>> bereits gemacht wurde.
>
> Woher weiss der Renderer, wie die Zeichen jenseits von ASCII
> darzustellen sind?

Er weiß es, weil er bereits Zeichen hat und keine Octets mehr. Er hat
also ein Zeichen "LATIN SMALL LETTER A WITH DIAERESIS" oder "EURO SIGN"
oder "PILE OF POO", die mit bestimmten Glyphen verknüpft sind (die
exakten Glyphen hängen von verwendeten Font ab, aber nicht mehr vom
charset. In dieser Stufe ist es vollkommen egal, ob das EURO SIGN durch
das Byte 0x80, das Byte 0xA4, die Bytefolge 0xE2 82 AC oder die
Bytefolge 0x26 0x65 0x75 0x72 0x6F 0x3B repräsentiert wurde. Ein
Euro-Zeichen ist ein Euro-Zeichen ist ein Euro-Zeichen.

Wie die Zeichen repräsentiert werden, ist Teil des APIs. Sinnvollerweise
wären das wohl heutzutage Unicode-Codepoints, aber es könnte auch ein
Transformation Format oder ganz was anderes sein.

Peter J. Holzer

unread,

Jul 4, 2012, 11:16:39 AM7/4/12

to

On 2012-07-02 06:06, Ralf Döblitz <doeb...@doeblitz.net> wrote:
> Michael Landenberger <spameim...@arcor.de> schrieb:

>> Am 01.07.2012 22:02, schrieb Ralf Döblitz:
>>> Bullshit, lies doch *endlich* mal die einschlägigen Standards.
>>

>> Gerne. Welche sollen das sein?
>
> Üblicherweise wird man dazu die RFCs und die Dokumente des W3C nehmen:
>
><http://www.w3.org/standards/techs/html>

>
>>> In HTML
>>> muß man gar kein Charset deklarieren, denn es ist ein Default vorge-
>>> geben. Und der lautet *nicht* ASCII.
>>

>> Wie lautet er dann?
>
> RFC2616 sieht für HTTP ISO-8859-1 vor.

| The HTTP protocol ([RFC2616], section 3.7.1) mentions ISO-8859-1 as a
| default character encoding when the "charset" parameter is absent from
| the "Content-Type" header field. In practice, this recommendation has
| proved useless because some servers don't allow a "charset" parameter to
| be sent, and others may not be configured to send the parameter.
| Therefore, user agents must not assume any default value for the
| "charset" parameter.

-- http://www.w3.org/TR/REC-html40/charset.html

Allerdings geht es hier eh nicht um HTTP, sondern um E-Mail, und der
charset-Parameter war ja angegeben, also ist mir nicht klar, inwieweit
das relevant sein soll.

Message has been deleted

Arno Welzel

unread,

Jul 5, 2012, 5:40:47 AM7/5/12

to

Am 04.07.2012 16:37, schrieb Peter J. Holzer:

> On 2012-07-03 10:11, Arno Welzel <use...@arnowelzel.de> wrote:
>> Am 02.07.2012 20:37, schrieb Michael Landenberger:
>>> Am 02.07.2012 17:17, schrieb Arno Welzel:
>>>
>>>> Wieso hängt die Art der Dekodierung vom Zeichensatz ab?
>>>
>>> Weil auch ein Zeichensatz wie z. B. UTF-8 decodiert werden muss. Oder
>>> willst du Hexcodes wie z. B. "C3A4" (UTF-8 Code für "ä") in deiner Mail
>>> lesen? Nein, du möchtest da ein "ä" lesen. Also muss C3A4 in "ä"
>>> umgewandelt werden. Wenn "Decodierung" dafür der falsche Ausdruck ist,
>>> dann bitte ich um Entschuldigung und wäre dir dankbar, wenn du mir den
>>> richtigen Ausdruck nennen könntest.
>>>
>>>> Also - im MIME-Header steht z.B.:
>>>>
>>>> Content-Transfer-Encoding: quoted-printable
>>>>
>>>> Dann ist der entsprechende Inhalt eben als quoted-printable zu lesen.
>>>
>>> Selbstverständlich. Bei Quoted-Printable-Decodierung in Verbindung mit
>>> UTF-Zeichensatz steht dann eben statt eines "ä" ein "=C3=A4" im
>>> Quelltext. Daraus macht der Quoted-Printable-Decoder zunächst 2 Zeichen
>>> mit den Byte-Repräsentationen 0xC3 und 0xB4. Anschließend verwandelt der
>>> UTF-8-Decoder diese beiden Zeichen in ein "ä".
>>
>> Die Bytfolge 0xC3, 0xA4 *ist* schon ein "ä", dargestellt als UTF-8.
>
> Nein, das ist zunächst einmal einfach nur die Byte-Folge 0xC3 0xA4. Zu
> einem "ä" wird es erst dadurch, dass eine Applikation es als "ä"
> interpretiert, also z.B. die korrekten Glyphe darstellt, es als
> lateinischen Buchstaben erkennt, etc.

Genau das schrieb ich ja - dargestellt als UTF-8. Man muss der
Applikation, die das anzeigen soll nur mitteillen, dass sie es als UTF-8
zu interpretieren hat. Da muss nichts dekodiert werden.

> Typischerweise muss dazu aus diesen beiden Bytes ein Wert des Typs
> "Zeichen" gemacht werden. Wenn Zeichen also applikationsintern als
> Unicode-Codepoints dargestellt werden (heutzutage eine plausible
> Annahme), dann muss muss aus der Bytefolge der Codepoint berechnet
> werden, in C z.B. so:
>
> wchar_t decode_utf8 (unsigned char *p) {
> if (*p < 0x80) {
> return *p++;
> } elsif (*p < 0xE0) {
> wchar_t c;
> c = *p++ & 0x1F;
> c <<= 6;
> c |= *p++ & 0x3F;
> return c;
> }
> ...
> }
>
> (grob vereinfacht und ohne Fehlerbehandlung).
>
> Diesen Vorgang nennt man "dekodieren".

Und welche Applikation braucht das? Ich kenne keinen halbwegs aktuellen
Browser oder Texteditor, der mit UTF-8 nicht umgehen könnte.

> In Einzelfällen kann sich eine Applikation das dekodieren sparen und die
> Bytestrings einfach opak durchschleusen - aber wenn sie irgendwas mit
> dem Text machen will (was man bei einem MUA annehmen kann), dann braucht
> die Applikation Zeichen und keine Bytes.

Sofern die Applikation nichts mit UTF-8 anfangen kann - und das ist die
Ausnahme, nicht dir Regel.

[...]

>>>> Du musst das Tag doch nicht parsen - einfach rauswerfen und durch ein
>>>> Eigenes mit den Angaben aus dem MIME-Content-Type-Header ersetzen,
>>>> wenigstens für die Anzeige.
>>>
>>> Ja, genau so habe ich es gemacht. Das Ergebnis zeigt der zweite der
>>> beiden weiter oben verlinkten Screenshots :-(
>>
>> Ja - hier ist es besonder dumm gelaufen, weil die META-Angabe richtig
>> ist, der MIME-Header aber nicht,
>
> Wie bitte? Es war doch genau umgekehrt! Oder gab es da noch eine zweite
> Message, von der ich nichts mitbekommen habe?

Offensichtlich. Siehe <a56tje...@mid.uni-berlin.de> - Zitat:

------------ Attachment-Header ------------
Content-Type: text/html;charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
--------- Ende Attachment-Header ----------
[...]
---------- HTML-Attachment-Body -----------
(...)
<head>
<title>eBay Research</title>

(...)
</head>
<body>
Klicken Sie auf die Schaltfl=E4che „An Umfrage teilnehmen“, um =
uns Ihre Meinung zum Verkaufen bei eBay mitzuteilen, oder f=FCgen Sie den f=
olgenden Link in die Adresszeile Ihres Webbrowsers ein:
(...)
</body>
(...)
------- Ende HTML-Attachment-Body ---------

(Zitat Ende)

Im Dokument wurde per META-Angabe UTF-8 angegeben und die darin
enthaltenen Daten sind auch UTF-8. Mir wäre jedenfalls neu, dass “
in ISO-8859-1 darstellbar wäre.

Arno Welzel

unread,

Jul 5, 2012, 5:49:33 AM7/5/12

to

Am 04.07.2012 17:10, schrieb Peter J. Holzer:

> On 2012-07-02 20:37, Arno Welzel <use...@arnowelzel.de> wrote:

[...]

>> Woher weiss der Renderer, wie die Zeichen jenseits von ASCII
>> darzustellen sind?
>
> Er weiß es, weil er bereits Zeichen hat und keine Octets mehr. Er hat
> also ein Zeichen "LATIN SMALL LETTER A WITH DIAERESIS" oder "EURO SIGN"
> oder "PILE OF POO", die mit bestimmten Glyphen verknüpft sind (die
> exakten Glyphen hängen von verwendeten Font ab, aber nicht mehr vom
> charset. In dieser Stufe ist es vollkommen egal, ob das EURO SIGN durch
> das Byte 0x80, das Byte 0xA4, die Bytefolge 0xE2 82 AC oder die
> Bytefolge 0x26 0x65 0x75 0x72 0x6F 0x3B repräsentiert wurde. Ein
> Euro-Zeichen ist ein Euro-Zeichen ist ein Euro-Zeichen.

Ein Euro-Zeichen kann aber, wie Du ja zeigst, mit unterschiedlichen
Bytefolgen dargestellt werden. Als Zeichen können Sie nur deswegen
interpretiert werden, weil man weiss, ob sie als ISO-8859-1, UTF-8 etc.
zu interpretieren sind. Wenn man diese Information aber hat, dann ist
nichts mehr umzuwandeln - dann ist man fertig. Nur wenn man dann noch
die Texte selber per API ausgeben will, muss man wissen, ob das API
direkt ISO-8859-1 oder UTF-8 akzeptiert - und nur dann muss man ggf.
umwandeln.

> Wie die Zeichen repräsentiert werden, ist Teil des APIs. Sinnvollerweise
> wären das wohl heutzutage Unicode-Codepoints, aber es könnte auch ein
> Transformation Format oder ganz was anderes sein.

Richtig. Das hat aber mit der ursprünglichen Fragestellung nichts mehr
zu tun.

Arno Welzel

unread,

Jul 5, 2012, 2:43:32 PM7/5/12

to

Ralf Döblitz, 04.07.2012 07:11:

> Arno Welzel <use...@arnowelzel.de> schrieb:

>> Ralf Döblitz, 03.07.2012 08:12:
>>
>>> Arno Welzel <use...@arnowelzel.de> schrieb:
>>>> Peter J. Holzer, 02.07.2012 21:00:
>>> [...]
>>>>> Falls er wirklich den Bytestrom zu einem Zeichenstrom dekodiert (in dem

> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

>>>>> dann z.B. ein Euro-Zeichen als U+20AC repräsentiert ist), dann wird
>>>>> diese Angabe nicht mehr benötigt, da dieser Teil der Verarbeitung ja
>>>>> bereits gemacht wurde.
>>>>
>>>> Woher weiss der Renderer, wie die Zeichen jenseits von ASCII
>>>> darzustellen sind?
>>>
>>> Etnweder er weiß es oder er muß ein Ersatzsymbol verwenden. Eine
>>
>> Ich meine ohne Angabe des verwendeten Zeichensatzes.
>>
>>> Zurodnung von Codepunkten ist nicht mehr notwendig (falls es dir darum
>>> ging), da die Zeichen ja im internen Format des Renderers vorliegen, die
>>> Dekodierung des Bytestroms liefert ja den Zeichenstrom in einer für die
>>> nachfolgende Software bekannten Darstellung (typisch irgendeine Unicode-
>>> Darstellung, sonst könnte man ja keinen konformen Renderer bauen).
>>
>> Nein, sie liegen nicht im "internen Format des Renderers" vor,
>

> Oben wurde etwas anderes vorausgesetzt. Wenn man den Bytestrom in einen
> Zeichenstrom dekodiert, dann liegen da *Zeichen* vor, und die sind im
> bekannten internen Format des Systems. Die Kenntnis des benutzten
> Zeichensatzes für den Bytestrom ist während dieser Dekodierung
> notwendig, danach aber nicht mehr.

Es gibt kein "bekanntes internes Format des Systems". *Jeder* Text hat
irgendeine Codierung. Auch nach der "Dekodierung" muss bekannt sein, wie
die einzelnen Bytes zu interpretieren sind. Nur weil das darstellende
System dies weiss, ist es noch lange kein ominöses "internes Format".

Peter J. Holzer

unread,

Jul 5, 2012, 2:46:49 PM7/5/12

to

[Kontext-Frage: Bist Du Programmierer? Wenn ja, welche
Programmiersprachen verwendest Du?]

Doch, die Applikation muss dekodieren. Und man muss ihr mitteilen,
welche Kodierung verwendet wurde, damit sie richtig dekodieren kann.
Wenn man der Applikation fälschlicherweises mitteilt, dass 0xC3 0xA4 als
ISO-8859-15 zu dekodieren ist, wird sie die Bytefolge zu den zwei
Zeichen LATIN CAPITAL LETTER A WITH TILDE, EURO SIGN dekodieren.

Wenn die Applikation nicht dekodieren müsste, dann müsste man ihr die
Kodierung auch nicht mitteilen.

>> Typischerweise muss dazu aus diesen beiden Bytes ein Wert des Typs
>> "Zeichen" gemacht werden. Wenn Zeichen also applikationsintern als
>> Unicode-Codepoints dargestellt werden (heutzutage eine plausible
>> Annahme), dann muss muss aus der Bytefolge der Codepoint berechnet
>> werden, in C z.B. so:
>>
>> wchar_t decode_utf8 (unsigned char *p) {
>> if (*p < 0x80) {
>> return *p++;
>> } elsif (*p < 0xE0) {
>> wchar_t c;
>> c = *p++ & 0x1F;
>> c <<= 6;
>> c |= *p++ & 0x3F;
>> return c;
>> }
>> ...
>> }
>>
>> (grob vereinfacht und ohne Fehlerbehandlung).
>>
>> Diesen Vorgang nennt man "dekodieren".
>
> Und welche Applikation braucht das? Ich kenne keinen halbwegs aktuellen
> Browser oder Texteditor, der mit UTF-8 nicht umgehen könnte.

Jeder Browser oder Texteditor, der "mit UTF-8 umgehen kann", kann (und
wird) UTF-8 dekodieren.

Wenn er das nicht als expliziten Schritt beim Lesen des Files macht
(was die meisten wohl tun werden, weil das einfach am praktischsten
ist), dann muss er es on-the-fly beim Verarbeiten tun (der Editor muss
also z.B. jeweils das Zeichen, das er gerade auf den Schirm pinseln
möchte und/oder über das der Benutzer mit dem Cursor drüberfährt,
dekodieren).

Das ist die Mail, die im Kopf hatte, ja.

> Im Dokument wurde per META-Angabe UTF-8 angegeben und die darin
> enthaltenen Daten sind auch UTF-8.

Nein. Die enthaltenden Daten sind ISO-8859-1 (wie vollkommen richtig im
MIME-Header angegeben). Das erkennt man am Wort Schaltfl=E4che, das
offensichtlich "Schaltfläche" heißen soll. Ein "ä" in ISO-8859-1 kodiert
ist ein Byte 0xE4, die quoted-printable Kodierung macht daraus dann
"=E4". Wäre es UTF-8 so würde da "Schaltfl=C3=A4che" stehen.

> Mir wäre jedenfalls neu, dass “ in ISO-8859-1 darstellbar wäre.

Das ist eine "Numeric character reference" (siehe
http://www.w3.org/TR/REC-html40/charset.html#h-5.3.1). Die hat nichts
mit UTF-8 zu tun. Numeric character references geben *immer* den
Unicode-Codepoint an (vollkommen unabhängig vom charset) und man braucht
sie eben genau dann, wenn ein Zeichen (hier "„" DOUBLE LOW-9 QUOTATION
MARK) im gewählten charset nicht repräsentierbar ist. Wären die Daten
UTF-8-kodiert, so wäre die Verwendung einer Numeric character Reference
unnötig, man könnte das Zeichen direkt durch die Bytefolge 0xE2 0x80
0x9E repräsentieren.

Message has been deleted

Arno Welzel

unread,

Jul 6, 2012, 7:25:49 AM7/6/12

to

Am 05.07.2012 20:46, schrieb Peter J. Holzer:

> [Kontext-Frage: Bist Du Programmierer? Wenn ja, welche
> Programmiersprachen verwendest Du?]

Ja, ich bin Programmierer seit ca. 25 Jahren und ich verwende C, C++,
Java, C#. Darüber hinaus habe ich auch mit Web-basierten Anwendungen zu
tun und kenne entsprechend auch (X)HTML, CSS, JavaScript und PHP.

> On 2012-07-05 09:40, Arno Welzel <use...@arnowelzel.de> wrote:
>> Am 04.07.2012 16:37, schrieb Peter J. Holzer:
>>
>>> On 2012-07-03 10:11, Arno Welzel <use...@arnowelzel.de> wrote:
>>>> Am 02.07.2012 20:37, schrieb Michael Landenberger:
>>>>> Am 02.07.2012 17:17, schrieb Arno Welzel:
>>>>>

[...]

>>>> Die Bytfolge 0xC3, 0xA4 *ist* schon ein "ä", dargestellt als UTF-8.
>>>
>>> Nein, das ist zunächst einmal einfach nur die Byte-Folge 0xC3 0xA4. Zu
>>> einem "ä" wird es erst dadurch, dass eine Applikation es als "ä"
>>> interpretiert, also z.B. die korrekten Glyphe darstellt, es als
>>> lateinischen Buchstaben erkennt, etc.
>>
>> Genau das schrieb ich ja - dargestellt als UTF-8. Man muss der
>> Applikation, die das anzeigen soll nur mitteillen, dass sie es als UTF-8
>> zu interpretieren hat. Da muss nichts dekodiert werden.
>
> Doch, die Applikation muss dekodieren. Und man muss ihr mitteilen,
> welche Kodierung verwendet wurde, damit sie richtig dekodieren kann.

Ja - und, was schrieb ich gerade eben? Liest Du auch, worauf Du antwortest?

Es ging mal um die Frage, wie man einem Renderer - also einer
Applikation oder einer eingebetteten Komponente - einen Text übergeben
muss, damit er korrekt dargestellt wird. Im Verlauf dieser Fragestellung
wurde dann die Idee erwähnt, dass der Text "dekodiert" wird und dann an
den Renderer übergeben wird.

Ich habe dazu eingewandt, dass man auch nach der "Dekodierung" nicht
plötzlich "Zeichen" statt "Bytefolgen" existieren, sondern nur wieder
Bytefolgen, die aber nun eine andere Bedeutung haben.

Die darstellende Komponente oder Applikation muss *immer* wissen, wie
die gelieferten Bytes zu lesen sind, egal ob nun ISO-8859-1, UTF-8 oder
Unicode binär.

[...]

>>> Typischerweise muss dazu aus diesen beiden Bytes ein Wert des Typs
>>> "Zeichen" gemacht werden. Wenn Zeichen also applikationsintern als
>>> Unicode-Codepoints dargestellt werden (heutzutage eine plausible
>>> Annahme), dann muss muss aus der Bytefolge der Codepoint berechnet
>>> werden, in C z.B. so:

[...]

>> Und welche Applikation braucht das? Ich kenne keinen halbwegs aktuellen
>> Browser oder Texteditor, der mit UTF-8 nicht umgehen könnte.
>
> Jeder Browser oder Texteditor, der "mit UTF-8 umgehen kann", kann (und
> wird) UTF-8 dekodieren.

Also ich muss die als UTF-8 vorliegenden HTML-Dokumente auf meinem
Webserver nicht erst dekodieren, damit sie ein Browser, der UTF-8
versteht und dort abruft, anzeigen kann. Ja - dass der Browser selbst
intern die Daten umwandeln muss, damit er sie über das API des OS auch
anzeigen lassen kann, ist klar - aber es ging hier ja nicht darum, was
man tun muss, wenn man einen Browser oder einen Texteditor programmieren
will.

Du scheinst hier etwas durcheinander zu bringen.

Arno Welzel

unread,

Jul 6, 2012, 7:32:36 AM7/6/12

to

Am 05.07.2012 23:09, schrieb Ralf Döblitz:

> Arno Welzel <use...@arnowelzel.de> schrieb:
[...]

>> Es gibt kein "bekanntes internes Format des Systems". *Jeder* Text hat
>> irgendeine Codierung. Auch nach der "Dekodierung" muss bekannt sein, wie
>> die einzelnen Bytes zu interpretieren sind. Nur weil das darstellende
>> System dies weiss, ist es noch lange kein ominöses "internes Format".
>

> Hast du jemals programmiert? Wenn man in einer Software einen Bytestrom

Ja, seit rund 21 Jahren hauptberuflich, davon schon fast 5 Jahre
hobbymäßig - in diversen Sprachen (C, C++, Java, C#...).

> zu einem Zeichenstrom dekodiert hat, dann liegen die Dateen danach im
> internen Format dieses Softwaresystems vor. Heute werden das häufig

Nenne doch bitte ein Beispiel für die Dekodierung eines
ISO-8859-1-Bytestroms aus einer Datei in das "interne Format" von
Windows 7, so dass man den Text dann lesbar in einem Fenster ausgeben
kann (etwa über ein GDI-Handle bei Windows). Linux oder MacOS mit den
dort üblichen Mechanismen ist auch OK.

Peter J. Holzer

unread,

Jul 6, 2012, 4:46:43 PM7/6/12

to

On 2012-07-06 11:32, Arno Welzel <use...@arnowelzel.de> wrote:
> Am 05.07.2012 23:09, schrieb Ralf Döblitz:
>
>> Arno Welzel <use...@arnowelzel.de> schrieb:
> [...]
>>> Es gibt kein "bekanntes internes Format des Systems". *Jeder* Text hat
>>> irgendeine Codierung. Auch nach der "Dekodierung" muss bekannt sein, wie
>>> die einzelnen Bytes zu interpretieren sind. Nur weil das darstellende
>>> System dies weiss, ist es noch lange kein ominöses "internes Format".
>>
>> Hast du jemals programmiert? Wenn man in einer Software einen Bytestrom
>
> Ja, seit rund 21 Jahren hauptberuflich, davon schon fast 5 Jahre
> hobbymäßig - in diversen Sprachen (C, C++, Java, C#...).

Gut, dann muss man wenigstens nicht bei Adam und Eva anfangen. Immerhin
dürfte Dir der Unterschied zwischen 4 Bytes, eine int (32 bit) und einem
float bekannt sein.

Dass man 20 Jahre programmieren kann, ohne die Grundlagen von
Character-Encodings verstanden zu haben, haben ein paar Kollegen von mir
auch schon demonstriert. Einer hat sich inzwischen dieses T-Shirt
gekauft: http://www.geekwear.de/produkte/scheiss-encoding-shirt.html :-)

>> zu einem Zeichenstrom dekodiert hat, dann liegen die Dateen danach im
>> internen Format dieses Softwaresystems vor. Heute werden das häufig
>
> Nenne doch bitte ein Beispiel für die Dekodierung eines
> ISO-8859-1-Bytestroms aus einer Datei in das "interne Format" von
> Windows 7, so dass man den Text dann lesbar in einem Fenster ausgeben
> kann (etwa über ein GDI-Handle bei Windows). Linux oder MacOS mit den
> dort üblichen Mechanismen ist auch OK.

Muss da unbedingt ein GUI im Spiel sein? Als Commandline-Tool wäre der
Code kürzer.

Aber gut, hier ist ein kleines Perl/Gtk2-Script, das (Text-)Files in
verschiedenen Encodings einliest, darstellt, und in einem (eventuell
anderen Encoding wieder abspeichert.

Interessant sind eigentlich nur die Callbacks für die beiden Buttons:

$load_button->signal_connect(
clicked
=> sub {
open(my $fh, "<:encoding($encoding{in})", $file_in_entry->get_text);
local $/;
$content = <$fh>;
$text->set_text($content);
}
);

Hier wird das File geöffnet, wobei das Encoding gleich beim open-Call
übergeben wird. Die Read-Operation (<$fh>) liefert dann bereits einen
Character-String, keinen Byte-String. Diesen Character-String kann ich
dann dem GUI übergeben, und es zeigt mir brav Umlaute, griechische und
japanische Zeichen an, völlig unabhängig davon, welches Encoding das
File hatte.

Alternativ hätte ich das File auch als Bytestream lesen und explizit
decode() aufrufen können.

$save_button->signal_connect(
clicked
=> sub {
open(my $fh, ">:encoding($encoding{out})", $file_out_entry->get_text);
print $fh $content;
}
);

Und hier wird in das File geschrieben. Wieder gebe ich beim open einfach
das gewünschte Encoding an, und der I/O-Layer erledigt den Rest. Auch
hier hätte ich zuerst explizit aus dem Character-String mit encode()
einen Byte-String machen können und den auf ein im Binary-Mode
geöffnetes File schreiben können.

In Java würde ich das im Prinzip gleich machen (da ist String ja schon
per definitionen eine Kette von char's, nicht eine von Bytes) [Ja, ich
weiß, 16 Bit reichen nicht ...]

In C vermutlich auch (mit wchar_t), aber da weiß ich nicht, wie das
GTK-API aussieht - kann sein, dass das Strings in UTF-8 haben möchte und
nicht als wchar_t[]. Aber ziemlich sicher will es es keine Byte-Strings
in beliebigen Encodings.

So, hier noch das ganze Script in seiner vollen Grauslichkeit (Sorry,
ich schreibe so selten GUI-Sachen, und das ist recht schnell
zusammengehackt):

#!/usr/bin/perl
use warnings;
use strict;
use utf8;
use v5.10;

binmode STDOUT, ":encoding(UTF-8)";

# Use the TRUE and FALSE constants exported by the Glib module.
use Glib qw/TRUE FALSE/;
use Gtk2 '-init';

my $text;
my %encoding = (in => 'iso-8859-1', out => 'iso-8859-1');
my $content;

create_window();
Gtk2->main;
exit 0;

sub create_window {
my $window = Gtk2::Window->new('toplevel');
$window->signal_connect(destroy => sub { Gtk2->main_quit; });
$window->set_border_width(10);

my $vbox = Gtk2::VBox->new(FALSE, 0);
my $bar = create_action_bar();
$vbox->pack_start($bar, TRUE, FALSE, 10);

$text = Gtk2::Label->new();
$text->show;
$vbox->pack_start($text, TRUE, FALSE, 10);

$vbox->show;
$window->add($vbox);
$window->show;
}

sub create_action_bar {
my $bar = Gtk2::HBox->new(FALSE, 0);
my $enc_in_menu = create_encoding_menu('in');
$bar->pack_start($enc_in_menu, TRUE, FALSE, 10);

# XXX - input file name
my $file_in_entry = Gtk2::Entry->new();
$file_in_entry->show;
$bar->pack_start($file_in_entry, TRUE, FALSE, 10);

my $load_button = Gtk2::Button->new("Load");
$load_button->signal_connect(
clicked
=> sub {
open(my $fh, "<:encoding($encoding{in})", $file_in_entry->get_text);
local $/;
$content = <$fh>;
$text->set_text($content);
}
);
$load_button->show;
$bar->pack_start($load_button, TRUE, FALSE, 10);

my $arrow = Gtk2::Label->new('→');
say $arrow;
$arrow->show;
$bar->pack_start($arrow, TRUE, FALSE, 10);

my $enc_out_menu = create_encoding_menu('out');
$bar->pack_start($enc_out_menu, TRUE, FALSE, 10);

my $file_out_entry = Gtk2::Entry->new();
$file_out_entry->show;
$bar->pack_start($file_out_entry, TRUE, FALSE, 10);

my $save_button = Gtk2::Button->new("Save");
$save_button->signal_connect(
clicked
=> sub {
open(my $fh, ">:encoding($encoding{out})", $file_out_entry->get_text);
print $fh $content;
}
);
$save_button->show;
$bar->pack_start($save_button, TRUE, FALSE, 10);

$bar->show;

return $bar;
}

sub create_encoding_menu {
my ($dir) = @_;

my $opt_menu = Gtk2::OptionMenu->new;
my $menu = Gtk2::Menu->new;
for my $enc (qw(iso-8859-1 iso-8859-15 utf-8 utf-16 koi8r)) {
my $item = Gtk2::MenuItem->new_with_label($enc);
$item->signal_connect(activate => sub { $encoding{$dir} = $enc });
$item->show;
$menu->append($item);
}
$opt_menu->set_menu($menu);
$opt_menu->show;
return $opt_menu;

Message has been deleted

Peter J. Holzer

unread,

Jul 7, 2012, 5:57:25 AM7/7/12

to

On 2012-07-06 11:25, Arno Welzel <use...@arnowelzel.de> wrote:
> Am 05.07.2012 20:46, schrieb Peter J. Holzer:
>> On 2012-07-05 09:40, Arno Welzel <use...@arnowelzel.de> wrote:
>>> Am 04.07.2012 16:37, schrieb Peter J. Holzer:
>>>
>>>> On 2012-07-03 10:11, Arno Welzel <use...@arnowelzel.de> wrote:
>>>>> Am 02.07.2012 20:37, schrieb Michael Landenberger:
>>>>>> Am 02.07.2012 17:17, schrieb Arno Welzel:
>>>>>>
> [...]

>>>>> Die Bytfolge 0xC3, 0xA4 *ist* schon ein "�", dargestellt als UTF-8.
>>>>
>>>> Nein, das ist zun�chst einmal einfach nur die Byte-Folge 0xC3 0xA4. Zu
>>>> einem "�" wird es erst dadurch, dass eine Applikation es als "�"

>>>> interpretiert, also z.B. die korrekten Glyphe darstellt, es als
>>>> lateinischen Buchstaben erkennt, etc.
>>>
>>> Genau das schrieb ich ja - dargestellt als UTF-8. Man muss der
>>> Applikation, die das anzeigen soll nur mitteillen, dass sie es als UTF-8
>>> zu interpretieren hat. Da muss nichts dekodiert werden.
>>
>> Doch, die Applikation muss dekodieren. Und man muss ihr mitteilen,
>> welche Kodierung verwendet wurde, damit sie richtig dekodieren kann.
>
> Ja - und, was schrieb ich gerade eben? Liest Du auch, worauf Du antwortest?

Ja. Darf ich die Frage zur�ckgeben?

> Es ging mal um die Frage, wie man einem Renderer - also einer

> Applikation oder einer eingebetteten Komponente - einen Text �bergeben

> muss, damit er korrekt dargestellt wird.

Richtig. Und ich habe darauf hingewiesen, dass diese beiden F�lle
unterschiedlich zu behandeln sind: Einer externen Applikation kann ich
typischerweise nur einen Bytestream �bergeben
(<slrnjv11cd.97...@hrunkner.hjp.at>,
<slrnjv3t23.uo...@hrunkner.hjp.at>), bei einer eingebetteten
Komponente h�ngt es vom API ab
(<slrnjv3rv0.uo...@hrunkner.hjp.at>).

> Im Verlauf dieser Fragestellung wurde dann die Idee erw�hnt, dass der
> Text "dekodiert" wird und dann an den Renderer �bergeben wird.

Ja, der OP hat behauptet, dass er das macht. Ich habe darauf
hingewiesen, dass das im Widerspruch zu seiner Behauptung steht, dass er
einen externen Renderer verwendet. (Der Widerspruch hat sich dadurch
aufgekl�rt, dass er als Zeichen-Typ einen 8-Bit-Typ verwendet, wodurch das
(konzeptionell notwendige) Encoding zu einer NOP wird)

Bei einem internen Renderer kann das aber sinnvoll oder sogar notwendig
sein. Beispielsweise w�re es naheliegend, dass man einer Java
HTML-Komponente[1] ein St�ck HTML-Code als String �bergibt und nicht als
ByteBuffer oder byte[] (oder gar als String, bei dem jeder char ein Byte
repr�sentiert - ein konzeptioneller Fehler, den man leider bei machen
Java-APIs findet).

> Ich habe dazu eingewandt, dass man auch nach der "Dekodierung" nicht

> pl�tzlich "Zeichen" statt "Bytefolgen" existieren, sondern nur wieder

> Bytefolgen, die aber nun eine andere Bedeutung haben.

Und das ist falsch. Nach der Dekodierung sind es eben - in der Semantik
des Programms und wahrscheinlich auch der verwendeten Programmiersprache
- Zeichen und keine Bytes mehr. Klar, RAM besteht aus Bytes[2], aber
solange Du nicht in Assembler programmierst, hat Dich das nicht zu
k�mmern. Und selbst wenn Du in Assembler programmierst, hat gibt es
applikationsinterne Typen - eine Folge von Bytes repr�sentiert eine
x-Koordinate, eine andere ein Unicode-Zeichen und eine dritte einen
Zeitpunkt.

> Die darstellende Komponente oder Applikation muss *immer* wissen, wie
> die gelieferten Bytes zu lesen sind, egal ob nun ISO-8859-1, UTF-8 oder

> Unicode bin�r.

Nein, wenn die Komponente schon Zeichen bekommt (also z.B. in Java einen
String), dann muss sie nicht mehr wissen, wie das File urspr�nglich
kodiert war (vielleicht gab es auch gar nie ein File - die Applikation
kann den String ja on the fly zusammengebastelt haben).

>>>> Typischerweise muss dazu aus diesen beiden Bytes ein Wert des Typs
>>>> "Zeichen" gemacht werden. Wenn Zeichen also applikationsintern als
>>>> Unicode-Codepoints dargestellt werden (heutzutage eine plausible
>>>> Annahme), dann muss muss aus der Bytefolge der Codepoint berechnet
>>>> werden, in C z.B. so:
> [...]
>>> Und welche Applikation braucht das? Ich kenne keinen halbwegs aktuellen

>>> Browser oder Texteditor, der mit UTF-8 nicht umgehen k�nnte.

>>
>> Jeder Browser oder Texteditor, der "mit UTF-8 umgehen kann", kann (und
>> wird) UTF-8 dekodieren.
>
> Also ich muss die als UTF-8 vorliegenden HTML-Dokumente auf meinem
> Webserver nicht erst dekodieren, damit sie ein Browser, der UTF-8
> versteht und dort abruft, anzeigen kann.

Nat�rlich nicht. Der Webserver verarbeitet das File ja nicht, er gibt es
nur 1:1 weiter. Auch auf diesen Fall hatte ich bereits hingewiesen
(<slrnjv8l9b.ba...@hrunkner.hjp.at>).

Wenn der Webserver aber das File doch verarbeitet (z.B. irgendwelchen
eingebetteten Code ausf�hrt), dann muss er es wahrscheinlich dekodieren.

> Ja - dass der Browser selbst intern die Daten umwandeln muss, damit er

> sie �ber das API des OS auch anzeigen lassen kann, ist klar

Wir reden hier �ber einen Mailer. Der ist in der gleichen Situation wie
ein Browser: Er bekommt einen Bytestrom und einen Content-Type und soll
das f�r Menschen lesbar darstellen.

Daf�r kann er unter Umst�nden vorhandene Komponenten verwenden. Ob f�r
diese Komponenten der Bytestrom vorverarbeitet werden muss, oder ob es
reicht, den Bytestrom samt Kontext zu �bergeben, h�ngt von der
Komponente ab. Gerade im Fall eines Browsers, dem ein file:-URL
�bergeben wird, ist so eine Verarbeitung aber fast sicher notwendig
(charset, cid:-URLs, Security, ...) und damit eine Dekodierung und
anschlie�ende Kodierung sinnvoll.

> - aber es ging hier ja nicht darum, was man tun muss, wenn man einen
> Browser oder einen Texteditor programmieren will.

Falls Du hier auf <slrnjvbo8r.v1...@hrunkner.hjp.at>
anspielst: Da war mit "die Applikation" die gesamte Applikation gemeint,
inklusive der ben�tzten Infrastruktur (externe Hilfsprogramme,
Libraries, OS-Code, Hardware, ...). Ich dachte, das war im Kontext klar,
aber vielleicht war es das nicht - sorry.

�berall sonst in diesem Thread habe ich soweit ich sehe immer deutlich
gemacht, dass ich mich auf eine spezifische Situation beziehe ("Wenn Du
...", "Falls er wirklich ...", ...).

> Du scheinst hier etwas durcheinander zu bringen.

Die Versuchung ist gro�, darauf mit "Nein, Du bringst hier was
durcheinander" zu antworten. Aber das w�re nicht konstruktiv. Ich hoffe,
ich habe die schlimmsten Missverst�ndnisse oben ausger�umt.

hp

[1] Gerade kurz in die Swing und JavaFX Doku reingeschaut: Kann das
sein, dass die keine HTML-Komponente haben?

[2] Aus Sicht des ABIs. Hardwarem��ig besteht es eher aus Worten.
Aber das sollte den Programmierer noch weniger k�mmern.

Arno Welzel

unread,

Jul 7, 2012, 6:50:01 AM7/7/12

to

Peter J. Holzer, 06.07.2012 22:46:

> On 2012-07-06 11:32, Arno Welzel <use...@arnowelzel.de> wrote:
>> Am 05.07.2012 23:09, schrieb Ralf Döblitz:
>>
>>> Arno Welzel <use...@arnowelzel.de> schrieb:
>> [...]
>>>> Es gibt kein "bekanntes internes Format des Systems". *Jeder* Text hat
>>>> irgendeine Codierung. Auch nach der "Dekodierung" muss bekannt sein, wie
>>>> die einzelnen Bytes zu interpretieren sind. Nur weil das darstellende
>>>> System dies weiss, ist es noch lange kein ominöses "internes Format".
>>>
>>> Hast du jemals programmiert? Wenn man in einer Software einen Bytestrom
>>
>> Ja, seit rund 21 Jahren hauptberuflich, davon schon fast 5 Jahre
>> hobbymäßig - in diversen Sprachen (C, C++, Java, C#...).
>
> Gut, dann muss man wenigstens nicht bei Adam und Eva anfangen. Immerhin
> dürfte Dir der Unterschied zwischen 4 Bytes, eine int (32 bit) und einem
> float bekannt sein.

Ja. Du hättest es auch gleich so schreiben können, dass in einer
*Programmiersprache* ein Bytestrom wahlweise als *Datentyp* "Zeichen"
darstellbar ist - das hätte viele Mißverständnisse vermieden.

> Dass man 20 Jahre programmieren kann, ohne die Grundlagen von
> Character-Encodings verstanden zu haben, haben ein paar Kollegen von mir
> auch schon demonstriert. Einer hat sich inzwischen dieses T-Shirt
> gekauft: http://www.geekwear.de/produkte/scheiss-encoding-shirt.html :-)

;-)

Im Ernst: Encoding interessiert mich exakt dann, wenn ich die Daten mit
einer selbst geschrieben Software lesen oder an eine andere Software
oder Komponente übergeben können muss. Genau dann muss ich wissen, ob
der vorliegende Bytestrom z.B. als UTF-8 zu interpretieren ist oder wie
ich den Bytestrom weitergeben muss, damit er korrekt interpretiert wird
- wie etwa bei HTML mit einem geeigneten META-Element oder durch einen
entsprechenden MIME- oder HTTP-Header.

[...]

Danke für die ausführlichen Beispiele.

Dass eine Laufzeitumgebung Byteströme unter Angabe des Encoding als Text
lesen und in ihrem eigenen Encoding verarbeitet, ist mir auch bekannt.
Spätestens bei der Ausgabe in der GUI geht das aber auch nur deswegen,
weil die Laufzeitumgebung wie etwa Gtk, weiss, in welchem Encoding die
GUI die Zeichen erwartet. Auch da ist es keinesfalls so, dass irgendein
ominöses "internes" Encoding verwendet wird, sondern es ist
selbstverständlich exakt definiert - bei Windows etwa durch Codepages
oder ab Windows NT aufwärts als Unicode.

Aber ich denke, wir haben das Thema jetzt erschöpfend ergründet ;-)

Michael Landenberger

unread,

Jul 7, 2012, 8:23:26 AM7/7/12

to

Am 07.07.2012 11:57, schrieb Peter J. Holzer:

> On 2012-07-06 11:25, Arno Welzel <use...@arnowelzel.de> wrote:

>> Im Verlauf dieser Fragestellung wurde dann die Idee erwähnt, dass der
>> Text "dekodiert" wird und dann an den Renderer übergeben wird.

>
> Ja, der OP hat behauptet, dass er das macht.

Ich habe das in der Tat anfangs so gemacht, ja. Ich bin aber sehr
schnell dahintergekommen, dass das wenig sinnvoll ist. Jetzt decodiere
ich nur noch gemäss MIME-Content-Transfer-Encoding-Header und lasse die
Zeichensatz-Codierung dabei unverändert (ich ersetze lediglich den im
HTML-Meta-Element deklarierten Zeichensatz durch den aus dem
MIME-Content-Type-Header). Um die Darstellung kümmert sich dann der
Renderer.

Anders ist es jedoch bei Plain Text. Hier arbeitet mein Programm bzw.
das zur Darstellung verwendete Steuerelement derzeit noch intern mit
8bit-Zeichen. Ergo müssen Multibyte-Zeichensätze wie z. B. UTF-8
zunächst in dieses Format umgewandelt werden. Diesen Vorgang bezeichnete
ich als "Decodierung", was aber leider Verwechslungsgefahr mit der
Quoted-Printable- oder Base64-Decodierung barg.

Bei Plain Text kann es aber auch keine Diskrepanzen zwischen
MIME-Zeichensatzdeklaration und Meta-Element-Zeichensatzdeklaration
geben, denn letztere gibt es ja bekanntlich bei Plain Text gar nicht.
Schon deshalb hatte ich damit auch nie Probleme.

Gruß

Michael

Thomas 'PointedEars' Lahn

unread,

Jul 12, 2012, 12:28:30 PM7/12/12

to

Ralf Döblitz wrote:

> Thomas 'PointedEars' Lahn <Point...@web.de> schrieb:
>> Ralf Döblitz wrote:
> [...]
>> ,-<http://www.w3.org/TR/REC-html40/charset.html#h-5.2.2>

>> |
>> | The HTTP protocol ([RFC2616], section 3.7.1) mentions ISO-8859-1 as a
>> | default character encoding when the "charset" parameter is absent from
>> | the "Content-Type" header field. In practice, this recommendation has
>> | proved useless because some servers don't allow a "charset" parameter
>> | to be sent, and others may not be configured to send the parameter.
>> | Therefore, user agents must not assume any default value for the
>> | "charset" parameter.

>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>> Das entsprechende Kapitel ist normativ und das "MUST NOT" daher
>> verbindlich.
>
> […]
> Wie sah das eigentlich vor HTML 4.0 aus? Denn früher galt das ja durch-
> aus mal (deshalb wird ja die Abweichung vom HTTP-RFC in obigem Teil an-
> gewiesen), insofern müßte man ja evtl. für Dokumente, die ältere HTML-
> Versionen deklarieren, dann anderes Verhalten implementieren.

Aber nur nach einer Zeitreise :)

--
PointedEars

Please do not Cc: me. / Bitte keine Kopien per E-Mail.

Thomas 'PointedEars' Lahn

unread,

Jul 12, 2012, 12:45:07 PM7/12/12

to

Peter J. Holzer wrote:

> On 2012-07-02 22:06, Heiko Schlenker <hsc...@gmx.de> wrote:
>> * Michael Landenberger <spameim...@arcor.de> schrieb:
>>> Am 02.07.2012 17:17, schrieb Arno Welzel:
>>>> Wieso hängt die Art der Dekodierung vom Zeichensatz ab?
>>> Weil auch ein Zeichensatz wie z. B. UTF-8 decodiert werden muss.
>>
>> Achtung, Missverständnisgefahr. UTF-8 ist kein Zeichensatz, sondern
>> eine Kodierung des Unicode-Zeichensatzes.

ACK.

> Korrekt.
>
> Aber der Parameter heißt nun einmal "charset", auch wenn in irgendeinem
> MIME-RFC sogar drinsteht, dass die Namenswahl unglücklich war
> ("char-encoding" o.ä. wäre vermutlich besser gewesen).

Ja.

> In der Praxis macht es aber wenig Unterschied: Der Parameter gibt an,
> wie Folgen von Bytes in Folgen von (abstrakten) Zeichen umgewandelt
> werden müssen. Ob das nun direkt (ISO-8859-15: 0xA4 -> EURO SIGN) oder
> über einen Zwischenschritt (UTF-8: 0xE2 0x82 0xAC -> Unicode: U+20AC ->
> EURO SIGN) geschieht, ist egal (vor allem, weil die Implementation das
> sowieso so machen kann, wie sie will, es muss nur am Schluss das
> richtige Zeichen angezeigt werden.

Der Unterschied zwischen Zeichensatz und Zeichencodierung ist _nicht_ egal,
weil ein Zeichensatz eben aus Zeichen an bestimmten Koordinaten
(Codepunkten) besteht. Die Zeichencodierung beschreibt hingegen, mit
welcher Codierung die Zeichen eines Textes (genauer: die Codepunkt-Werte
jedes einzelnen Zeichens) prinzipiell *(irgend)eines* Zeichensatzes zu
codieren ist (wobei der Fall häufig ist, dass ein Zeichensatz nur eine
mögliche Zeichencodierung zulässt, z. B. ISO-8859-x).

Noch mal das Beispiel HTML: Der Document Character Set, d. h. der
Zeichensatz eines HTML-Dokuments ist der Universal Character Set (UCS), wie
er für die Zeichencodierung UCS-2 spezifiziert war/ist (Beleg hatte ich in
diesem Thread geliefert). Ein HTML-Benutzerprogramm muss also *diese*
*Zeichen* (und tatsächlich *nur* diese) prinzipiell *darstellen* können
(Abhängigkeiten von Schriftarten ignorieren wir jetzt mal). Um die Zeichen
dieses Zeichensatzes, mithin die Codepunkt-Werte zu codieren, kann aber
*jede* *beliebige* *Zeichencodierung* verwendet werden, nicht nur (und am
besten aus Kompatibilitätsgründen gar nicht) UCS-2.

Man muss sich also darüber im Klaren sein, dass der Wert des `Content-Type'-
Parameters, *obwohl* der Parameter `charset' heisst, die Zeichen*codierung*
der Ressource angibt und eben _nicht_ den Zeichensatz.

Thomas 'PointedEars' Lahn

unread,

Jul 12, 2012, 12:53:09 PM7/12/12

to

Michael Landenberger wrote:

> Am 03.07.2012 12:11, schrieb Arno Welzel:
>> Die Bytfolge 0xC3, 0xA4 *ist* schon ein "ä", dargestellt als UTF-8. Was
>> soll daran noch dekodiert werden?
>
> Sofern das (Windows-)Steuerelement, das das "ä" darstellen soll, ein
> anderes Format als UTF-8 erwartet, muss der Text vor der Anzeige in
> dieses andere Format umgewandelt werden. Beispielsweise kann ein
> Control, das ANSI-Text erwartet, mit 0xC3 0xA4 nichts anfangen. Damit es
> ein "ä" anzeigt, muss man ihm stattdessen ein 0xF6 liefern.
>
> Auf das IE-Control trifft das allerdings nicht zu, das kann man direkt
> mit UTF-8 füttern (man muss ihm nur sagen, dass es UTF-8 ist, womit es
> gefüttert wurde). Wie es das dann intern verarbeitet, kann ich nicht
> sagen.
>
> Den MIME-Typ text/plain zeigt mein Mailclient allerdings selbst an,
> wobei das dafür verwendete Control ANSI-Text erwartet. Liegt der Text in
> UTF-8 vor, muss er also wie oben beschrieben in ANSI umgewandelt werden

> […]

Du möchtest Dich über die Grundlagen informieren, bevor Du argumentierst:

<http://de.wikipedia.org/wiki/ANSI> ff.
<http://de.wikipedia.org/wiki/UTF-8> ff.

TL;DR:

1. Es gibt keinen "ANSI-Zeichensatz".
2. UTF-8 lässt sich nicht (verlustfrei) in Windows-125x umwandeln,
da UTF-8 Unicode-Zeichen codiert (65536+) und Windows-125x nicht (256).
3. Unicode wird seit mehr als einer Dekade vom Windows-API unterstützt.

Thomas 'PointedEars' Lahn

unread,

Jul 12, 2012, 12:56:21 PM7/12/12

to

> Unicode-Codepoint an (vollkommen unabhängig vom charset) […]

<nitpick>den _UCS_-Codepunkt</nitpick>

Thomas 'PointedEars' Lahn

unread,

Jul 12, 2012, 1:05:10 PM7/12/12

to

Ralf Döblitz wrote:

> Arno Welzel <use...@arnowelzel.de> schrieb:

>> Es gibt kein "bekanntes internes Format des Systems". *Jeder* Text hat
>> irgendeine Codierung. Auch nach der "Dekodierung" muss bekannt sein, wie
>> die einzelnen Bytes zu interpretieren sind. Nur weil das darstellende
>> System dies weiss, ist es noch lange kein ominöses "internes Format".
>

> Hast du jemals programmiert? Wenn man in einer Software einen Bytestrom

> zu einem Zeichenstrom dekodiert hat, dann liegen die Dateen danach im
> internen Format dieses Softwaresystems vor. Heute werden das häufig

> Unicode-Codepoints sein.

Das ist grober Unfug. Das sogenannte "interne Format" ist nichts anderes
als die Oktetts, die sich ergeben, wenn man den Text *in einer bestimmten
Zeichencodierung* speichert. (Bei ECMAScript-Implementierungen ist das in
der Regel UTF-16, wie in ECMA-262-5.1, Abschnitte 4.3.16 und 8.4
beschrieben.) Es werden in keiner mir bekannten Programmiersprache die
Codepunkte der Zeichen gespeichert. Das heisst, dass zeichenbasierte
Funktionen der Programmiersprache mit diesen Oktett-Folgen umgehen können
müssen.

Thomas 'PointedEars' Lahn

unread,

Jul 12, 2012, 1:14:52 PM7/12/12

to

Peter J. Holzer wrote:

> Michael Landenberger wrote:
>> Am 01.07.2012 19:14, schrieb Peter J. Holzer:
>>> Um den HTML-Text in ein File zu schreiben, musst Du ihn wieder
>>> encodieren,
>>
>> Nö, warum? Einen Base64-encodierten JPG-Anhang encodiere ich auch nicht
>> wieder, bevor ich ihn in eine JPEG-Datei exportiere, denn andernfalls
>> könnte kein JPEG-Viewer mit der erzeugten Datei etwas anfangen.
>
> Du verwechselst die Kodierungsebenen. Base64 bzw. Quoted-Printable ist
> Content-Transfer-Encoding. Dabei wird ein Bytestrom so kodiert, dass er
> in einer syntaktisch korrekten RFC-5322-E-Mail transportiert werden
> kann.

Nein, er wird so codiert, dass er verlustfrei den Transfer durch eine 7-
bittige Leitung übersteht. Um konform Internet Message Format zu sein,
bedarf es *keines* Content-Transfer-Encoding.

Peter J. Holzer

unread,

Jul 15, 2012, 7:42:43 AM7/15/12

to

Für die Dekodierung *ist* das egal. Es macht im Endeffekt überhaupt
keinen Unterschied, ob ich die Bytefolgen 0xE2 0x82 0xAC und 0xAC 0x20
als verschiedene Kodierungen des gleichen Charactersets ansehe und
0x80 als Kodierung eines anderen Charactersets, als Kodierungen von drei
verschiedenen Charactersets, oder als drei verschiedene Kodierungen ein-
und desselben Charactersets.

Peter J. Holzer

unread,

Jul 15, 2012, 7:59:56 AM7/15/12

to

On 2012-07-12 16:56, Thomas 'PointedEars' Lahn <Point...@web.de> wrote:
> Peter J. Holzer wrote:

>> Unicode-Codepoint
>
><nitpick>den _UCS_-Codepunkt</nitpick>

Das Unicode Consortium ist anderer Meinung.

Peter J. Holzer

unread,

Jul 15, 2012, 8:19:57 AM7/15/12

to

On 2012-07-12 17:14, Thomas 'PointedEars' Lahn <Point...@web.de> wrote:
> Peter J. Holzer wrote:

>> Du verwechselst die Kodierungsebenen. Base64 bzw. Quoted-Printable ist
>> Content-Transfer-Encoding. Dabei wird ein Bytestrom so kodiert, dass er
>> in einer syntaktisch korrekten RFC-5322-E-Mail transportiert werden
>> kann.
>
> Nein, er wird so codiert, dass er verlustfrei den Transfer durch eine 7-
> bittige Leitung übersteht.

Nein, das ist nicht hinreichend. Das RFC-5322-Format kennt zusätzliche
Einschränkungen, insbesondere besteht die gesamte Message aus Zeilen
einer maximalen Länge, die mit CRLF abgeschlossen werden und in denen CR
und LF nicht isoliert vorkommen dürfen.

(Abgesehen davon definiert RFC 5322 tatsächlich nur Messages, die aus
US-ASCII Characters 1 - 127 bestehen. Für Erweiterungen wird auf die
MIME-Serie verwiesen).

> Um konform Internet Message Format zu sein, bedarf es *keines*
> Content-Transfer-Encoding.

Kommt auf den Inhalt an. Für manche Inhalte ist es notwendig. Das kann
auch bei HTML der Fall sein, z.B. wenn Zeilen zu lang sind.

7-Bit-Leitungen sind heute auch bei E-Mail kein ernstzunehmendes
Argument mehr, RFC-5322-Syntax hingegen schon.

Thomas 'PointedEars' Lahn

unread,

Sep 2, 2012, 5:51:41 PM9/2/12

to

Peter J. Holzer wrote:

> Thomas 'PointedEars' Lahn wrote:
>> Peter J. Holzer wrote:
>>> In der Praxis macht es aber wenig Unterschied: Der Parameter gibt an,
>>> wie Folgen von Bytes in Folgen von (abstrakten) Zeichen umgewandelt
>>> werden müssen. Ob das nun direkt (ISO-8859-15: 0xA4 -> EURO SIGN) oder
>>> über einen Zwischenschritt (UTF-8: 0xE2 0x82 0xAC -> Unicode: U+20AC ->
>>> EURO SIGN) geschieht, ist egal (vor allem, weil die Implementation das
>>> sowieso so machen kann, wie sie will, es muss nur am Schluss das
>>> richtige Zeichen angezeigt werden.
>>
>> Der Unterschied zwischen Zeichensatz und Zeichencodierung ist _nicht_
>> egal, weil ein Zeichensatz eben aus Zeichen an bestimmten Koordinaten
>> (Codepunkten) besteht. Die Zeichencodierung beschreibt hingegen, mit
>> welcher Codierung die Zeichen eines Textes (genauer: die Codepunkt-Werte
>> jedes einzelnen Zeichens) prinzipiell *(irgend)eines* Zeichensatzes zu
>> codieren ist (wobei der Fall häufig ist, dass ein Zeichensatz nur eine
>> mögliche Zeichencodierung zulässt, z. B. ISO-8859-x).
>
> Für die Dekodierung *ist* das egal.

Keineswegs.

> Es macht im Endeffekt überhaupt keinen Unterschied, ob ich die Bytefolgen
> 0xE2 0x82 0xAC und 0xAC 0x20 als verschiedene Kodierungen des gleichen
> Charactersets ansehe

Doch. In diesem Fall könnten theoretisch Unicode-Zeichen herauskommen (das
erste wäre ein UTF-8-codiertes U+20AC EURO SIGN, das zweite wäre eine im
Unicode-Standard AFAIK nicht definierte, weil nicht eindeutige
Zeichencodierung).

Es muss also im allgemeinen Fall erstens die Codierung klar und unterstützt
sein und zweitens eine Schriftart verwendet werden, welche die betreffenden
Unicode-Zeichen auf den entsprechenden Codepunkten enthält bzw. notfalls ein
Mapping zwischen den decodierten Codepunkten zu diesen.

Zum ersten Punkt muss u. U. auch die Bytereihenfolge klar sein, damit
überhaupt ein sinnvoller Codepunkt berechnet werden kann.

> und 0x80 als Kodierung eines anderen Charactersets,

0x80 codiert in der überschaubaren Windows-125x-Familie bereits zwei
unterschiedliche Zeichen, in Abhängigkeit von dem Zeichensatz, den wiederum
die Codierung definiert. In Windows-1252 bis -1258 codiert es das Euro-
Symbol (€), in Windows-1251 das kyrillische grosse Dsche (Ђ).

Umgekehrt: In ISO/IEC 8859-1 gibt es kein Euro-Symbol, in ISO/IEC 8859-15
wird es mit 0xA4 codiert, in Windows-1252 ("ISO-8859-1") mit 0x80 und in Mac
OS Roman mit 0xDB.

Wenn ich also ein Byte (in Erweiterung: eine Oktett-Sequenz) eines Textes
einlese, muss ich es/diese je entsprechend der verwendeten Zeichencodierung
behandeln. Da die Zeichencodierung nicht trivial eindeutig ermittelbar ist,
sollte sie bzw. muss sie deklariert werden. Dies kann entweder über
Metadaten oder mit einem Byte Order Mark (BOM) geschehen.

> als Kodierungen von drei verschiedenen Charactersets,

Ein Text besteht aus Zeichen *eines* Zeichensatzes; _nicht_ mehrerer. Daher
die Betonung auf "eines" oben. Du velwechserst offensichtlich Zeichensätze
mit Schriften (Skripte). Ein Zeichensatz kann Zeichen verschiedener Skripte
enthalten; Unicode ist hier das beste Beispiel.

> oder als drei verschiedene Kodierungen ein- und desselben Charactersets.

Ein *Text* kann sinnvollerweise nur in einer einzigen Zeichencodierung
vorliegen, da die Zeichencodierung den Zeichensatz bestimmt, durch den
Codepunkte Schriftzeichen zugeordnet werden (und umgekehrt).

Unicode wurde unter anderem deshalb entwickelt, weil es nicht länger tragbar
war, sich in Dokumenten auf einen Zeichensatz, der lediglich den
*Buchstaben* einer Sprache (z. B. Englisch) oder Schriftfamilie (z. B.
lateinische Schrift) gerecht wurde, zu beschränken. Nicht umsonst ist der
Unicode-Zeichensatz sowohl in Zeichen als auch Codepunkten eine Obermenge
von ISO/IEC 8859-1 (Latin-1).

--
PointedEars

Twitter: @PointedEars2

Thomas 'PointedEars' Lahn

unread,

Sep 2, 2012, 5:58:13 PM9/2/12

to

Peter J. Holzer wrote:

> On 2012-07-12 16:56, Thomas 'PointedEars' Lahn <Point...@web.de> wrote:
>> Peter J. Holzer wrote:
>>> Unicode-Codepoint
>> <nitpick>den _UCS_-Codepunkt</nitpick>
>
> Das Unicode Consortium ist anderer Meinung.

Das Unicode-Konsortium definiert nicht den Universal Character Set-2, den
HTML 4.01 per Spezifikation verwendet, sondern Unicode. Seine Meinung dazu,
wenn sie von meiner Aussage abwiche, wäre daher irrelevant.

Ich schrieb übrigens die beiden Tags, weil mir die Gemeinsamkeiten von UCS-2
und Unicode 2.0 aufwärts sehr wohl bekannt sind.

--
PointedEars

Twitter: @PointedEars2

Thomas 'PointedEars' Lahn

unread,

Sep 2, 2012, 6:09:14 PM9/2/12

to

Peter J. Holzer wrote:

> Thomas 'PointedEars' Lahn wrote:
>> Peter J. Holzer wrote:
>>> Du verwechselst die Kodierungsebenen. Base64 bzw. Quoted-Printable ist
>>> Content-Transfer-Encoding. Dabei wird ein Bytestrom so kodiert, dass er
>>> in einer syntaktisch korrekten RFC-5322-E-Mail transportiert werden
>>> kann.
>>
>> Nein, er wird so codiert, dass er verlustfrei den Transfer durch eine 7-
>> bittige Leitung übersteht.
>
> Nein, das ist nicht hinreichend.

Es ging hier um die Gründe für die Verwendung von Base64 bzw. Quoted-
Printable in E-Mail.

> Das RFC-5322-Format kennt zusätzliche Einschränkungen, insbesondere
> besteht die gesamte Message aus Zeilen einer maximalen Länge, die mit CRLF
> abgeschlossen werden und in denen CR und LF nicht isoliert vorkommen
> dürfen.

Die maximale Zeilenlänge und der Abschluss mit CRLF waren aus
Kompatibilitätsgründen schon lange vor RFC 5322 Pflicht, aber all das ist in
Bezug auf die hier diskutierte Fragestellung hochgradig irrelevant.

> (Abgesehen davon definiert RFC 5322 tatsächlich nur Messages, die aus
> US-ASCII Characters 1 - 127 bestehen. Für Erweiterungen wird auf die
> MIME-Serie verwiesen).

Ach.[tm]

>> Um konform Internet Message Format zu sein, bedarf es *keines*
>> Content-Transfer-Encoding.
>
> Kommt auf den Inhalt an. Für manche Inhalte ist es notwendig. Das kann
> auch bei HTML der Fall sein, z.B. wenn Zeilen zu lang sind.

Äpfel und Birnen. Content-Transfer-Encoding in E-Mails hat mit erzwungenen
Zeilenumbrüchen im Message Body genau gar nichts zu tun. Es geht dabei
ausschliesslich darum, für die Informationsübertragung falls nötig mit 7 Bit
codierbare (US-ASCII-)Zeichen zu erzeugen. Bei anderen, neueren Internet-
Nachrichtentypen kommen zusätzlich Features wie Komprimierung (heutzutage
i. d. R. gzip) ins Spiel.

> 7-Bit-Leitungen sind heute auch bei E-Mail kein ernstzunehmendes
> Argument mehr,

Beweis durch Behauptung.

> RFC-5322-Syntax hingegen schon.

Insbesondere vor RFC 5322 wurden E-Mails schon gern so codiert, dass sie
durch eine 7-bittige Leitung passten. Du passt nicht auf.

--
PointedEars

Twitter: @PointedEars2

Peter J. Holzer

unread,

Sep 3, 2012, 1:41:55 PM9/3/12

to

On 2012-09-02 21:51, Thomas 'PointedEars' Lahn <Point...@web.de> wrote:
[wirres Zeug]

Lieber Thomas, Du solltest nicht auf 7 Wochen alte Postings antworten.
Offensichtlich bist Du damit �berfordert, �ber diesen Zeitraum das Thema
eines Threads soweit im Kopf zu behalten, dass Deine Antwort wenigstens
noch irgendwie dazupasst.

Detlef Meißner

unread,

Sep 3, 2012, 3:11:23 PM9/3/12

to

Peter J. Holzer schrieb:

> On 2012-09-02 21:51, Thomas 'PointedEars' Lahn <Point...@web.de> wrote:
> [wirres Zeug]
>
> Lieber Thomas, Du solltest nicht auf 7 Wochen alte Postings antworten.

> Offensichtlich bist Du damit überfordert, über diesen Zeitraum das Thema

> eines Threads soweit im Kopf zu behalten, dass Deine Antwort wenigstens
> noch irgendwie dazupasst.

Wie auch in anderen Gruppen erkennbar,scheint er sich gerade zu langweilen.

Detlef

Thomas 'PointedEars' Lahn

unread,

Sep 4, 2012, 1:24:11 PM9/4/12

to

Peter J. Holzer wrote:

> On 2012-09-02 21:51, Thomas 'PointedEars' Lahn <Point...@web.de> wrote:
> [wirres Zeug]
>
> Lieber Thomas, Du solltest nicht auf 7 Wochen alte Postings antworten.

> Offensichtlich bist Du damit überfordert, über diesen Zeitraum das Thema

> eines Threads soweit im Kopf zu behalten, dass Deine Antwort wenigstens
> noch irgendwie dazupasst.

Lieber Peter *örks*, Network News ist kein Echtzeitkommunikationsmedium und
E-Mail existiert. Nur weil Du nicht mehr in der Lage bist, nach o. g. Zeit
einen Zusammenhang zwischen Postings herzustellen, heisst das noch lange
nicht, dass ein neues Posting in einem älteren Thread wirr oder gar
irrelevant ist.

Score adjusted

--
F'up2 PointedEars