Xampp auf Zeichensatz UTF-8 umstellen

[nzc]

Hallo,

ich habe mir gerade die aktuelle XAMPP-Version auf meinem Rechner installiert (Vista Home). Später wird noch Drupal7 hinzukommen, so daß ich eine Website auf Drupal-Basis lokal entwickeln kann.

Jetzt habe ich mir gedacht, dass ich mir in Bezug auf das Thema Zeichensätze gleich zu Beginn eine vernünftige Basis schaffe und alle XAMPP-Komponenten auf UTF8 umstelle mit dem Ziel, nie NIE in irgendwelche Zeichensatzprobleme, kryptische Anzeige von Umlauten o.ä. zu laufen. Ich hab jetzt soweit recherchiert, dass ich die Umstellung konfigmäßig hinbekommen würde.

Je mehr ich allerdings recherchiere, umso mehr Zweifel kommen mir, ob diese Umstellung in der Praxis überhaupt Sinn macht. Was ist z.B. mit Kompatibiltät? Ich denke da an Drupal-Module, in dessen Code z.B. nicht die Multibyte-String-Operationen verwendet werden, sondern die normalen. Da ich kein PHP-Programmierer bin, bin ich auf diese Form des Fremdcodes angewiesen und nicht jeder Coder auf der großen weiten Welt ist voller Elan um Unicode-Unterstützung bemüht.

Ich habe mir außerdem einmal die Konfiguration von XAMPP angesehen (httpd.conf, php.ini, MySQL usw.) und nicht eine einzige Komponente ist in Richtung UTF8 konfiguriert. Ich nehme an, das das XAMPP-Team da auch gute Gründe für hatte.

Meine Fragen:
1. Macht meine geplante Umstellung auf UTF8 Sinn?
2. Gibt es Besonderheiten speziell bei XAMPP, die ich bei der Umstellung berücksichtigen muss?
3. Aus welchen Gründen ist XAMPP zeichensatztechnisch so konfiguriert worden wie es ist?

[Altrea]

Hallo nzc,

Jetzt habe ich mir gedacht, dass ich mir in Bezug auf das Thema Zeichensätze gleich zu Beginn eine vernünftige Basis schaffe und alle XAMPP-Komponenten auf UTF8 umstelle mit dem Ziel, nie NIE in irgendwelche Zeichensatzprobleme, kryptische Anzeige von Umlauten o.ä. zu laufen.

Vernünftig.

Ich hab jetzt soweit recherchiert, dass ich die Umstellung konfigmäßig hinbekommen würde.

Im Grunde ist dafür kaum etwas zu tun.

Was ist z.B. mit Kompatibiltät? Ich denke da an Drupal-Module, in dessen Code z.B. nicht die Multibyte-String-Operationen verwendet werden, sondern die normalen.
Da ich kein PHP-Programmierer bin, bin ich auf diese Form des Fremdcodes angewiesen und nicht jeder Coder auf der großen weiten Welt ist voller Elan um Unicode-Unterstützung bemüht.

Kompatibilität ist immer ein Grund bei Fremdcode. Prinzipiell kann man aber sagen, dass ernst zu nehmende Module eines weltweit beliebten Content-Management-Systems es sich garnicht leisten können ihr Modul gegen einen festen lokalen Zeichensatz zu programmieren. Die Module die man nicht ernst nehmen kann würde ich als Entwickler garnicht erst produktiv einsetzen, da neben dem fehlenden Zeichensatzsupport dann meist auch das Bugfixing nicht ganz so ernst genommen wird. So trennt sich dann in der Regel schon die Spreu vom Weizen, natürliche Auslese eben
Das bedeutet nicht, dass alle Module die nicht die Multibyte-Repräsentationen der PHP Funktionen verwenden fehlerhaft mit UTF-8 umgehen würden. In vielen Fällen macht es schlichtweg keinen Unterschied.

Ich habe mir außerdem einmal die Konfiguration von XAMPP angesehen (httpd.conf, php.ini, MySQL usw.) und nicht eine einzige Komponente ist in Richtung UTF8 konfiguriert. Ich nehme an, das das XAMPP-Team da auch gute Gründe für hatte.

Welche Komponente meinst du denn in Richtung UTF-8 konfigurieren zu müssen? Prinzipiell kann sowohl Apache als auch PHP als auch MySQL in der Grundkonfiguration mit UTF-8 umgehen (nicht vollständig natürlich, PHP wird erst mit PHP 6 voll unicode fähig). Das einzige was nicht getan wurde (und das aus Gründen der Kompatibilität) ist Standard-Zeichensätze zu setzen (außer MySQL, welches standardmäßig latin1 verwendet).

