Andreas Korthaus: Was erwartet mich bei asiatischen Besuchern?

Hallo!

Ich habe ein Web-Projekt erstellt(auf Basis von PHP), welches in den nächsten Wochen seinen Live-Betrieb aufnehmen wird, wobei es hier zu einem großen Anteil von asiatischen Benutzern genutzt werden wird. Ich hatte noch niemals nie mit anderen Zeichensätzen als dem guten alten "iso-8859-1" zu tun. Vor allem aber habe ich noch nie einen asiatischen Browser gesehen. Die Seiten werden nur in deutsch/englisch angeboten, das heißt, ich habe zumindest auf meiner Seite keine Probleme zu befürchten. Zum einen habe ich keine Ahnung welche Browser in diesen Regionen (vor allem Taiwan, China, Süd-Korea...) weit verbreitet sind, ich hoffe das doch zumindest IE 5 Standard ist (es geht ausschließlich um mittlere bis große Firmen), oder? Hat da von Euch jemand Erfahrungswerte?

Da die meiste Software, die meisten Protokolle und die meisten Quellen aus dem amerikanischen bzw. europäischen Raum kommen, gehe ich davon aus, dass die asiatischen Browser in der Lage sind, standardmäßig englische Seiten mit iso-8859-1 korrekt darzustellen. Oder ist das nicht so? Die Benutzer rufen im Prinzip nur Seiten in englischer Sprache auf, eben mit iso-8859-1, und haben nur sehr wenige Formular-Felder, in die Zahlen eingegeben werden können, keine Buchstaben (Buchstaben nur an "unwichtigen" Stellen, sowas wie "persönliche Einstellungen", wo Name etc. verändert Werden kann).

Kann ich darauf vertrauen dass das bei asiatischen Benutzern genau so gut klappt wie bei "westlichen" Besuchern? Gibt es irgendwelche Fallstricke worauf man achten sollte?

Noch eine andere Frage, bei den durch PHP generierten Seiten wird kein Header bzgl. des charset gesendet. Dafür habe ich folgendes im <head> stehen:

<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">

Aber prinzipiell finde ich diese Vorgehensweise eigentlich nicht korrekt, denn um an den charset zu kommen, muss man das Dokument bereits parsen, ohne den charset zu kennen. Macht es nicht mehr Sinn den charset im HTTP-Header zu übertragen?

Bin dankbar für jeden Tipp/Link zum Thema.

Viele Grüße
Andreas

