Tach!
Kann man machen. Die Umkodierung kann aber auch MySQL selbst vornehmen.
Das war ja die Frage (die ich im Hinterkopf hatte), ob MySQL das auch wirklich tut oder nach außen nur die zur Tabelle/Datenbank passende Codierung liefern möchte. DEN Verdacht habe ich nämlich noch.
MySQL ist eine Blackbox. Was es wirklich intern tut, kann man teilweise nur durch Versuche nachweisen. Dabei muss man aber beachten, dass die Umkodierungen
Es ist allerdings beschrieben, wie MySQL mit den ankommenden Daten der Verbindung umgeht und mit Abfrageergebnissen. Der Teil zwischen Interpretation und Schreiben in Felder sowie Auslesen und der Stelle an der character_set_results berücksichtigt wird, fehlt allerdings. Das ist der Teil, an dem ich immer behaupte, dass die Werte zwischen der Vebindungskodierung und der Feldkodierung umkodiert wird. Diese Behauptung beruht aber auf einem Versuch, den ich vor langer Zeit unternahm. Er ist auch hier im Achiv irgendwo zu finden. Seitdem hat sich in MySQL nichts diesbezügliches verändert, so dass die Testergebnisse immer noch gelten. Meine Behauptung stütze ich auf die prinzipbedingten verlustbehafteten Umkodierfehler, die sich dann nachweisen lassen. Zum Beispiel gehen Zeichen verloren, wenn man Nicht-Latin1-Zeichen auf einer UTF-8-ausgehandelten Verbindung sendet und diese in einem Latin1-Feld abzulegen versucht. Die werden dann zum Fragezeichen 0x3F (meiner Erinnerung nach). Latin1 hat ja kein zu � äquivalentes Zeichen. Dieses Fragzeichen lässt sich nicht mehr rückwärts zum eigentlichen Zeichen umwandeln. Es wird auch weder beim Umkodieren von UTF-8 nach Latin1 noch andersrum verändert, so dass es beim Auslesen unverändert bleibt, egal welche Verbindungskodierung man wählt. Das nehme ich als Indiz, dass hinzu umkodiert wird. Beim Auslesen kann man das auch mit einem passenden Versuch in ähnlicher Form nachweisen, aber das spar ich mir jetzt.
dedlfix.