Zum abertausendsten mal: zeichenkodierung

[dedlfix]

Hi!

Allerdings verstehe ich nicht ganz, warum es einfacher sein
soll, dafür zu sorgen, dass überall ISO-8859-1 verienbart/
eingestellt ist. Dass es wahrscheinlich fehlerunanfälliger
ist, sehe ich ein, weil das wohl bei den meisten Einstellungen
der Default ist.

Die Empfehlung zu ISO-8859-1 traf ich, weil das bei dir der vermutlich aktuelle Stand ist und mit dem wenigsten Aufwand deine aktuellen Probleme zu beseitigen sind (unter der Voraussetzung, dass du keine Zeichen außerhalb von ISO-8859-1/Windows-1252 verwenden möchtest). Für neue Projekte empfehle ich UTF-8. Auch wenn man denkt, dessen Möglichkeiten derzeit noch nicht ausnutzen zu wollen, es schadet nicht/kaum, darauf vorbereitet zu sein.

Was ich für mich als sinnvoll erachten würde, wäre eine Art
Rangliste. Was überschreibt was bzw. wer ist stärker. Ein
Paar Dinge sind, glaube ich, mir klar:

• für jede Datei, die in irgendeiner Form zur Anzeige kommt
    und die Sonderzeichen enthält, muss beim Abspeichern die
    Zeichenkodierung festgelegt werden.

Ob eine Datei Sonderzeichen enthält, ist für das Prinzip unwichtig. Sie muss immer in einer bestimmten Kodierung gespeichert werden, und sei es ASCII.

• das wohl schwächste Gleid in der Kette habe ich festgelegt:
  <meta content="text/html; charset=iso-8859-1"

Ja, aber auch das hat seinen Verwendungszweck. Bei lokal gespeicherten Dateien steht zum Öffnen kein Webserver bereit, der eine Kodierungsangabe machen könnte, so dass der Browser diese Angabe nehmen kann. (Im Prinzip ist das ein Paradoxon, denn man muss erst einmal den Inhalt richtig interpretieren können, um diese Angabe korrekt lesen zu können. Hier geht man praktischerweise davon aus, dass es reicht, den Text als ASCII zu interpretieren. Alle Kodierungsnamen lassen sich bisher mit ASCII darstellen.)

• Der Server sendet im Header die Zeichenkodierung mit.

Aus Sicht des Browsers sind das die beiden interessanten Angaben, das Meta-Element und der (stärkere) HTTP-Header.

Dass der die Dateien vor dem Ausliefern auf ihren Zeichnsatz
  überprüft kann ich mir nicht vorstellen.

In seiner Grundstellung macht er das nicht, aber es gibt Module, die die Kodierung zumindest anhand eines Dateinamenszusatzes oder durch Suchen des Meta-Elements bestimmen können.

Ich interpretiere das, was ich darüber gefunden habe so:
  Mit den Direktiven AddCharset und AddDefaultCharset werden
  die Zeichenkodierungen festgelegt, mit denen die entsprechenden
  Dateiendungen ausgeliefert werden. Diese Information wird
  dem Browser im Header mitgesendet.

Überschreiben lässt sich dieser Wert durch CGI- oder als Modul eingebunden Programme.

Legt man die Direktiven nicht fest, bleibt dem Browser nur zu Raten.

Ja, und das ist immer Mist, wenn man ein definiertes Ergebnis bevorzugt.

Unter phpinfo() habe ich folgende Informationen bzgl. Zeichensatz gefunden:

PHP Core

default_charset no value

Dieser Wert überschreibt Apaches Add(Default)Charset-Konfiguration (natürlich nur wenn PHP im Spiel ist), und er wird von den Programmierern meist zugunsten eines header()-Aufrufs ignoriert.

(Ich sortiere die Zitate übrigens mal etwas um, weil manche Dinge anders zusammengehören als du sie aufzähltest.)

• Die vom Server gesendete Information lässt sich mit
    php:header() überschreiben.

Ja, im Allgemeinen. Wobei man auch den Apachen das letzte Wort haben lassen kann, wenn ich mich recht erinnere. Das hatten wir vor kurzem hier im Forum mal diskutiert, aber ich habe mir das Ergebnis nicht genau gemerkt, weil es aus meiner Sicht in der Praxis zu selten vorkommt, als dass es sich lohnt, die Details abrufbereit zu haben. Es ging wohl mit mod_headers.

HTTP Headers Information

HTTP Response Headers
Content-Type text/html; charset=ISO-8859-1

Ich weiß nicht genau, wo diese Angabe steht, vermutlich im Apache-Block. Ich hab grad keinen hier und kann dazu nichts konkretes sagen. So sähe jedenfalls eine HTTP-Header-Zeile aus wie sie der Browser bekommt (wenn man sich noch einen Doppelpunkt hinter Content-Type denkt).

Apache Environment

HTTP_ACCEPT_CHARSET ISO-8859-1,utf-8;q=0.7,*;q=0.7

HTTP Headers Information

HTTP Request Headers
Accept-Charset ISO-8859-1,utf-8;q=0.7,*;q=0.7

PHP Variables

_SERVER["HTTP_ACCEPT_CHARSET"] ISO-8859-1,utf-8;q=0.7,*;q=0.7

Alle drei Angaben sind das selbe, werden vom Browser gesendet und in der Regel von den Programmierern ignoriert. Die Browser kommen auch gut damit zurecht, wenn man sich nicht nach ihren Wünschen richtet, sondern stattdessen für die Response einfach eine Kodierung selbst festlegt.

• Für den Datenbankserver habe ich einen verwedendeten
    Zeichensatz unter phpmyadmin gefunden:

MySQL-Zeichensatz:  UTF-8 Unicode (utf8)

Was der PMA da auf seiner Startseite erzählt, hat keine Auswirkungen auf andere Anwendungen. Ich verweise da mal auf </archiv/2010/1/t194524/#m1301030> und hoffe, dass das erst einmal als Erklärung reicht. Wenn nicht, weißte ja, nachfragen hilft. :-)

• für die Kommunikation zwischen Web- und Datenbankserver
    wird auch irgendwo ein Zeichensatz festgelegt.
• Auch der lässt sich explizit durch "SET NAMES" überschreiben.

mysql(i)_set_charset() wäre die bevorzugte Variante, aber für ISO-8859-alle (und UTF-8) ergibt es zu einem SET-NAMES-Statement keinen Unterschied. (SET CHARACTER SET taucht gelegentlich als Gefährte von SET NAMES auf, aber das will man üblicherweise nicht haben, wenn man sich des Unterschieds nicht bewusst ist.)

Ich denke, für mein Verständis muss das Ziel nun erstmal sein,
überall dort explizit den zu verwendenden Zeichensatz festzulegen,
wo er festgelegt werden muss, mit keiner Einstellung eine andere
zu überschreiben und am Ende gezielt den Default festlegen/
überprüfen, um eine weitere Sicherheit einzubauen.

Die meisten Optionen gibt es bei der Konfiguration des Apachen und im Zusammenspiel mit PHP. Wenn man sich da auf PHPs header() (plus Meta-Element im HTML) beschränkt, ist man üblicherweise gut bedient und kommt unabhängig von Add(Default)Charset zum Ziel.

Lo!