1. Macht meine geplante Umstellung auf UTF8 Sinn?

Ich nutze nurnoch UTF-8, von daher würde ich erstmal mit "ja" antworten. In einigen Fällen ist UTF-8 nicht nötig, aber es macht kaum einen Mehraufwand sich auf UTF-8 statt auf ISO-8859-1 zu stürzen, kann aber im Nachhinein viel Portierungsaufwand sparen, wenn man zum Beispiel feststellt, dass die beliebte Kommentarfunktion dann doch für andersartige Schriftzeichen kompatibel gemacht werden soll.

2. Gibt es Besonderheiten speziell bei XAMPP, die ich bei der Umstellung berücksichtigen muss?

Speziell auf XAMPP bezogen, nein. Du musst den Zeichensatz nur konsequent durchziehen. Das fängt bei der Zeichenkodierung in der deine PHP-Dateien gespeichert werden an, geht über korrekte Meta-Angaben des HTML outputs, richtiges Aushandeln des Zeichensatzes in der Datenbankkommunikation bis hin zum Zeichensatz der Persistenzschicht selbst. In allen Mitteln der Benutzerinteraktivität (Formulare etc) muss man ebenfalls darauf achten.

3. Aus welchen Gründen ist XAMPP zeichensatztechnisch so konfiguriert worden wie es ist?

XAMPP setzt keine Standardzeichensätze um eben nicht den Entwickler zu einem speziellen Zeichensatz zu drängen.
Aber wenn du dich auf den Zeichensatz der orangenen XAMPP Administration Page beziehst ist es vermutlich historisch so gewachsen (genauso wie die XAP noch auf short_open_tag = On angewiesen ist). Du bist aber frei in deiner Wahl.

Ich nutze UTF-8 mit XAMPP seit PHP 5, also schon ein wenig länger.

mit freundlichen Grüßen,
Altrea

[nzc]

Vielen Dank für deine ausführliche Antwort.

Im Grunde ist dafür kaum etwas zu tun.

Am Ende dieses Posting habe ich in einer Code-Box mal zusammengestellt, was das Internet glaubt, was zu tun sei, sprich was ich so an Konfigänderungen recherchiert habe. Das kannst du dir ja mal anschauen und schreiben, was du davon umsetzten würdest, bzw. was Sinn macht und was nicht. Ich befürchte nämlich, dass ich viel zu viel ändern will.

Welche Komponente meinst du denn in Richtung UTF-8 konfigurieren zu müssen? Prinzipiell kann sowohl Apache als auch PHP als auch MySQL in der Grundkonfiguration mit UTF-8 umgehen (nicht vollständig natürlich, PHP wird erst mit PHP 6 voll unicode fähig). Das einzige was nicht getan wurde (und das aus Gründen der Kompatibilität) ist Standard-Zeichensätze zu setzen (außer MySQL, welches standardmäßig latin1 verwendet).

Und genau darauf laufen die meisten Konfigänderungsvorschläge (siehe Codebox) im Internet hinaus: Überall UTF8 als Default setzen. Muss man das gar nicht bzw. ist das sogar schädlich in Bezug auf Kompatibilität?
Auf jeden Fall sinnvoll finde ich die Konfigänderungen bei MySQL. Da ist mir das voreingestellte latin1 mit schwedischer Kollation doch ein Dorn im Auge. Interessant und hilfreich für den PHP-Coder finde ich die init_connect Anweisung. Dann muss man nicht für jede UTF8-Verbindung aus dem PHP heraus immer das entsprechende SENT NAMES absetzten. Mit dem skip-character-set-client-handshake wäre ich dagegen wohl eher vorsichtig in Bezug auf Kompatibilität.

bis hin zum Zeichensatz der Persistenzschicht selbst.

Das Wort "Persistenzschicht" musst ich - hüstel - erst mal googlen Du meinst den Zeichensatz des Dateisystems, richtig? Da bin ich mir bei Windows gar nicht sicher. Ich weiß das ein aktuelles Windows intern mit UTF16 arbeitet, auf der anderen Seite macht es auch viel mit seinen Codepages rum. Da ist ein Linux auf UTF8-Basis schon durchsichtiger. Eignet sich Windows eigentlich als vernünftiger "UTF8-Server"?

Umstellung auf UTF8

Code: Select all

