nicht angemeldet
Moin!
Derzeit ist es ja auch so, dass die meisten Provider MySQL nur in der Version 3.23.49 anbieten und UTF-8 erst ab Version 4.1 funktioniert, oder? Das heisst doch, dass in Versionen vor 4.1 nur die Kodierung mit Entities sinnvoll ist, oder?
Nein, es hängt davon ab, was die Datenbank tun soll.
UTF-8 ist eine sehr gut ausgedachte Codierungsform. Alle dabei entstehenden 8-Bit-Codes sind voll kompatibel zu allen Mechanismen, die eigentlich nur dafür gedacht sind, irgendein ASCII o.ä. (auch ISO-8859-1 etc.) zu verarbeiten, weil die durch UTF-8 entstehenden Bytecodes zum einen eben immer 8-Bit-Einheiten sind (von denen eine, zwei, drei oder vier zu einem Unicode-Zeichen zusammengehören), zum anderen aber auch immer darstellbare ASCII-Zeichen ergeben, niemals unsichtbare Steuerzeichen. Und außerdem kann man UTF-8 zumindest nach der "Zeichennummer" auch sortieren, ohne zu verstehen, welche Zeichen man da vor sich hat.
Wenn du in der Datenbank also nur Strings speicherst und wieder ausliest, die Datenbank selbst aber mit dem String nichts anfangen muß, kannst du eigentlich jede Datenbank nehmen, die nur irgendwie in der Lage ist, 8-Bit-Zeichen zu speichern. Notfalls nimmst du ein BLOB-Feld, da rein kannst du nämlich alle Bytes von 0 bis 255 speichern - also auch UTF-8.
Problematisch wird's nur dann, wenn es beim Datenzugriff auf Einzelzeichen ankommt.
Beispiel: Um ein alphabetisches Register aller gespeicherten Namen erstellen zu können, verwendet man vielleicht sowas hier:
SELECT ersterbuchstabe_aus(namensspalte) AS anfangsbuchstabe FROM tabelle GROUP BY anfangsbuchstabe
Das ist ein Problem. Die deutschen Umlaute sind UTF-8-codiert zwei Zeichen (das erste ist ein großes A-Tilde). Wenn die Datenbank UTF-8 nicht erkennt, wird bei den normalen ASCII-Zeichen (Bytewert kleiner 127) alles funktionieren, aber das Ä, Ö und Ü würde nicht geliefert werden können - das würde alles zu "A-Tilde" zusammengefaßt.
In solch einem Fall hast du mit der Datenbank ein Problem, weil die Datenbank dann wissen muß, wieviele gespeicherte Bytes denn nun zu einem Unicode-Zeichen dazugehören, andernfalls arbeitet die Zeichenabschneidefunktion falsch.
Das gleiche Problempotential bilden einige reguläre Ausdrücke, die z.B. mit Zeichenklassen operieren. /[a-zA-ZäöüßÄÖÜ]+/ findet mindestens eines der genannten Zeichen. Aber wenn die RegEx-Engine nicht in der Lage ist, die UTF-8-Umlaute als EINEN Buchstaben zu behandeln, sondern nur vom ISO-8859-1-Encoding ausgeht, werden die Umlaute niemals gefunden.
Weil UTF-8 eine eigentlich sehr nette Erfindung ist - jeder sollte es heutzutage eigentlich verwenden, wenn er eine Seite macht, egal ob die nur deutsch oder sogar mehrsprachig ist -, grundsätzlich bis auf oben genannte Feinheiten auch kompatibel zu UTF-8-unverständlichen Umgebungen ist, wesentlich kleinere Dateigrößen ergibt im Vergleich zu den numerischen Entities, und auch beim Formularversand der Browser die beste Lösung ist, wenn alle eingebbaren Zeichen auch tatsächlich auf dem Server ankommen sollen, spricht eigentlich nur noch die mangelnde Unterstützung durch die Texteditoren gegen eine Verwendung.
Aber die Entwicklung geht auch dort weiter. Als Freeware-Editor mit bescheidenen, aber funktionierenden Quelltext-Highlightingfunktionen kann ich "UniRed" empfehlen. Ansonsten können ziemlich viele kommerzielle Programme mittlerweile auch mit UTF-8 so umgehen, dass man tatsächlich das original eingegebene Zeichen angezeigt bekommt: Dreamweaver, Textpad, UltraEdit, Frontpage, Word,...
Ich empfehle http://www.alanwood.net/unicode/utilities_editors.html für eine Auflistung der Marktlage (UniRed ist dort einer der recht seltenen Freeware-Editoren, die auch wirklich komplett funktionieren), sowie die ganze Site für generelle Informationen zu Unicode.
- Sven Rautenberg