PHP, MySQL und der Ärger mit UTF-8
erschienen in der Kategorie Webdesign, am 28.03.2012

Immer wieder liest man im Netz von Problemen mit PHP, MySQL und UTF-8. Der Webserver soll Daten aus der MySQL Datenbank lesen und auf der, in UTF-8 codierten, Webseite darstellen. Trotz der Tatsache, dass die Daten auch in der Datenbank im UTF-8 Format gespeichert sind, werden die Umlaute falsch dargestellt.
Tückisch an diesem Problem ist vor allem auch die Tatsache, dass der Fehler auf dem eigenen Rechner (Lokalhost) oft gar nicht auftritt. So kann es vorkommen, dass man in aller Seelenruhe, auf dem lokal gehosteten Webserver, eine Homepage baut, dann irgendwann glaubt fertig zu sein, und die Seite voller Vorfreude auf den Webspace hochlädt. Dachte man bis eben noch endlich fertig zu sein, wird man nun eines Besseren belehrt und mit bösartigen Fragezeichen, statt Umlauten, beworfen.
Des Fehlers Ursprung begründet sich in der Tatsache, dass die meisten deutschen Provider davon ausgehen, dass ihre ebenfalls deutschen Kunden Webseiten bauen, die mit der ISO-8859-1 Codierung arbeiten. Daher haben sie ihre Web- und Datenbankserver so konfiguriert, dass sie mit dieser Codierung optimal klarkommen.
Zur Fehlerbehebung und vor allem zur Fehlervermeidung (für jene, die nicht auf diese Webseite gestoßen sind, weil sie gerade mit dem beschriebenen Problem kämpfen), sei Folgendes empfohlen: Vor dem ersten Zugriff (Query) auf die Datenbank sollte folgende Codezeile ausgeführt werden:
Dies sorgt dafür, dass der Datenbankserver weiß, dass er sowohl bei Datenbankabfragen als auch bei Inserts oder Updates mit UTF-8-codierten Daten arbeiten soll. Der Befehl muss nicht vor jeder Query ausgeführt werden, es reicht, wenn man ihn vor der Ersten ausführt oder am besten direkt, nachdem man die Datenbankverbindung aufgebaut hat.
In vielen Foren wird, statt dieser Lösung, empfohlen mit den PHP-Funktionen utf8_encode und utf8_decode zu arbeiten, dies halte ich aber für einen ziemlich (wartungs-) aufwendigen Workaround, der das Problem auch nicht wirklich bei der Wurzel packt.
Hier noch ein paar allgemeine Tipps für eine saubere UTF-8 Webseiten-Umsetzung
Tschüssikowski, Fragezeichen des Grauens!
Wer seinen eigenen Webserver betreibt, kann sich die oben genannten Punkte (abgesehen vom HTML-Meta-Tag) sparen, indem er die entsprechenden Einstellungen als Standard festlegt.
Apache-Einstellungen: In der Konfigurationsdatei (in der Regel /etc/apache2/http.conf oder /etc/apache2/apache2.conf) des Apache-Webservers fügt man die folgende Zeile hinzu (oder ändert die Codierung, falls die Zeile schon vorhanden ist):
PHP-Einstellungen: In der Datei php.ini (unter /etc/php5/apache2/ zu finden) ändert man die folgenden Parameter, bzw. fügt sie hinzu, falls noch nicht vorhanden:
Falls vor einem Eintrag noch ein Semikolon steht, muss dieses entfernt werden (sonst ist er auskommentiert).
MySQL-Konfiguration: In der der Datei /etc/mysql/my.cnf fügt man folgende Einstellungen ein:
Das nimmt einem auch das Ausführen der oben gezeigten Query ab. Somit muss man sich bei der Implementierung keine Gedanken mehr um die Codierung machen.
Nachdem die Änderungen vorgenommen wurden, müssen die betreffenden Server neu gestartet werden (# /etc/init.d/apache2 restart, # /etc/init.d/mysql restart).

Des Fehlers Ursprung begründet sich in der Tatsache, dass die meisten deutschen Provider davon ausgehen, dass ihre ebenfalls deutschen Kunden Webseiten bauen, die mit der ISO-8859-1 Codierung arbeiten. Daher haben sie ihre Web- und Datenbankserver so konfiguriert, dass sie mit dieser Codierung optimal klarkommen.
Zur Fehlerbehebung und vor allem zur Fehlervermeidung (für jene, die nicht auf diese Webseite gestoßen sind, weil sie gerade mit dem beschriebenen Problem kämpfen), sei Folgendes empfohlen: Vor dem ersten Zugriff (Query) auf die Datenbank sollte folgende Codezeile ausgeführt werden:
mysqli_query($dbcon, "SET NAMES 'utf8'");
Dies sorgt dafür, dass der Datenbankserver weiß, dass er sowohl bei Datenbankabfragen als auch bei Inserts oder Updates mit UTF-8-codierten Daten arbeiten soll. Der Befehl muss nicht vor jeder Query ausgeführt werden, es reicht, wenn man ihn vor der Ersten ausführt oder am besten direkt, nachdem man die Datenbankverbindung aufgebaut hat.
$dbcon = mysqli_connect($dbhost,$dbuser,$dbpass);
mysqli_select_db($dbcon, $dbname);
mysqli_query($dbcon, "SET NAMES 'utf8'");
...
mysqli_query(...);
...
mysqli_close($dbcon);
mysqli_select_db($dbcon, $dbname);
mysqli_query($dbcon, "SET NAMES 'utf8'");
...
mysqli_query(...);
...
mysqli_close($dbcon);
In vielen Foren wird, statt dieser Lösung, empfohlen mit den PHP-Funktionen utf8_encode und utf8_decode zu arbeiten, dies halte ich aber für einen ziemlich (wartungs-) aufwendigen Workaround, der das Problem auch nicht wirklich bei der Wurzel packt.
Hier noch ein paar allgemeine Tipps für eine saubere UTF-8 Webseiten-Umsetzung
- im HTML Head Bereich angeben, dass die Seite UTF-8 kodiert ist:
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> - im PHP Header ebenfalls:
header("Content-Type: text/html; charset=utf-8"); - alle PHP Dateien UTF-8 kodiert abspeichern
Tschüssikowski, Fragezeichen des Grauens!
UTF-8 Server-Einstellungen
Update 05.02.2014: Weil diesbezüglich gerade eine Frage per Mail rein kam, hier noch ein paar Infos zur Linux-Server-Konfiguration:Wer seinen eigenen Webserver betreibt, kann sich die oben genannten Punkte (abgesehen vom HTML-Meta-Tag) sparen, indem er die entsprechenden Einstellungen als Standard festlegt.
Apache-Einstellungen: In der Konfigurationsdatei (in der Regel /etc/apache2/http.conf oder /etc/apache2/apache2.conf) des Apache-Webservers fügt man die folgende Zeile hinzu (oder ändert die Codierung, falls die Zeile schon vorhanden ist):
AddDefaultCharset UTF-8
PHP-Einstellungen: In der Datei php.ini (unter /etc/php5/apache2/ zu finden) ändert man die folgenden Parameter, bzw. fügt sie hinzu, falls noch nicht vorhanden:
default_charset = "UTF-8"
[iconv]
iconv.input_encoding = UTF-8
iconv.internal_encoding = UTF-8
iconv.output_encoding = UTF-8
[exif]
exif.encode_unicode = UTF-8
[mssql]
mssql.charset = "UTF-8"
[iconv]
iconv.input_encoding = UTF-8
iconv.internal_encoding = UTF-8
iconv.output_encoding = UTF-8
[exif]
exif.encode_unicode = UTF-8
[mssql]
mssql.charset = "UTF-8"
Falls vor einem Eintrag noch ein Semikolon steht, muss dieses entfernt werden (sonst ist er auskommentiert).
MySQL-Konfiguration: In der der Datei /etc/mysql/my.cnf fügt man folgende Einstellungen ein:
[client]
default-character-set=utf8
[mysql]
default-character-set=utf8
[mysqld]
collation-server = utf8_general_ci
init-connect='SET NAMES utf8'
character-set-server = utf8
default-character-set=utf8
[mysql]
default-character-set=utf8
[mysqld]
collation-server = utf8_general_ci
init-connect='SET NAMES utf8'
character-set-server = utf8
Das nimmt einem auch das Ausführen der oben gezeigten Query ab. Somit muss man sich bei der Implementierung keine Gedanken mehr um die Codierung machen.
Nachdem die Änderungen vorgenommen wurden, müssen die betreffenden Server neu gestartet werden (# /etc/init.d/apache2 restart, # /etc/init.d/mysql restart).
Geschnatter
60 Kommentare, selbst mitschnattern
DAnKE, am 11.12.2013 um 21:15 Uhr
DANKE!
Andi, am 09.01.2014 um 10:45 Uhr
Danke, hat sehr geholfen!
Marc, am 05.02.2014 um 13:27 Uhr
Danke :-)
Andreas, am 06.02.2014 um 00:01 Uhr
Danke für die Ergänzung!
Antwort: Gern geschehen. Läuft's denn jetzt?
Andreas, am 06.02.2014 um 00:21 Uhr
Ja, ich hatte nur erst vergessen den MySQL-Server neu zu starten.
Antwort: D'oh!
Alexander, am 06.02.2014 um 11:46 Uhr
Und warum nehmt ihr nicht einfach ISO-8859?
Anonym, am 06.02.2014 um 13:48 Uhr
@Alexander:
Weil ISO-8859 für viele Sachen sehr ungeeignet und unflexibel ist.
Außerdem ist UTF-8 der de-facto-Standard unter Linux-Systemen. Folglich ist es eigentlich auch Standard für die meisten Web-Applikationen (Apache, Mysqld, ...).
Weil ISO-8859 für viele Sachen sehr ungeeignet und unflexibel ist.
Außerdem ist UTF-8 der de-facto-Standard unter Linux-Systemen. Folglich ist es eigentlich auch Standard für die meisten Web-Applikationen (Apache, Mysqld, ...).
Es gelten die Regelungen der Datenschutzerklärung.