Zeichen werden falsch dargestellt

Autor: thorn (vom WB Forum)

Die Frage nach falscher Darstellung von Zeichen im Browser dürfte zu den wohl meist gestellten Fragen im Website Baker Forum gehören. Schuld ist die mangelhafte Unterstützung von UTF-8 bis einschliesslich WB v2.6.5. Mit WB v2.6.6 wurden Kernfunktionen erweitert, um UTF-8 Unterstützung zu gewährleisten.

• Begriffsklärung (Charset, Kollation)
  
• Grundeinstellungen (Fehlerursachen/Lösungen)
  
• Weiterführende Informationen (vorsicht länglich)
  

Begriffsklärung (Charset, Kollation)

Nachfolgend eine kurze Erklärung der wichtigsten Begriffe rund um das Thema MySQL und Zeichendarstellung:

• Character-Set: Der Zeichensatz (genauer gesagt, das Encoding) also z.B. latin1, cp1251, utf8, ....
• Collation: Die Sortier-Reihenfolge (für Strings, für Vergleiche, ...) (z.B. latin1_swedish_ci, utf8_unicode_ci, ...).
  Die Collation ist an den Zeichensatz gebunden, d.h. die Einstellung "latin1_swedish_ci" erzwingt als Character-Set "latin1". (d.h. in der üblichen myphpadmin-Ansicht wird durch Einstellen der collation auch gleich der character-set eingestellt.)

Grundeinstellung (Fehlerursachen/Lösungen)

Als Ausgangsbasis ist ein Update auf die letzte WB Version dringend anzuraten. In allen Website Baker Versionen ab 2.6.6 sollte im Backend: Optionen -> Erweiterte Optionen anzeigen -> Zeichensatz die Option UTF-8 eingestellt werden. Andere Zeichensätze sollten auch funktionieren, wirklich sicher fährt man aber nur mit UTF-8. Trotz UTF-8 und WB v2.6.6 können noch folgende Probleme auftauchen:

Fehler 1: Umlaute oder z.B kyrillische Zeichen werden im Browser falsch angezeigt

Ursache #1: Fehlender Charset im Template.

Überprüfe, ob im Template folgender Code eingebunden ist:

<meta http-equiv="Content-Type" content="text/html; charset=<?php 
if(defined('DEFAULT_CHARSET')) { echo DEFAULT_CHARSET; } else 
{ echo 'utf-8'; }?>" />

Ursache # 2: Apache liefert PHP als ISO-8859-1 aus

Wenn Ursache#1 auszuschließen  ist, bitte überprüfen, welchen Zeichensatz der Browser benutzt. Dies wird wahrscheinlich fälschlicherweise ISO-8859-1 sein. Stellt man den Browser-Zeichensatz auf UTF-8 wird alles richtig angezeigt, bis man die nächste Seite lädt. Eine dauerhafte Abhilfe schafft eine .htaccess Datei im WB-Verzeichnis auf dem Server (dort, wo auch die config.php steht) mit folgendem Inhalt. 

<Files .htaccess>
order allow,deny
deny from all
</Files>
php_value default_charset UTF-8

Hiermit wird Apache angewiesen alle php-generierte Seiten als UTF-8 auszuliefern.

Fehler 2: Nur einige Zeichen werden falsch dargestellt

Bei Verwendung von kyrillisch sind z.B. "И" und "ш" betroffen, bei Verwendung von griechisch z.B. "ή".

Ursache: Ein default-character-set ist in my.ini (oder my.cnf) vorgegeben, oder der Benutzer hat eine Datenbank mit einem Character-Set festgelegt

Normalerweise sind diese Angaben nicht vorhanden, und es wird hier automatisch für beides latin1 angenommen (das ist die default-Einstellung). Ändert man dies nun nur an einer Stelle (man legt für die Erstellung der Datenbank einen anderen Charater-Set als latin1 fest, benutzt aber keinen Eintrag für default-character-set, oder andersherum) kommt es unweigerlich zu Konvertierungsfehlern, die dazu führen, daß scheinbar wahllos einige Zeichen nicht richtig angezeigt werden.

Das bedeutet insbesondere wenn der Service-Provider einen default-character-set in der my.ini festgelegt hat, und dieser von latin1 abweicht, bleiben nur zwei Möglichkeiten:  entweder, wenn möglich, diesen Eintrag ändern lassen; oder, beim Anlegen der Datenbank (sofern man dazu überhaupt die nötigen Rechte hat), den Character-Set der Datenbank auf den gleichen Wert einstellen. Ist dies vor der Installation von WB nicht möglich, muß man nachträglich (aber bevor man Inhalte in WB anlegt) den Character-Set von _allen_ Spalten und Tabellen von Hand umstellen. Ebenso muß man (wenn möglich) den character-set der Datenbank selbst umstellen. 

Zusammenfassung:
Der default-character-set und der Character-Set der einzelnen Spalten muß übereinstimmen. Dies ist normalerweise der Fall wenn man die Installation von WB wie in der Anleitung beschrieben durchführt.

Weiterführende Informationen