--
SELFHTML Feature Artikel: http://aktuell.de.selfhtml.org/artikel/
  1. Die Seiten werden nur in deutsch/englisch angeboten, das heißt, ich habe zumindest auf meiner Seite keine Probleme zu befürchten.

    Zum einen habe ich keine Ahnung welche Browser in diesen Regionen (vor allem Taiwan, China, Süd-Korea...) weit verbreitet sind, ich hoffe das doch zumindest IE 5 Standard ist (es geht ausschließlich um mittlere bis große Firmen), oder?

    Bitte, Asien ist weit weg, aber liegt nicht auf dem Mars.

    Da die meiste Software, die meisten Protokolle und die meisten Quellen aus dem amerikanischen bzw. europäischen Raum kommen, gehe ich davon aus, dass die asiatischen Browser in der Lage sind, standardmäßig englische Seiten mit iso-8859-1 korrekt darzustellen.

    Siehe unten.

    nur sehr wenige Formular-Felder, in die Zahlen eingegeben werden können, keine Buchstaben (Buchstaben nur an "unwichtigen" Stellen, sowas wie "persönliche Einstellungen", wo Name etc. verändert Werden kann).

    Bei Formularen solltest Du darauf achten, dass accept-charset nur einen Wert enthält (am besten utf-8), weil zumindest die Gecko-Browser nicht in der Lage sind, aus einer Reihe von Zeichensätzen den passendsten auszuwählen. Man würde dann zum Beispiel bei "iso-8859-1,utf-8" den Text als iso-8859-1 erhalten, wobei alle Nicht-iso-8859-1-Zeichen als &#xxxx;-HTML-Masken erscheinen (die naturgemäß nicht vom eingebenen &#xxxx;-Texten zu unterscheiden sind).
    Diese unglückselige Eigenschaft kann (oder konnte) man bisweilen auch hier im Forum beobachten (Eurozeichen, &#8364;, €).

    <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">

    Aber prinzipiell finde ich diese Vorgehensweise eigentlich nicht korrekt, denn um an den charset zu kommen, muss man das Dokument bereits parsen, ohne den charset zu kennen.

    1. Fast alle Zeichensätze weltweit basieren auf US-ASCII und da Dein <meta...>-Text nichts anderes enthält als US-ASCII-Zeichen, gibt es mit fast allen Zeichensätzen auch keine Probleme.
    2. Als Problem wäre denkbar, dass der Browser einen Zeichensatz erwartet, der nicht in 8 Bit verpackt ist, oder einen, der nicht auf US-ASCII basiert (gemäß Fall 1). Da Du aber bis hierhin nichts angegeben hast, gilt Fall 3:
    3. Falls nichts anderes angegeben, ist iso-8859-1 Basis für HTML-Seiten. Du hast den Text bis hierhin in iso-8859-1 geschrieben, also sollte es für den Browser auch kein Problem sein, den Text bis hierhin wieder auszulesen.

    Achte aber darauf, dass der Server nicht schon einen Zeichensatz per HTTP mitschickt. Dieses Verhalten lässt sich als Vorgabe einstellen und überschreibt die meta-Angabe. Näheres dazu in der Anleitung Deines Webservers.

    Macht es nicht mehr Sinn den charset im HTTP-Header zu übertragen?

    Eigentlich ja.

    1. Hallo!

      [...] ich hoffe das doch zumindest IE 5 Standard ist [...]
      Bitte, Asien ist weit weg, aber liegt nicht auf dem Mars.

      Wenn Du das sagst, hätte ja sein können dass dort Netscape 4 oder IE 4 oder noch was ganz anderes sehr verbreitet ist. Das ist für einige Dinge wichtig, z.B. für das verwendete SSL-Zertifikat.

      nur sehr wenige Formular-Felder, in die Zahlen eingegeben werden können, keine Buchstaben (Buchstaben nur an "unwichtigen" Stellen, sowas wie "persönliche Einstellungen", wo Name etc. verändert Werden kann).

      Bei Formularen solltest Du darauf achten, dass accept-charset nur einen Wert enthält (am besten utf-8), weil zumindest die Gecko-Browser nicht in der Lage sind, aus einer Reihe von Zeichensätzen den passendsten auszuwählen. Man würde dann zum Beispiel bei "iso-8859-1,utf-8" den Text als iso-8859-1 erhalten, wobei alle Nicht-iso-8859-1-Zeichen als &#xxxx;-HTML-Masken erscheinen (die naturgemäß nicht vom eingebenen &#xxxx;-Texten zu unterscheiden sind).
      Diese unglückselige Eigenschaft kann (oder konnte) man bisweilen auch hier im Forum beobachten (Eurozeichen, &#8364;, ).

      Aber warum UTF-8?UTFe Formulardaten werden in einer DB gespeichert, und zwar als iso-88iso1. Daher solte sollteas wohl auch für die Formulare verwenden. AußedAußerdemn die Formulardaten - sowohl zur Kontrolle aus der Session, als auch später aus der DB, direkt im Browser angezeigt, der ja wieder iso-88iso1 erwartet. Das man keine asiatischen Sonderzeichen auf diese Weise verwenden kann ist mir bewußbewusst wenn ich das wollte, würde das sehr große Änderungen erfordern. Die i18n Unterstützung von PHP isPHPicht wirklich gut. Soll sich aber in Version 5.2 wohl verbessern, nur das bringt mir heute nichts. Auch ist das ein Problem mit den verschiedenen Datenbanken. Für den ersten Schritt interessiert mich, ob asiatische Besucher (die alle des englischen mächtig sind) grundsätzlich Probleme mit der Ausgabe, oder Eingabe von Zahlen und westlichen Zeichen bekommen können. Das sieht ja nicht so aus. Der nächste Schritt wäre dann, die Software in mehrere asiatische Sprachen zu übersetzen, wobei es hier erstmal nur um die Darstellung (feststehende Texte, Feldbezeichnungen...) geht, nicht um die Daten. Hierzu müsste ich dann den charsecharsetrn, das Problem wird hier wohl erstmal das ParsenParsenbeiten der Sprachdateien sein. Im 3. Schritt muss man dann auch mal mit asiatischen Daten umgehen können, was dann entsprechende Änderungen in der Datenbank, Formularen... mit sich bringt.

      Im Augenblick reicht es aber wie gesagt, wenn asiatische Besucher westliche Zeichen, und vor allem Zahlen eingeben, und angezeigt bekommen können.

      Grüße
      Andreas

      --
      SELFHTML Feature Artikel: http://aktuell.de.selfhtml.org/artikel/