Viersprachige Website // Unicode-Frage

[Karsten]

Hallo,

ich bin gerade dabei, eine viersprachige Unternehmenspräsentation fertig zu stellen. Deutsch und Englisch sind ja kein Problem - aber bei chinesisch und japanisch würde ich mich gern nochmal etwas informieren:

Die asiatischen Schriftzeichen werden direkt vor Ort eingepflegt. Ich hätte gedacht, dass ich aus diesem Grunde den Dateien mal den UTF-8 Zeichensatz zuweise:

<meta http-equiv='Content-Type' content='text/html; charset=utf-8' />

Aber sobald ich die Zeile drinnen hab, werden die chinesischen Schriftzeichen im Firefox und im IE falsch dargestellt. Lasse ich die Zeile draußen, dann sieht es im Firefox gut aus, im IE aber auch nicht.

Was läuft da falsch?

Die Seite um die es geht ist übrigens www.guidetrend.de - ich würde ich wirklich über jeden Tipp freuen!

Viele Grüße,
Karsten

[dedlfix]

echo $begrüßung;

<meta http-equiv='Content-Type' content='text/html; charset=utf-8' />

Aber sobald ich die Zeile drinnen hab, werden die chinesischen Schriftzeichen im Firefox und im IE falsch dargestellt. Lasse ich die Zeile draußen, dann sieht es im Firefox gut aus, im IE aber auch nicht.

Was läuft da falsch?

Die Zeile sagt aus in welchem Format die Daten des Dokuments vorliegen[*]. Du solltest dich dann natürlich daran halten und die Daten auch wirklich so kodieren.

echo "$verabschiedung $name";

[*] http-equiv steht für HTTP-Äquivalent. Die Meta-Angabe kommt nur zum Zuge, wenn keine HTTP-Header-Angaben zur Kodierung vorliegen.

[Karsten]

Die Zeile sagt aus in welchem Format die Daten des Dokuments vorliegen[*]. Du solltest dich dann natürlich daran halten und die Daten auch wirklich so kodieren.

Jetzt müsstest Du mir noch ein wenig auf die Sprünge helfen... wie könnte das denn z.B. im Falle einer chinesischen Seite aussehen. Momentan werden die Content-Seiten der Einfachheit halber ja einfach per include in das Rahmentemplate geschickt und je nach Sprache verschiedene charset-Angaben an den Browser geschickt:

Englisch: content='text/html; iso-8859-1, windows-1252'
Deutsch: content='text/html; iso-8859-1, windows-1252'
Chinesisch: content='text/html; GB2312'
Japanisch: content='text/html; shift_jis, iso-2022-jp, euc-jp'/>

Die deutschen Inhalte sind mit den entsprechenden entities für Umlaute etc. versehen. Wie muß ich mir da die Vorgehensweise bei chinesische oder japanischen Schriftzeichen vorstellen? Die Content-Seiten (eigentlich Text-Dokumente mit simplen HTML-Anweisungen zur Formatierung) werden ja direkt in Asien erstellt . Muß dabei irgendetwas anders gemacht werden, oder bei der grundsätzlichen Programmierung?

Vielen Dank für Deine Hilfe übrigens!

» [*] http-equiv steht für HTTP-Äquivalent. Die Meta-Angabe kommt nur zum Zuge, wenn keine HTTP-Header-Angaben zur Kodierung vorliegen.

Hmm.. woher kommen denn normalerweise die HTTP-Header? Werden die in irgendeiner Form von den HTML-Dokumenten beeinflußt oder liefert die einfach nur der Webserver gemäß welchen Einstellungen auch immer aus?

[dedlfix]

echo $begrüßung;

Jetzt müsstest Du mir noch ein wenig auf die Sprünge helfen... wie könnte das denn z.B. im Falle einer chinesischen Seite aussehen. ...

Die deutschen Inhalte sind mit den entsprechenden entities für Umlaute etc. versehen.

Wenn du die &Entities; verwendest brauchst du die Charset-Angabe nicht. Die wird nur benötigt, wenn die Zeichen "als Bytes" kodiert sind. Also wenn der Browser auf das Byte E4 trifft und daraus ein ä machen soll, dann muss er gesagt bekommen, dass das iso-8859-1 ist. Und wenn er bei C3 A4 ein ä darstellen soll, muss er wissen, dass das utf-8 ist.

