Webserver und Charsets (UTF8, ISO8559)

Wer Sonderzeichen unterschiedlicher Sprachen (z.B. Deutsch und Tschechisch) kombinieren will, stößt rasch an Grenzen. HTML-Entities (ü auml; usw) sind keine Abhilfe, wenn mit nicht html-Frontends (z.B. Access, OOOBase, online-pdf-Creators u.ä.) ebenfalls direkt aus der Datenbank gearbeitet werden soll.

Wie man ein komplettes, in mehreren Entwicklungsschritten erstelltes datenbankorientiertes Webprojekt auf UTF8 umstellt. Zu diesem System gehören ein MYSQL-Server, eine php-generierte Website inkl. Webshop, die über html-Frontends gesteuert wird. Weiters lokale Anwendungen sowohl in Windows/MSAccess bzw. Linux/OOOBase, für direkte Datenpflege-Aufgaben in der MYSQL-Datenbank (z.B. Produktpflege, Buchhaltung) Diese Anwendungen kommunizieren über eine ODBC-Schnittstelle mit der MYSQL-Datenbank.

Produktivdaten

Wo überall charsets die Datenspeicherung beeinflussen

Damit in einem derartigen System jedes an jeder Stelle eingegebene Zeichen (also auch ä-Ö-Ü-ß-Å™-ž-Ä› usw) auch an jeder anderen Stelle wieder ausgegeben - das gleiche Aussehen hat, muss das gesamte System für die Speicherung, Abruf und Wiedergabe des utf8-Zeichensatzes (charset) ausgelegt sein. Die in den Einzelprogrammen vorgegebenen Aufrufe und Kommandos reichen da - im Gegensatz zu den Angaben in den Handbüchern - alleine nicht immer aus.

Was alles passiert, wenn ein Zeichen in einem bestimmten Zeichensatz in eine Datenbank eingegeben wird, die vielleicht auf einen anderen Zeichensatz hört und dieses Zeichen wiederrum von einer Schnittstelle ausgelesen wird, die irgendwo im lokalen Computer auf eine lokale Einstellung eines dritten Zeichensatzes hört, ist ->hier beschrieben.

Ich hab nicht alles davon kapiert, war aber auch nicht nötig, weil die darin enthaltenen Lösungen ausreichend genug sind. Fix ist, dass die Vereinheitlichung von unten (Erstens) nach oben (Drittens) erfolgen muss. Stellt man nämlich ein bestehendes System auf UTF-8 um, gibt es u.U. danach eine Menge Fehlausgaben, die dadurch entstehen, dass bisherige sich selbst aushebelnde charset-Doppelfehler nun nicht mehr vorliegen. Da heißt es dann entweder ein Konveriterungsscript schreiben oder Seite für Seite alles durchgehen und nachbessern. Und diesen Aufwand sollte man, wenn schon nicht vermeidbar, dann nur 1x machen müssen.

Erstens: Datenbank am MYSQL-Server

"Charset" ist das Speicherschema,  "collation" nur die Sortierreihenfolge. Im übrigen System kann eine andere Einstellung gewählt werden, die dann aber überall gleich sein muss.

MYSQL-Server

charset-default einstellen ist nur möglich, wenn Vollzugriff auf den Webserver besteht (virtueller Server oder Localhost z.B. mit XAMPP). Ist bei semiprofessionellen externen Hosting-Produkten nicht möglich aber auch nicht unbedingt nötig. Allerding muss das nachfolgende "set names" Kommando konsequent im eigenen Webprojekt umgesetzt werden, um ein mglw. anderes Server-Default zu überschreiben.

MYSQL-Datenbank

hier lassen sich die Standardeinstellungen künftiger Tabellen verändern. Bestehende Tabellen werden aber nicht konvertiert:

create database NAMEDERDB character set CHARNAME (Schreibweise UTF8, bei Datenbank erstellen)

alter database NAMEDERDB character set CHARNAME (Schreibweise UTF8, bei DB ändern)

MYSQL-Tabellen

hier lassen sich die Standardeinstellungen künftiger Tabellenspalten verändern. Bestehende Tabellenspalten werden aber nicht konvertiert:

CREATE TABLE `namedertabelle` CONVERT TO CHARACTER SET utf8 COLLATE utf8_general_ci;

das default bestehender tabellen wird konvertiert mit:

ALTER TABLE `namedertabelle` CONVERT TO CHARACTER SET utf8 COLLATE utf8_general_ci;

MYSQL-Tabellenspalten

hier wird jetzt entschieden was Sache ist. Mit welchem Chairset die Daten gespeichert werden und nach welcher Collation sie sortiert werden. Tebellenspalte erstellen:

CREATE TABLE  `tabellennnaem` (`spaltenname` char(1) COLLATE utf8_general_ci NOT NULL default '')

Generell gilt: es wird immer auf das nächst höhere default zurückgegriffen, wenn gar keine charset-Angabe gemacht wird

Zweitens: Datenbankverbindung

Hier liegt der entscheidende Knackpunkt, der das Zusammenspiel aller richtig eingestellten Systeme weiterhin stören kann. Selbst wenn die MYSQL-DB richtige Datenbankeinstellungen, richtig nach UTF8 konvertierte Tabellen besitzt, das CMS, der Webschop, das lokale DBMS (Access oder Base) alles auf UTF8 eingestellt sind - der Provider aber ein anderes Defaultcharset für den Gesamtserver vorgibt - dann kann weiterhin Verzweiflung aufkommen über  "öüä", welche plötzlich so "?��" aussehen. Und dies serverseitig nicht veränderbar ist, weil kein Zugriff auf die notwendigen Dateien (z.B. php.ini) möglich ist.

