Re: Parallels -> VMware Fusion Upgrade für $9.99

"Juergen P. Meier" <nospam-1984@xxxxxxxx> writes:

Das Verfaelschen hat *deine* Software gemacht, die hat aus den
Duebeln Euro-Zeichen in UTF-8 gemacht. Meine software hat *deine*
UTF-8 Euro-Symbole dann lediglich in ISO 8859-15 neu kodiert.

Hmmm... ohne mich da allzusehr einmischen zu wollen: Hier kam Geralds
Post als content-encoding UTF-8 an und besagte Dübel/Währungssymbole
hatten brav die ursprüngliche Codierung 0xA4.

Das Problem ist der Wechsel der content-encodings, würde ich
vermuten. Der Codepoint 0xA4 hat in Latin-1 die Entsprechung als
Dübel/Währungssymbol und in Latin-9 wird aus diesem Codepoint dann das
Euro-Zeichen. Ich bin kein Zeichensatz-/Unicode-Experte, daher ist mir
nicht klar, was Dein slrn da hätte sinnvolles tun können/sollen, außer
den Codepoint einfach übernehmen. Durch das neue content-encoding wird
dann aus dem Dübel eben das Euro-Zeichen.

Warum du UTF-8 machst, wo alle Zeichen vollstaendig in ISO kodierbar
sind, und dann auch noch falsch kodierst, musst du selbst
rausfinden.

Also falsch codiert hat Geralds Thunderbird eigentlich nicht. Laut

http://www.utf8-zeichentabelle.de/

ist auch in UTF-8 der Codepoint 0xA4 das Währungssymbol (exakt wie in
Latin-1, dem content-encoding von Basars Post):

U+00A4 ¤ c2 a4 CURRENCY SIGN

Und damit wurde Basars Codierung insbesondere auch semantisch korrekt
wiedergegeben. Es ist ja nicht verboten, UTF-8 zu bevorzugen.

Das Problem ist nun, dass Du Deinen slrn vermutlich so eingestellt
hast, dass Latin-9 bevorzugt verwendet werden soll. Ganz streng
genommen hätte slrn eigentlich gar kein Latin-9 verwenden dürfen, da
es das CURRENCY SIGN in dieser Zeichensatzkodierung gar nicht gibt,
eine semantisch korrekte Wiedergabe also gar nicht möglich
ist. Insofern wäre hier, wenn überhaupt, höchstens slrn resp. Deine
(evtl. zu eng konfigurierte Wahlfreiheit der Zeichsatzkodierung) ein
klein wenig Schuld.

--
Stefan.
.