Wenn Daten in die Datenbank geschrieben werden, müssen sie zuerst aus dem Zeichensatz der Anwendung in den Zeichensatz der Datenbank (*1) gewandelt werden. Entsprechend müssen, wenn Daten aus der Datenbank gelesen werden, diese in den Zeichensatz der Anwendung zurückgewandelt werden. Vereinfacht (*2) ausgedrückt gibt es also zwei Seiten zu beachten:

1. den Zeichensatz von Website Baker (Anwendung).
2. den Zeichensatz der Datenbank (*1).

Normalerweise sollte die Anwendung beim Anlegen der Datenbank und ihrer Tabellen den zu verwendenden Zeichensatz festlegen (sinnvollerweise als utf8). Auch sollte die Anwendung bei jedem Verbindungsaufbau zur Datenbank ein "SET NAMES ...." durchführen (SET NAMES legt den Character-Set für character_set_client, character_set_results und character_set_connection fest). In diesem Fall müßte man sich um dieses ganze Thema keine Gedanken machen; es würde einfach so laufen...

Probleme ergeben sich nun daraus, das Website Baker keine der o.g. Festlegungen trifft. Und in diesem Fall benutzt MySQL immer den default-Wert "latin1" (bzw. mit Angabe der Kollation: "latin1_swedish_ci").

Benutzt man innerhalb Website Bakers nun ISO-8859-1, so ist dies generell problemlos, da ISO-8859-1 in latin1 enthalten ist.
Benutzt man dagegen einen anderen Zeichensatz, z.B. UTF-8, werden die Daten ebenfalls, wie bei ISO-8859-1, ohne Konvertierung direkt in die Datenbank geschrieben, weil mySQL nicht weiß, daß es hier eine Konvertierung durchführen müßte.

Beim Auslesen aus der Datenbank werden die Daten ebenfalls nicht konvertiert. Und weil hier in beide Richtungen keine Konvertierung stattfindet funktioniert Website Baker trotz "falscher" Einstellung des connection-character-sets auch mit anderen Zeichensätzen (*3) als ISO-8859-1. Lediglich wenn man sich die Daten direkt in der Datenbank ansieht, beispielsweise mit phpMyAdmin, sehen die dort gespeicherten Zeichen "kaputt" aus. So wird z.B. "Über" als "Ãœber" angezeigt. Dies liegt daran, daß phpMyAdmin die Daten aus dem Zeichensatz der Datenbank zur Ansicht in den Zeichensatz wandelt, den das Betriebssystem (Windows, Linux) als Standard benutzt. Ist dies z.B. UTF-8, so führt phpMyAdmin eine Konvertierung latin-1->uft8 durch, obwohl die Daten schon als UFT-8 in der Datenbank liegen.

Ändert man den Zeichensatz der Datenbank / der Tabellen von Hand, z.B. auf utf8, so wird in den oben skizzierten Ablauf noch jeweils eine Konvertierung eingefügt, da mySQL annimmt, es müsse von latin-1 (client) nach utf8 (database) konvertieren. Bei der Verwendung von ISO-8859-1 innerhalb Website Bakers ist dies nun wieder unproblematisch, aber bei Benutzung von UTF-8 z.B. bedeutet dies, daß nun ein String, der in UTF-8 kodiert ist, einer Konvertierung latin-1 --> utf8 unterzogen wird. Und beim auslesen der Daten entsprechend utf8 --> latin-1. Häufig hat man Glück, und die Zeichen "überstehen" diese falsche Behandlung, aber bei einigen Zeichen entsteht dabei nur noch Zeichensalat...
Das gleiche gilt, wenn man den "client-character-set", ändert, z.B. durch eine Einstellung (default-character-set) in der Konfigurations-Datei von mySQL.

Nur wenn man beide Änderungen aufeinander abstimmt (beide auf z.B. utf8 oder beide auf cp1251), funktioniert es wieder so wie anfangs für latin-1 beschrieben.

(*1): Ausschlaggebend ist hier im Endeffekt nur der Column-Character-Set.
(*2): Vereinfacht, weil es wesentlich mehr Einstellmöglichkeiten gibt:
Datenbank-seitig:
- Server-Character-Set
- Database-Character-Set
- Table-Character-Set
- Column-Character-Set
Client-seitig:
- Character-String-Literal-Character-Set
- Client-Character-Set
- Connection-Character_Set
- Results-Character_Set
(*3): Eine Ausnahme scheinen hier die Zeichensätze ISO-2022-JP und -KR zu bilden,
möglicherweise auch BIG5 und GB2312 -- das muß noch genauer geprüft werden. 

Copyright (c) 2007 Website Baker Hilfe Team
Text und Bilder dieser Seite unterliegen den Bestimmungen der Creative Commons Attribution-NonCommercial-NoDerivs 3.0 Lizenz. Sie dürfen den Inhalt für nicht kommerzielle Zwecke vervielfältigen und verbreiten, solange dieser unverändert übernommen wird, der Copyright Hinweis bestehen bleibt und ein Link zu http://websitebaker.org angegeben wird.