Wie muß ich mir da die Vorgehensweise bei chinesische oder japanischen Schriftzeichen vorstellen?

Entweder du nimmst für Zeichen, die mit der aktuellen Kodierung nicht dargestellt werden können die &Entitiyschreibweise; - auch in den Formen &#x20AC; oder &#8364; denn nicht für jedes Zeichen gibt es eine Schreibweise mit einem Namen (&euro;)

Oder du schreibst die Zeichen in den Texten "normal" und speicherst mit einem entsprechend fähigen Editor in der am besten geeigneten Kodierung ab, z.B. UTF-8.

Diese Kodierung muss nun der Server dem Client (Browser) mitteilen. Dafür gibt es entsprechende Angaben in den Header-Zeilen im HTTP-Protokoll.

HTTP-Header werden vor jedem Dokument mitgesendet. Darin stehen z.B. Angaben zur Länge, zum Content-Type und auch zum Charset. Beim Apachen wird diese Angabe mit der Konfigurationsdirektive AddDefaultCharset eingestellt. Wenn keine Angabe zum Charset im Header mitgesendet wurde, dann darf der Browser die Angabe im Meta-Tag auswerten.

echo "$verabschiedung $name";

[Gunnar Bittersmann]

Hi dedlfix,

&Entitiyschreibweise; - auch in den Formen &#x20AC; oder &#8364;

Das sind keine Entities, sondern numerische Zeichenreferenzen.

Gruß,
Gunnar

[Gunnar Bittersmann]

Hi Karsten,

je nach Sprache verschiedene charset-Angaben an den Browser geschickt:

Nein. Die charset-Angeben sind in nicht von der Sprache abhängig, sondern von der tatsächlich verwendeten Zeichencodierung.

Englisch: content='text/html; iso-8859-1, windows-1252'

Da fehlt was und da ist was zu viel: content="text/html; charset=ISO-8859-1". Und es sollte mich sehr wundern, wäre an dieser Stelle die Angabe zweier Codierungen erlaubt.

Die deutschen Inhalte sind mit den entsprechenden entities für Umlaute etc. versehen.

Was bei der Codierung in ISO 8859-1 überhaupt nicht notwendig ist. In UTF-8 natürlich auch nicht.

Wie muß ich mir da die Vorgehensweise bei chinesische oder japanischen Schriftzeichen vorstellen?

Möglich wäre auch bei diesen die Codierung in ISO 8859-1 und numerische Referenzierung: グンナー. Praktikabel ist das nur für vereinzelte Wörter, sicher nicht für ganze chinesische oder japanische Texte.

Du solltest dich besser für eine Codierung entscheiden, mit der du alle im Dokument vorkommenden Zeichen codieren kannst. UTF-8 deckt alle Zeichen des Universal Character Sets (UCS) / Unicode ab, kannst du also für deutsche wie englische wie chinesische wie japanische Dokumente einsetzen.

Gruß,
Gunnar

[Gunnar Bittersmann]

Nachtrag: Schau doch mal ins Kapitel 5 Repräsentation von HTML-Dokumenten der HTML 4.01-Spezifikation.

Gruß,
Gunnar

[Karsten]

Hi dedlfix, hi Gunnar,

vielen Dank für Eure Hinweise... so langsam lichtet sich das. Jetzt hab ich zumindest schonmal kapiert, dass ich vor allem erstmal einen Editor brauche, der UTF-8 kodierte Dokumente speichern kann. Ich verwende hier im Moment als Text- oder Code-Editor hauptsächlich Weaverslave und der kann das wohl nicht.

