Unterschiede beim Encoding zwischen MySQL 5.1 und 5.0
Nach der Umstellung von MySQL 5.0.67 auf 5.1.40 hat unsere Perl-basierte Web-Applikation INSERT-Statements, in denen Strings mit Umlauten vorkamen, zwar klaglos ausgeführt. Am Browser jedoch erschienen plötzlich dennoch wieder seltsame Zeichen, und zwar solche, die ich auch schon vor der in meinem früheren Artikel beschriebenen Problemlösung im Zusammenhang von ExtJS, UTF-8, ISO-8859-1 und Perl beobachtet hatte. Eigentlich war das Problem also schon mal behoben. Warum taucht es jetzt wieder auf? Nun: Das Encoding war bisher systemweit ISO-8859-1. Wie im gerade erwähnten Artikel beschrieben, funkte lediglich ExtJS durch Nutzen der JavaScript-Function encodeURIComponent dazwischen und sendete seine Ajax-Requests UTF-8-codiert. Dieses Problem war, siehe erwähnter Artikel behoben. Jedoch sind in MySQL 5.1 Bugs behoben, die in 5.0.67 wohl noch existiert haben, so auch das Verhalten, dass beim Senden eines INSERT-Statements, in dem ISO-8859-1-codierte Zeichen gemischt mit UTF-8-codierten Zeichen mit der neueren DBMS-Version ("sicherheits"halber?) UTF-8 als Default verwendet wird, während 5.0.67 hier dem INSERT-Statement brav das in den Session-Variablen hinterlegte latin1 aufgezwungen hat. Und da eine Request-Parameter nicht ISO-8859-1-codiert war, sondern UTF8, liefen wir eben in dieses unerwünschte Verhalten rein. Wieder was gelernt...
Labels: Ajax, Asynchronous JavaScript and XML, Character Set, Characters, Codierung, Encoding, ExtJS, GUI, ISO-8859-1, ISO-8859-15, ISO-Latin-1, Migration, mySQL, Umlaut, UTF-8, XMLHttpRequest


0 Kommentare:
Kommentar veröffentlichen
Links zu diesem Beitrag:
Link erstellen
<< Home