E-MAIL und UTF-8

[Stefan]

Hallo,

ich habe ein HTML E-Mail-Template im UTF-8 Zeichensatz erstellt und sowohl im HTML-Header als auch im Mail-Header UTF-8 als Zeichensatz gewählt.

Leider wird die E-Mail in Outlook beim Öffnen mit ISO 5598-1 Encoding angezeigt und somit Sonderzeichen und Umlaute nicht korrekt dargestellt. Was muss ich tun, um sicherzugehen, dass der Mail-Client (v.a. Outlook) den richtigen Zeichensatz erkennt?

Vielen Dank für eure Hilfe.
Gruß, Stefan

[Stefan]

Es muss natürlich ISO 8859-1 heißen.
Gruß, Stefan

[Joerg]

Hi,

ich habe ein HTML E-Mail-Template im UTF-8 Zeichensatz erstellt und sowohl im HTML-Header als auch im Mail-Header UTF-8 als Zeichensatz gewählt.

Hmmm ... bei vielen mail-Clients wird per default nur plain text angezeigt, da nuetzt ein HTML-template wenig ... ;-)

Was muss ich tun, um sicherzugehen, dass der Mail-Client (v.a. Outlook) den richtigen Zeichensatz erkennt?

Wenn den Zeilrechner kein UTF-8 hat/unterstuetzt, nuetzt der schoenste mail-Header nichts. "For the time being" wuerde ich beim ISO-encoding fuer e-mail bleiben.

HTH,

• Joerg

[Stefan]

Hi Jörg,

ich habe ein HTML E-Mail-Template im UTF-8 Zeichensatz erstellt und sowohl im HTML-Header als auch im Mail-Header UTF-8 als Zeichensatz gewählt.

Hmmm ... bei vielen mail-Clients wird per default nur plain text angezeigt, da nuetzt ein HTML-template wenig ... ;-)

Bei der Textversion habe ich das Problem natürlich auch...

Was muss ich tun, um sicherzugehen, dass der Mail-Client (v.a. Outlook) den richtigen Zeichensatz erkennt?

Wenn den Zeilrechner kein UTF-8 hat/unterstuetzt, nuetzt der schoenste mail-Header nichts. "For the time being" wuerde ich beim ISO-encoding fuer e-mail bleiben.

Aber wenn der Zielclient es unterstützt - und das tut mein Outlook, dann möchte ich gern, dass UTF-8 beim Öffnen der Mail richtig erkannt und dargestellt wird.

Grüße, Stefan

[Christian Kruse]

你好 Stefan,

Was muss ich tun, um sicherzugehen, dass der Mail-Client (v.a. Outlook) den richtigen Zeichensatz erkennt?

Wenn den Zeilrechner kein UTF-8 hat/unterstuetzt, nuetzt der schoenste mail-Header nichts. "For the time being" wuerde ich beim ISO-encoding fuer e-mail bleiben.

Ach, das ist doch Unsinn. Moderne Systeme unterstützen inzwischen alle UTF-8. Selbst die Konsolen-Programme für Unix/Linux unterstützen das inzwischen fast alle.

Aber wenn der Zielclient es unterstützt - und das tut mein Outlook, dann möchte ich gern, dass UTF-8 beim Öffnen der Mail richtig erkannt und dargestellt wird.

Schonmal den Quelltext der Mail angeschaut? Sicher, dass da alles richtig ist? Und dann: Zeichensatzerkennung auf Automatisch gestellt? Oder einen fest vorgegeben?

再见,
 克里斯蒂安

[Stefan]

Hallo Christian,

Schonmal den Quelltext der Mail angeschaut? Sicher, dass da alles richtig ist?

Ich habe das Problem soeben gelöst. Hatte in meinem PHP-Code zum Schreiben des Mail-Headers einen Fehler.

Und dann: Zeichensatzerkennung auf Automatisch gestellt? Oder einen fest vorgegeben?

Ich habe einen festen Zeichensatz mitgegeben.

Grüße, Stefan

[L00NIX]

Hi.

ich habe ein HTML E-Mail-Template im UTF-8 Zeichensatz erstellt
und sowohl im HTML-Header als auch im Mail-Header UTF-8 als
Zeichensatz gewählt.