--------------------------------------------------------------------------------
APACHE
Änderungen in: \xampp\apache\conf\httpd.conf (oder in htaccess)
--------------------------------------------------------------------------------
    // UTF-8 als Standardzeichensatz für alles ...
    AddDefaultCharset UTF-8
     
    // ... oder nur speziell für php, html, xml, javascript etc..
    AddCharset UTF-8 .php
    AddCharset UTF-8 .html
    AddCharset UTF-8 .xml
    AddCharset UTF-8 .js

--------------------------------------------------------------------------------
PHP
Änderungen in: xampp\php\php.ini
--------------------------------------------------------------------------------
    [PHP]
    default_charset = "utf-8"

    [mbstring]
    mbstring.language = utf-8
    mbstring.internal_encoding = utf-8
    mbstring.http_input = utf-8
    mbstring.http_output = utf-8
   
--------------------------------------------------------------------------------
MYSQL
Änderungen in: \xampp\mysql\bin\my.ini
--------------------------------------------------------------------------------
    [client]
    default-character-set = utf8

    [mysqld]
    default-character-set = utf8
    character-set-server = utf8
    collation-server = utf8_general_ci
    init_connect = 'ET collation_connection = utf8_general_ci'
    init_connect = 'SET NAMES utf8'

    //Sicherstellen, dass MySQL alle Daten IMMER als UTF8 empfängt und speichert (egal was der Client fordert)
    skip-character-set-client-handshake

    [mysqldump]
    default-character-set = utf8

    [mysqlimport]
    default-character-set = utf8

    [mysql]
    default-character-set = utf8
   

Wichtig ist natürlich, dass man alle Dateien UTF-8 kodiert und auch die Datenbanken alle auf UTF-8 laufen.


[Altrea]

Und genau darauf laufen die meisten Konfigänderungsvorschläge (siehe Codebox) im Internet hinaus: Überall UTF8 als Default setzen. Muss man das gar nicht bzw. ist das sogar schädlich in Bezug auf Kompatibilität?

Prinzipiell muss man das nicht, wenn man überall konsequent den richtigen Zeichensatz verwendet und angibt - wie im vorigen post schon kurz angerissen (was man allein der Sauberkeit zu Liebe tun sollte). Default Zeichensätze könnten vielleicht das eine oder andere vergessene meta Tag ersetzen, doch du machst dein Script mit diesen Einstellungen abhängig von einer ganz speziellen Konfiguration (was aus Kompatibilitätsansicht eher negativ ist, da die Portabilität darunter leidet). Ich bin da bisher besser mit der Devise gefahren "lieber ein zwei fehlinterpretierte Zeichensätze mehr, die man auf der Entwicklungsumgebung beheben kann, und dafür lauffähig unabhängig von der Konfiguration".
Negativ könnte das zudem auch im Hinblick auf die Lauffähigkeit von Fremdscripts sein, wenn diese nicht mit dem erzwungenen Default-Zeichensatz zusammenarbeiten können, was aber recht selten ist.

Auf jeden Fall sinnvoll finde ich die Konfigänderungen bei MySQL. Da ist mir das voreingestellte latin1 mit schwedischer Kollation doch ein Dorn im Auge.

Die Kollation ist übrigens nur für die Sortierung relevant. Es macht also kaum einen unterschied, ob du die Schwedische Kollation nimmst oder die Deutsche. Sinn macht es aber statt latin1 hier eine UTF8 Kollation zu wählen, in der Regel utf8_general_ci oder utf8_unicode_ci. Da musst du dann nur entscheiden, auf welcher Ebene du den Default-Zeichensatz umstellst. Sowohl das DBMS an sich, als auch jede Datenbank für sich, jede Datenbanktabelle und sogar jedes Datenbanktabellen-Textfeld kann seine Standard-Kollation definiert bekommen. Ich würde die Kollation bei neuen Datenbanken von der Datenbankebene (über den "Operationen" Reiter) abwärts festlegen, nicht über irgendwelche Konfigurationsparameter pauschal für das ganze DBMS in der Konfigurationsdatei, aus dem oben genannten Grund. Diese wird dann automatisch bei Neuanlegen von Datenbanktabellen oder Textfeldern als erstes vorgeschlagen/genommen und taucht auch in den SQL-Anweisungen der Datenbankexport auf.
Bei existierenden Datenbanken wirst du nicht umhin kommen die Daten auf Datenfeldebene zu konvertieren.