Die Lösung ist trotzdem simpel: an jeder Stelle, wo ein Frontend eine Verbindung zur Datenbank aufbaut, muss einmalig das SQL-Kommando 

an den MYSQL-Server abgesetzt werden. Damit wird diesem mitgeteilt, auch wirklich UTF8-Daten zu liefern, und keine eigenmächtigen, ungewünschten Konvertierungen durchzuführen nur weil z.B. das Server-Default es so vorgibt.

ODBC muss dieses SQL-Statement senden, damit die Frontends Access und Base richtige Zeichen anzeigen.
PHP muss dieses SQL-Statement senden, damit die html-basierten Frontends (CMS, OSC, die Homepage selbst) richtige Zeichen anzeigen.

ODBC Linux Ubuntu

Menügeführt

Aufruf: sudo ODBCConfig

(->welche Pakete für dieses Programm nötig sind)

Über Konsole

gksu gedit /etc/odbc.ini
einfügen der Zeilen:

[DBVERBINDUNG]
Charset    = utf8
Stmt        = set names utf8

in Base unter "Bearbeiten/Datenbanken/Eigenschaften"

ODBC Windows

je nach WINDOOF-Version: systemsteuerung/verwaltung/odbc:

php Webserver

an jeder stelle, wo eine verbindung zur DB aufgemacht wird mit

mysql_connect(DB_HOST, DB_USERNAME, DB_PASSWORD);

muss nachgesetzt werden ein

Drittens: html-Frontends

Formulardaten

werden vom Browser an den Server zurückgesendet. Auch für diese Daten-Verbindung muss es eine Anweisung an den Browser geben, da dieser sonst sein eigenes default nimmt und dieses nicht notwendigerweise mit dem Server ident ist. Dies geschieht am Ende jedes <Form>-Tags:

<form action=" [uswusw] " accept-charset="UTF-8">

Angezeigte Seiten

Es muss dafür gesorgt werden, dass das meta-Tag:

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

überall auf das gewünschte charset gestellt wird.

Homepage selbst bzw. statische Seiten

Metadaten

So lange ein serverseitiges File (z.B. php-file) in seinem Code keine Sonderzeichen enthält (und das ist nach wie vor - wenn man selbst Code schreibt - die allerbeste Empfehlung), ist auch der Zeichensatz des Files selbst nicht von belang und man kann diesen Punkt überspringen.

Völlig anders sieht es in folgenden zwei Fällen aus:

1. Files, die Textstücke enthalten, die zur Klartextanzeige ausgelesen werden. Dies trifft für praktisch alle Sprachsteuersysteme zu (Dateien mit Namen wie "language.php", "english.php", "german.php" in allen Varianten). Jedes CMS oder Shopprogramm im Open-Source Bereich, welches Mehrsprachigkeit unterstützt, besitzt solche Files. Die wenigsten greifen auf eine Datenbank zu sondern schreiben die im Frontend verwendeten Textstücke im Klartext. Entities sind hier keine Abhilfe, denn z.B. bei automatischer Versendung von Antwort-Mails werden diese auch nicht nicht von allen Mailprogrammen richtig umgesetzt.
2. Im Extremfall (schon erlebt), führen sogar Umlaute in Kommentarzeilen zum Programmabsturz, wenn das File selbst mit dem falschen Charset am Server liegt. Deutsche Umlaute in Kommentarenzeilen halte ich persönlich für schlichtweg schlechten Programmierstil, weil man dann eben voraussetzt, dass alle die das Script nutzen automatisch das eigene Charset zu haben haben. Es ist ganz schön ärgerlich, wenn man eine derart inkompatible Contribution in sein Programm einpflegt und stundenlang im aktiven Code vergeblich nach dem Fehler sucht, weil nichts geht. Aber es nutzt nix, es ist nun mal verbreiteter Aberglaube selbst bei professionellen Programmierern, dass in Zeiten von Windoof XP und Linux nicht-englische Zeichen überall bedenkenlos anwendbar sind. Also immer mit kontrollieren, wenn was nicht funktioniert und ggf. Umlaute in Kommentaren des Autors einfach elimenieren. In diesem Fall pfeifen wir ausnahmsweise auf GNU usw, auch wenn wir das sonst natürlich nicht tun.

html-Editoren wie Bluefish usw. zeigen das Charset der Datei direkt an und stellen auch eine einfache Umstellfunktion zur Verfügung.

Konvertieren der Dateien über die Konsole

Wenn es viele Dateien auf diese Weise zu konvertieren gilt und der einzelne Aufruf über einen html-Editor zu umständlich ist, kann auch mit einem Konsolenbefehl (bash-script auf Neudeutsch) gearbeitet werden:

iconv -f ISO8859-1 -t UTF-8 LATIN1_skript > UNICODE_skript

Infos ->hier

.htaccess im Serverroot

Weist den Server an, Files mit der angegebenen Endung standardmäßig im angebenen Charset auszuführen. Infos dazu ->hier.

<FilesMatch "\.(htm|html|css|js)$">
AddDefaultCharset UTF-8
</FilesMatch>

Die liebe Familie

Seitenanfang

Die Häuser