Sorry, aber das ist Blödsinn!

Wenn du eine Vorlage machst, dann möglichst us-ascii oder wenn
Umlaute nötig iso-8859-1.

Warum?

Ganz einfach:

Du weißt nicht, was auf der Gegenseite für ein Mailprogramm benutzt
wird und das versucht entsprechend der im Mailheader angegebenen
Codierung die Mail korrekt anzuzeigen. Normalerweise entscheidet auch
dein Mailprogramm, welcher Ausgangzeichensatz verwendet wird und zwar
verschickt es, wenn möglich, eben als us-ascii (7Bit). Mit Umlauten
ist das dann nicht möglich und es schwenkt um auf iso-8859-1, wenn
auch noch das Eurozeichen drin ist iso-8859-15, etc.

UTF-8 aber ist der absolute Overkill, auch in Bezug auf die 16-Bit
Codierung (also 9 Bit /Zeichen mehr als us-ascii!).

Lass dein Mailprogramm die Ausgangcodierung entscheiden und verwende
möglichst wenige "Sonderzeichen" in deiner Vorlage, es sei denn, du
bist darauf angewiesen.

Gruß
L00NIX

[Sven (κ)]

Hallo L00NIX,

UTF-8 aber ist der absolute Overkill, auch in Bezug auf die 16-Bit
Codierung (also 9 Bit /Zeichen mehr als us-ascii!).

UTF-8 verwendet iirc 8 Bit/Zeichen, d.h. genauso viel wie ISO 8859-1(5). Du meintest vermutlich UTF-16.

Grüße,

Sven

[Christian Kruse]

你好 Sven,

UTF-8 aber ist der absolute Overkill, auch in Bezug auf die 16-Bit
Codierung (also 9 Bit /Zeichen mehr als us-ascii!).

UTF-8 verwendet iirc 8 Bit/Zeichen, d.h. genauso viel wie ISO 8859-1(5). Du meintest vermutlich UTF-16.

UTF-8 benutzt zwischen 8 und 42 Bit (1-6 Octetts) pro Zeichen. Die Code-Einheiten sind allerdings jeweils 8 Bit gross, das stimmt.

UTF-16 benutzt übrigens zwischen 16 und 32 Bit pro Zeichen. Die Code-Einheiten sind dabei 16 Bit gross.

UTF-32 benutzt immer 32 Bit pro Zeichen, die Code-Einheiten sind auch immer 32 Bit gross.

再见,
 克里斯蒂安

[Sven (κ)]

Moin Christian,

UTF-8 benutzt zwischen 8 und 42 Bit (1-6 Octetts) pro Zeichen. Die Code-Einheiten sind allerdings jeweils 8 Bit gross, das stimmt.

Jep, das ist der Grund, weswegen ASCII-Zeichen im #selfchat immer wunderbar funktionieren und aus UTF-8 "ö"s plötzlich zwei Sonderzeichen werden ;-)

UTF-16 benutzt übrigens zwischen 16 und 32 Bit pro Zeichen. Die Code-Einheiten sind dabei 16 Bit gross.

UTF-8 kann ja (iirc) alle Unicode-Zeichen darstellen. UTF-16 auch. Welchen Vorteil hat dann letzteres?

UTF-32 benutzt immer 32 Bit pro Zeichen, die Code-Einheiten sind auch immer 32 Bit gross.

und vor allem, welchen Vorteil hat UTF-32?

Grüße,

Sven

PS: Ein Vorteil fällt mir ein: Wenn man chinesisch schreibt (wie du), kann man die Position einzelner Zeichen z.B. bei UTF-32 wesentlich schneller herausfinden, bei UTF-8 muss man sie ja erst fast "berechnen" (bzw. den ganzen Text durchgehen)

[Christian Kruse]

你好 Sven,

UTF-16 benutzt übrigens zwischen 16 und 32 Bit pro Zeichen. Die Code-Einheiten sind dabei 16 Bit gross.

UTF-8 kann ja (iirc) alle Unicode-Zeichen darstellen. UTF-16 auch. Welchen Vorteil hat dann letzteres?

