Gerd Riesselmann: Notizen aus dem Moor

Manchmal kommt es vor, dass der Import von Daten in die DB fehlschlägt, und man trotz korrektem UTF-8 wieder mit verhunzten Umlauten zu tun hat. In diesem Fall kann die CONVERT-Funktion von MySQL in Verbindung mit BLOB-Spalten hilfreich sein.

Es ist nun schon eine Weile her seit der letzten Folge, Zeit die unter anderem in den Gyro-PHP Application Framework geflossen ist. Dafür soll es in der Serie über PHP und UTF-8 nun endlich um PHP selber gehen. Dabei wird in einem ersten Schritt über die String-Funktionen von PHP zu reden sein, während die Frage der Regular Expressions auf eine weitere Folge vertagt ist.

Nachdem nun die MySQL-Datenbankverbindung reibungslos mit UTF-8 funktioniert und bevor wir uns im weiteren Verlauf der Serie über PHP und UTF-8 wirklich PHP selber zuwenden, sollen noch ein paar Worte über das korrekte ausliefern einer UTF-8 kodieren Webseite verloren werden. Das Problem, das hier angegangen werden soll ist: Wie erkennt der Browser eigentlich, dass eine Webseite in UTF-8 ist?

Am Anfang der Serie über PHP und UTF-8 soll zunächst ein Abstecher zu MySQL stehen, schließlich ziehen die meisten PHP-Anwendungen ihre Daten aus einer MySQL-Datenbank. Und anders als man vielleicht annehmen würde, ist die Verwendung von UTF-8 mit MySQL alles andere als problemfrei - insbesondere reicht es nicht aus, Tabellen einfach als UTF-8 zu deklarieren!

Es ist kein Geheimnis, dass PHP und Multibyte-Zeichensätze wie etwa UTF-8 nicht gut zusammen gehen. Dies hat drei Gründer:

• Die meisten PHP-Funktionen setzen wie selbstverständlich ANSI-Strings voraus, etwa die meisten String-Funktionen
• Bei PHP-Funktionen, die Multibyte-Zeichensätze verarbeiten können, wie etwa htmlentities(), werden diese nicht benutzt.
• Und last not least ist der korrekte Einsatz von MySQL und UTF-8 auch nicht einfach.

Ich werden diesen drei Problemfeldern in den nächsten Wochen nachspüren.

Teil 1: UTF-8 und MySQL
Teil 2: Webseiten als UTF-8 ausliefern
Teil 3: PHP String Funktionen
Exkurs: Exkurs: Falsche Daten in der DB fixen

... könnte das an einem fehlerhaften script-Tag liegen. Sowohl Internet Explorer 6 als auch 7 mögen es nämlich gar nicht, wenn das script-Tag selbstschließend ist. Folgender Code führt zu einer weißen Seite:

Nutzt man dagegen ein explizites schließendes Tag, ist der IE zufrieden:

Ich falle da leider jedesmal aufs Neue rein...

Eigentlich dachte ich, solche Meldungen gehörten der Vergangenheit an:

Leider verwenden Sie keinen Microsoft Internet Explorer 6 (SP1 oder SP2) / IE 7 oder Firefox 1.5.0.7/1.5.0.8.
Diese Webseite setzt derzeit Microsoft Windows als Betriebssystem mit installiertem Internet Explorer 6 (SP1 oder SP2) / IE 7 oder Firefox 1.5.0.7/1.5.0.8 und den Windows Mediaplayer ab Version 9 voraus.
Leider erfüllt Ihre Systemkonfiguration diese Voraussetzungen nicht, so dass der Inhalt voraussichtlich nicht korrekt dargestellt werden kann.

Um mal gleich mit der Tür ins Haus zu fallen: Es gibt kein Euro-Zeichen im ISO-8859-1-Zeichensatz (aka Latin1) - und folglich sind alle Versuche, einen Text mit dem niedlichen Kniddel-E von UTF-8 oder jedem anderen Zeichen-Encoding nach Latin1 zu konvertieren zum Scheitern verurteilt. Mit etwas Glück kommt dabei ein Fragezeichen oder immerhin noch Gekröse raus. Korinthenkacker wie iconv dagegen stellen einfach ganz die Arbeit ein und man endet in einem Fehler.

Interesse an der ganzen Geschichte (die Lösung wird auch verraten)?

Das nächste Treffen des Multimediatreffs findet am 2. Dezember 2006 im Mediapark Köln statt. Der Titel der Veranstaltung - "Web 3.0, die Zukunft des WWW" - ist vermutlich ein wenig hochtrabend, das Programm aber sehr interessant:

• Christian Wenz & Tobias Hauser: Bestandsaufnahme 2006
• Johannes Gamperl: AJAX - die Antwort auf alle Fragen?
• Kai Laborenz: Usabilty - Do's and Dont's
• Tomas Caspers: Barrierefreiheit 2.0
• Christian Wenz & Tobias Hauser: Das Web 2007 - Blick in die Kristallkugel

Der 2. Dezember ist ein Samstag, das Treffen von 12:30 Uhr bis 20:00 Uhr terminiert. Es muss also auf die Bundesliga verzichtet werden, die ausgerechnet an diesem Tag nur Samstagsspiele hat.

Ich hatte es ja schon einige Mal mit der Frage lohnt sich C++ Low-Level-Optimierung und ist C++ wirklich schnell. Dieses Thema stirbt wohl nie aus, wie man an dieser Debatte sehen kann: C++ als angeblich beste Sprache für mathematische Anwendungen, weil das ja so toll schnell ist. In den Kommentaren steht es bereits, aber die ausführlichste Antwort, warum High-Level-Sprachen schneller komplex rechnen als hardwarenahe Sprachen wie C oder C++ findet sich bei Good Math, Bad Math: Compiler optimieren besser als der Mensch, vorausgesetzt sie haben genug Informationen. Genau diese Informationen fehlen aber dem C++-Compiler gerade wegen der pointer-basierterten Natur von C++.