Interessant und hilfreich für den PHP-Coder finde ich die init_connect Anweisung. Dann muss man nicht für jede UTF8-Verbindung aus dem PHP heraus immer das entsprechende SENT NAMES absetzten.

Ich lasse die SET NAMES Anweisung immer von meinem Datenbankwrapper setzen. Auch hier gilt für mich wieder, lieber die Abhängigkeiten im Code zu haben statt in der Konfiguration.

Mit dem skip-character-set-client-handshake wäre ich dagegen wohl eher vorsichtig in Bezug auf Kompatibilität.

Prinzipiell wäre ich mit allen Einstellungen vorsichtig und würde sie erst setzen, wenn es wirklich nötig ist, also wenn Probleme auftreten. Wie gesagt, wenn du auf Scriptebene alles sauber hällst wirst du kaum Probleme bekommen.

Kleines Beispiel warum man vorsichtig sein sollte: Nehmen wir an, du setzt wie von jemandem empfohlen im Apache "AddDefaultCharset UTF-8". Der Apache geht dann hin und sendet bei jeder Antwort im Header mit, dass das folgende Dokument mit UTF-8 kodiert ist. Im Fremdscript ist im HTML-head aber vielleicht ein meta Tag mit Zeichenkodierung iso-8859-1 gesetzt. Nun hat der Browser zwei sich widersprechende Informationen und muss sich entscheiden. Du hast als Administrator keine Kontrolle darüber für welchen Wert er sich entscheidet. Schlimmer noch, du hast keine Möglichkeit über meta Angaben Ausnahmen von dieser Regel zu setzen, das geht nurnoch über weitere Apache Konfigurationsparameter. Ende vom Lied: Die Datei ist vielleicht wirklich mit iso-8859-1 kodiert und schon hast du Umlauteprobleme.
Meine Empfehlung: Schreib dem Apache nicht vor, was er sagen soll.

Sowohl bei PHP als auch HTML hast du volle Kontrolle darüber, in welcher Kodierung dein Nutztext vorliegt. Man kann sich das logisch ganz leicht begreiflich machen: Überlege an welcher Stelle die Speicherung ins Spiel kommt. Das ist bei der Datenbank in der Datenbanktabelle/dem Datenbankfeld und in PHP/HTML in den Dateien. Das sind die Orte in denen die Abhängigkeit zur Zeichenkodierung existiert (und natürlich in der Kommination zwischen den Schichten). Kann der Apache als übergeordnete Einheit die Entscheidung pauschal für alle Dateitypen treffen? Logisch gesehen: nein. Was letztendlich beim User ankommt ist nur eine Folge aus deinen Entscheidungen die du davor getroffen hast. Die Abhängigkeit sollte immer dort gesetzt werden wo sie auch vorliegt.

bis hin zum Zeichensatz der Persistenzschicht selbst.

Das Wort "Persistenzschicht" musst ich - hüstel - erst mal googlen Du meinst den Zeichensatz des Dateisystems, richtig?

Entschuldige, ich hab schonwieder zu sehr meine Programmiererbrille auf Eine Art Code logisch zu trennen ist das dreistufige Schichtmodell, bei dem die Präsentationsschicht (z.B. statische HTML Dateien) von der Schicht mit der Anwendungslogik (.php Dateien die, die die Anfragen Bearbeiten, Daten aufbereiten, etc) und der Datenhaltungsschicht/Persistenzschicht (in der Regel ein Datenbankmodell oder Dateimodel) aufgeteilt wird. Was ich eigentlich veranschaulichen wollte ist, dass nichtnur die Schichten an sich gültige sich nicht widersperchende Zeichenkodierungen verwenden sollten (Datenbanktabellenfelder, header Angaben), sondern die Kommunikation zwischen diesen auch passende Zeichenkodierungen aushandeln sollten (SET NAMES, accept charset). Und wenn dann noch die Daten korrekt gespeichert sind (bei HTML-/PHP-Dateien auf die Editoreinstellung achten, bei Datenbanken Ex- und Imports auch prüfen) läuft das wunderbar.

Jetzt ist der Beitrag schon viel zu lang.
Kurz: Ich würde auf alle von dir genannten Konfigurationsparameter verzichten, bis du merkst dass es ohne nicht geht.
Lege den Fokus lieber auf die vorhandenen Nutzdaten, den Dateien und den Zeichensätzen der Datenbank.

mit freundlichen Grüßen,
Altrea

P.S.: Auf Kürzungen und Schreibfehlerprüfungen wurde verzichtet. Wer Fehler findet, darf sie behalten