UTF-16 ist optimiert auf die sog. „Basic multilingual plane”, das heisst im Standard-Fall kann alles in 16 Bit kodiert werden. Erst wenn es „aussergewöhnlich” wird, werden 32 Bit benötigt.

UTF-32 benutzt immer 32 Bit pro Zeichen, die Code-Einheiten sind auch immer 32 Bit gross.

und vor allem, welchen Vorteil hat UTF-32?

Die Einfachheit. Keine variable Länge der Code Units, alle sind 32 Bit lang. Man kann also z. B. sofort erkennen, wie lang die Zeichenkette ist. Beim schneiden von Zeichenketten (substring oder so) muss man nicht auf Zeichengrenzen aufpassen, etc, pp. Man kann diese Kodierung viel einfacher verarbeiten. Bei UTF-16 muss man da sehr aufpassen, bei UTF-8 noch viel mehr.

再见,
 克里斯蒂安

[Dennis]

Hi Christian,

Die Einfachheit. Keine variable Länge der Code Units, alle sind 32 Bit lang. Man kann also z. B. sofort erkennen, wie lang die Zeichenkette ist. Beim schneiden von Zeichenketten (substring oder so) muss man nicht auf Zeichengrenzen aufpassen, etc, pp. Man kann diese Kodierung viel einfacher verarbeiten.

Ich weiß nicht, ob ich das jetzt richtig verstanden habe - aber heißt das dann, dass ein einfacher Text der nur aus ACII Zeichen besteht in UTF-32 mehr Speicherplatz benötigt (weil für jedes Zeichen 32 Bit benötigt) als in UTF-8 (wo für normale ASCII-Zeichen sicherlich nur 8 Bit oder so benötigt werden)?

Bei UTF-16 muss man da sehr aufpassen, bei UTF-8 noch viel mehr.

Da sieht man mal wieder, was du mit der Programmierung dieses Forum geleistet hast, wovon man als normaler User gar nichts weiß ;-)

MfG, Dennis.

[Der Martin]

Hallo Dennis,

Ich weiß nicht, ob ich das jetzt richtig verstanden habe - aber heißt das dann, dass ein einfacher Text der nur aus ASCII Zeichen besteht in UTF-32 mehr Speicherplatz benötigt (weil für jedes Zeichen 32 Bit benötigt) als in UTF-8 (wo für normale ASCII-Zeichen sicherlich nur 8 Bit oder so benötigt werden)?

genau so ist es. UTF-32 eignet sich damit bestens für große Rechner-Architekturen, deren CPU sowieso nicht weniger als 32bit auf einmal adressieren kann. Aber nicht für kleinere Maschinen, wo Speicherplatz noch ein Thema sein könnte, und noch weniger für die Datenübertragung, wo die Bandbreite und damit das Übertragungsvolumen *immer* kostbar ist.

Bei UTF-16 muss man da sehr aufpassen, bei UTF-8 noch viel mehr.
Da sieht man mal wieder, was du mit der Programmierung dieses Forum geleistet hast, wovon man als normaler User gar nichts weiß ;-)

ACK. :-)

Schönen Abend noch,
 Martin

[Sven Rautenberg]

Moin!

Ich weiß nicht, ob ich das jetzt richtig verstanden habe - aber heißt das dann, dass ein einfacher Text der nur aus ACII Zeichen besteht in UTF-32 mehr Speicherplatz benötigt (weil für jedes Zeichen 32 Bit benötigt) als in UTF-8 (wo für normale ASCII-Zeichen sicherlich nur 8 Bit oder so benötigt werden)?

Genau das heißt das.

Alle ASCII-Zeichen (also die 7-Bit-Version) sind im Unicode kompatibel platziert, haben also den identischen Zahlencode, und dementsprechend passen sie  in genau eine Codeeinheit von UTF-8 - nehmen also genausoviel Platz ein.

In UTF-32 hat jedes Zeichen 4 Byte - also drei mehr, als ASCII. Texte benötigen somit dreimal mehr Platz, von dem der meiste aus Nullbytes besteht.