Dazu hab ich mir jetzt mal "SuperEdi" (http://www.wolosoft.com) besorgt. Der kann UTF schreiben.

Wie wäre denn dan aber hier der Workflow?

• Ich habe mein "Haupt"-PHP-File. Das speicher ich einfach auch nochmal  mit dem neuen Editor im UTF-8 Format ab und schreibe hier als Meta Tag "<meta http-equiv='Content-Type' content='text/html; charset=utf-8'/>" hinein.

• Aber wie behandle ich jetzt die content-files? Wenn ich mir www.guidetrend.de/content/cn_products.php allein ansehe, sieht das in beiden "großen" Browsern gut aus. Gehe ich aber über das Menü von www.guidetrend.de zu diesem Punkt, dann scheint das mit der Codierung nicht ganz hinzuhauen. Wo liegt denn da mein Denkfehler?

Lieben Dank und viele Grüße,
Karsten

[Karsten]

Nachtrag:

Seltsam - wenn ich eines der original-Dokumente hernehme...

www.guidetrend.de/content/cn_products.php

...dann siehts für sich genommen (ohne "Rahmenlayout") gut aus. Öffne ich die Datei allerdings in dem vorher genannten "SuperEdi" und speichere sie da einfach nur wieder ab mit der Kodierungs-Option "UTF-8", dann siehts so aus...

www.guidetrend.de/content/cn_products_utf.php

...und wenn ich die beiden in mein Rahmendokument include, dann siehts beides mal nicht gut aus.

Wenn ich das Original-Dokument cn_products.php in IE öffne und per Kontextmenü zu den Kodierungseinstellungen gehe, sehe ich, dass das wohl in "Chinesisch vereinfacht (GB2312)" kodiert ist. Aber sollte dann Unicode nicht auch gehen?

Versteh ich nich...

[Sven Rautenberg]

Moin!

www.guidetrend.de/content/cn_products.php

Dieses Dokument enthält GBK(GB2312)-codierte chinesische Zeichen.

...dann siehts für sich genommen (ohne "Rahmenlayout") gut aus.

Logisch, weil der Browser sich automatisch auf GBK-codierung einstellen kann. Es gibt ja auch keine anderen Zeichen, die "verhunzt" werden könnten.

Öffne ich die Datei allerdings in dem vorher genannten "SuperEdi" und speichere sie da einfach nur wieder ab mit der Kodierungs-Option "UTF-8", dann siehts so aus...

www.guidetrend.de/content/cn_products_utf.php

Klassischer Fall von "Codierung zerstört". Dein Editor muß beim Öffnen das Dokument als GBK-codiert behandeln, dann beim Anzeigen die richtigen chineischen Zeichen anzeigen, und beim Speichern die Konvertierung in UTF-8 durchführen.

Wenn ich das Original-Dokument cn_products.php in IE öffne und per Kontextmenü zu den Kodierungseinstellungen gehe, sehe ich, dass das wohl in "Chinesisch vereinfacht (GB2312)" kodiert ist. Aber sollte dann Unicode nicht auch gehen?

Unicode ist einfach eine andere Art, dem Computer zu sagen, welches Schriftzeichen er anzeigen soll. Einfach nur die Zeichensatzangabe zu verändern ist nicht genug, es muß tatsächlich umcodiert bzw. konvertiert werden.

• Sven Rautenberg

[Gunnar Bittersmann]

Hi,

sehe ich, dass das wohl in "Chinesisch vereinfacht (GB2312)" kodiert ist. Aber sollte dann Unicode nicht auch gehen?

Unicode ist keine Zeichencodierung. Da verstehe ich auch nicht, was Sven mit

Unicode ist einfach eine andere Art, dem Computer zu sagen, welches Schriftzeichen er anzeigen soll.

meint. Vielleicht „UTF-8 ist einfach …“?

Gruß,
Gunnar

[Karsten]

Hallo Sven,

...dann siehts für sich genommen (ohne "Rahmenlayout") gut aus.
Logisch, weil der Browser sich automatisch auf GBK-codierung einstellen kann. Es gibt ja auch keine anderen Zeichen, die "verhunzt" werden könnten.

Öffne ich die Datei allerdings in dem vorher genannten ...
Klassischer Fall von "Codierung zerstört". Dein Editor muß beim Öffnen das Dokument als GBK-codiert behandeln, dann beim Anzeigen die richtigen chineischen Zeichen anzeigen, und beim Speichern die Konvertierung in UTF-8 durchführen.

Hmm.... ok. Dann hab ich also einfach den falschen Editor? Kennst Du einen anderen - da das Problem wahrscheinlich nicht mehr so oft auftreten wird - möglichst kostenlosen Editor / Konverter, der mit Japanischen und Chinesischen Dokumenten zurecht kommt? Oder kann ich den content-Lieferanten vielleicht sagen, auf was sie bei der Erstellung der Inhalts-Dateien achten müssen?

[Ashura]

Hallo Karsten.

Hmm.... ok. Dann hab ich also einfach den falschen Editor?

Scheint so, ja.

Kennst Du einen anderen - da das Problem wahrscheinlich nicht mehr so oft auftreten wird - möglichst kostenlosen Editor / Konverter, der mit Japanischen und Chinesischen Dokumenten zurecht kommt?

Immer wieder gerne -> Notepad2.

Gruß, Ashura

[Karsten]

Hi Ashura,

vielen Dank für den Tipp! Leider hat mich das auch noch nicht so richtig weitergebracht. Wenn ich das Problem jetzt richtig identifiziert habe, dann stellt sich das ja folgendermaßen dar:

• Ich bekomme "chinesisch vereinfachte" (GB2312) kodierte Content-Files direkt aus Asien (später auch noch japanische). Wenn ich diese mit Hilfe meiner UDF-8 kodierten (und mit "<meta http-equiv="content-type" content="text/html; charset=UTF-8">" versehenen index.php include, stellt der Browser nicht die gewünschten Schriftzeichen dar.

Also: aus http://www.guidetrend.de/content/cn_products.php mach http://www.guidetrend.de/layout/index.php?content=products&lang=cn

• Wenn ich diese chinesisch kodierten Dateien nun in notepad2 öffne, dann sehe ich ebenfalls nur so etwas: <h1>ÀË´ï-ËܽºÈȳÀ</h1>. Speichere ich diese Datei jetzt UTF-formatiert, erhalte ich leider auch keine korrekte Darstellung. Er scheint mir also die Kodierung auch hier wieder zu zerschiessen. Wenn ich mir innerhalb von notepad2 die Kodierung der frisch geöffneten Datei ansehe, dann steht da übrigens ANSI. GB2312 o.ä. bietet er mir gar nicht an?

Vielleicht hast Du noch einen Tipp für mich, oder einen Hinweis, wie denn der Arbeitsablauf grundsätzlich besser wäre?

[Ashura]

Hallo Karsten.

• Ich bekomme "chinesisch vereinfachte" (GB2312) kodierte Content-Files direkt aus Asien (später auch noch japanische). Wenn ich diese mit Hilfe meiner UDF-8 kodierten (und mit "<meta http-equiv="content-type" content="text/html; charset=UTF-8">" versehenen index.php include, stellt der Browser nicht die gewünschten Schriftzeichen dar.

Schon einmal einen anderen header gesendet?
Beispiel aus meinen üblichen .php-Dateien:

header('Content-type: text/html; charset=utf-8');

Der Stellenwert dieser Angabe ist höher, als xml-Prolog und Metaangabe.

• Wenn ich diese chinesisch kodierten Dateien nun in notepad2 öffne, dann sehe ich ebenfalls nur so etwas: <h1>ÀË´ï-ËܽºÈȳÀ</h1>.

Was steht unter [Datei] -> [Konvertiere (Zeichensatz)]?
Wenn dort ANSI gewählt ist, wurde die Datei falsch gespeichert. (Am Besten stellst du unter [Standard...] gleich UTF-8 ein. Das Häkchen darunter nicht setzen.)

Speichere ich diese Datei jetzt UTF-formatiert, erhalte ich leider auch keine korrekte Darstellung.

Wie sieht diese „nicht korrekte Darstellung“ aus?
Öffne ich eine ANSI-kodierte Datei mit dem Inhalt „ä“ und konvertiere sie zu UTF-8, erhalte ich ein schönes „ä“.

Ich habe eben aber einmal mit dem Zeichen „き“ experimentiert. Und tatsächlich ist Notepad2 nicht in der Lage, es intern korrekt anzuzeigen.
Konvertiert man die Datei aber zu „Unicode“ anstatt „UTF-8“, wird das Zeichen zumindest im Browser korrekt ausgegeben. In Notepad2 gibt es leider nur ein plumpes „“... :-(

Er scheint mir also die Kodierung auch hier wieder zu zerschiessen.

Muss nicht sein, siehe mein Experiment von eben.

Wenn ich mir innerhalb von notepad2 die Kodierung der frisch geöffneten Datei ansehe, dann steht da übrigens ANSI. GB2312 o.ä. bietet er mir gar nicht an?

Dann wandele einmal in „Unicode“ um und lasse es im Browser ausgeben.

Vielleicht hast Du noch einen Tipp für mich, oder einen Hinweis, wie denn der Arbeitsablauf grundsätzlich besser wäre?

Frag CK, der kennt sich mit solchen Zeichen aus. :-)

Gruß, Ashura