Softwareentwicklung

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

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++.