Bei UTF-16 muss man da sehr aufpassen, bei UTF-8 noch viel mehr.

Da sieht man mal wieder, was du mit der Programmierung dieses Forum geleistet hast, wovon man als normaler User gar nichts weiß ;-)

In erster Annäherung ist UTF-8 eigentlich sehr simpel zu handhaben - nämlich genauso, wie jede andere Codierung auch. Die Postings vom Browser kommen schon direkt damit codiert an, werden simpel gespeichert, wieder ausgegeben, und der Browser zeigt das richtige Zeichen an - fertig.

Spannend wird's dann, wenn man Stringfunktionen auf den Text anwendet, insbesondere diejenigen, die eventuell aus Einfachheitsgründen einfach nur die Anzahl der Bytes zählen bzw. an Bytegrenzen den String zerschnippeln. Die funktionieren so simpel eben nicht mehr. Aber auch dafür gibts Bibliotheken, die das für einen erledigen können. :)

ASP ist übrigend voll unicode-fähig, während PHP damit immer noch ein paar grundsätzliche Probleme hat. Scheint also doch nicht so simpel zu sein.

- Sven Rautenberg

[Dennis]

Hi Sven,

In UTF-32 hat jedes Zeichen 4 Byte - also drei mehr, als ASCII. Texte benötigen somit dreimal mehr Platz, von dem der meiste aus Nullbytes besteht.

Ok, das entspricht dem was ich mir gedacht hatte - man speichert einfach mal einen Haufen Nullbytes ab ;-)

ASP ist übrigend voll unicode-fähig, während PHP damit immer noch ein paar grundsätzliche Probleme hat. Scheint also doch nicht so simpel zu sein.

Wenn ich mich richtig erinnere ist für PHP6 volle Unicode-Unterstützung geplant - ob dann auch endlich ein simples str_replace("ü", ...) funktioniert? *hoff*

MfG, Dennis.

[Christian Kruse]

你好 Dennis,

Die Einfachheit. Keine variable Länge der Code Units, alle sind 32 Bit lang. Man kann also z. B. sofort erkennen, wie lang die Zeichenkette ist. Beim schneiden von Zeichenketten (substring oder so) muss man nicht auf Zeichengrenzen aufpassen, etc, pp. Man kann diese Kodierung viel einfacher verarbeiten.

Ich weiß nicht, ob ich das jetzt richtig verstanden habe - aber heißt das dann, dass ein einfacher Text der nur aus ACII Zeichen besteht in UTF-32 mehr Speicherplatz benötigt (weil für jedes Zeichen 32 Bit benötigt) als in UTF-8 (wo für normale ASCII-Zeichen sicherlich nur 8 Bit oder so benötigt werden)?

Dass dem so ist, haben dir die beiden anderen ja gesagt. Deshalb wird UTF-8 auch hauptsächlich in der internen Verarbeitung verwendet. Ist halt wirklich schön einfach.

Bei UTF-16 muss man da sehr aufpassen, bei UTF-8 noch viel mehr.

Da sieht man mal wieder, was du mit der Programmierung dieses Forum geleistet hast, wovon man als normaler User gar nichts weiß ;-)

Ach Unfug *abwink* So schwer ist das nun auch wieder nicht.

再见,
 克里斯蒂安

[L00NIX]

Hallo L00NIX,

UTF-8 aber ist der absolute Overkill, auch in Bezug auf die 16-
Bit Codierung (also 9 Bit /Zeichen mehr als us-ascii!).

UTF-8 verwendet iirc 8 Bit/Zeichen, d.h. genauso viel
wie ISO 8859-1(5). Du meintest vermutlich UTF-16.

Ich verwende hier UTF-8 als locale und da hat es mit Sicherheit 16
Bit. Grundsätzlich ging es mir auch weniger um die
Bandbreitenverschwendung als vielmehr darum, E-Mail mit dem
kleinstmöglichen gemeinsamen Nenner (sprich: Zeichenkodierung) zu
verschicken um ein Maximum an Kompatibilität zu erreichen.

Ich erinnere mich auch, das irgendwo so mal gelesen zu haben (RFC?),
habe aber gerade keinen Link parat.

Gruß
L00NIX

[Christian Kruse]

你好 L00NIX,

Ich verwende hier UTF-8 als locale und da hat es mit Sicherheit 16 Bit.

Bitte. Lies, bevor du schreibst. Bei UTF-8 sind alle Code-Einheiten 8 Bit gross. Dabei können bis zu 6 (bzw. 4, je nach dem welchen Standard man liest) Code-Einheiten ein Zeichen beschreiben.

再见,
 克里斯蒂安

[L00NIX]

Hallo ...

Bitte. Lies, bevor du schreibst. Bei UTF-8 sind alle Code-
Einheiten 8 Bit gross. Dabei können bis zu 6 (bzw. 4, je nach dem
welchen Standard man liest) Code-Einheiten ein Zeichen
beschreiben.

Verstehe ich nicht so ganz, was mit Code-Einheit gemeint ist.

Jedenfalls ist ein Zeichen mit 16 Bit codiert, d.h. jeder Buchstabe
besteht aus 2 Byte, was sich bei Fehldarstellungen ja immer in diesen
doppelten Zeichen (z.B. Rechtecke) darstellt.

Was meinst du also genau mit "Code-Einheit"?

Gruß
L00NIX

[Christian Kruse]

你好 L00NIX,

Verstehe ich nicht so ganz, was mit Code-Einheit gemeint ist.

Zeichen werden in Codes kodiert; dabei kann ein Codes auf verschiedene Code-Einheiten aufgeteilt werden. Unicode kann vollständig in 32 Bit abgebildet werden, aber dann bräuchte man für jedes Zeichen direkt 32 Bit, auch wenn der Code für das Zeichen z. B. 32 ist. Blöd, da 32 problemlos auch in 8 Bit kodiert werden kann. Da kommen die Kodierungsformate ins Spiel, die Codes auf variable Längen aufteilen, dabei wird jeder Code-Teil in einer bestimmten Größe dargestellt; daraus ergeben sich die Code-Einheiten. Bei UTF-8 ist die Größe der Code-Einheiten 8 Bit, das heisst, es können alle Zeichen bis 2^7 in 8 Bit dargestellt werden. Alles was überhalb von 2^7, aber unterhalb von 2^11 liegt, kann in 16 Bit, also zwei Code-Einheiten kodiert werden. Von 2^11 bis 2^16 braucht man 24 Bit, also drei Code-Einheiten. Und für Zeichen von 2^11 bis 2^20 benötigt man 32 Bit, also 4 Code-Einheiten. In UTF-8 ist ein Zeichen als mit 1-4 Octetts (oder, wenn man der ISO-Norm folgt, 1-6 Octetts) kodiert.

Jedenfalls ist ein Zeichen mit 16 Bit codiert, d.h. jeder Buchstabe
besteht aus 2 Byte, was sich bei Fehldarstellungen ja immer in diesen
doppelten Zeichen (z.B. Rechtecke) darstellt.

Wenn du genauer aufgepasst hättest, wäre dir aufgefallen, dass diese "Fehldarstellungen" nur bei bestimmten Zeichen (bei dir vermutlich die deutschen Sonderzeichen ä, ö, ü, ß, etc, pp) auftritt. Du kannst ja mal den Sourcecode der Forums-Seiten anschauen; die sind in UTF-8 kodiert.

再见,
 克里斯蒂安

[L00NIX]

Hallo

...und danke für die ausführliche Erläuterung zu UTF-xy.

Wenn du genauer aufgepasst hättest, wäre dir aufgefallen, dass
diese "Fehldarstellungen" nur bei bestimmten Zeichen (bei dir
vermutlich die deutschen Sonderzeichen ä, ö, ü, ß, etc, pp)
auftritt. Du kannst ja mal den Sourcecode der Forums-Seiten
anschauen; die sind in UTF-8 kodiert.

Stimmt. :-)

Die Umlaute wurde (bis gerade) falsch dargestellt. Lag allerdings an
dem noch nicht umgestellten Text-Editor. Deine (chinesischen?)
Schriftzeichen sind jedenfalls hier kein Problem. :-)

Gruß
L00NIX