nicht angemeldet
Tach!
Beide DBs befinden sich auf einem Server.
Ich habe einige Seiten im Intranet, die ausschließlich auf die DB mit latin1_general_ci zugreifen, habe allerdings bisher nie beim Zugriff mit SET NAMES oder SET CHARACTER SET gearbeitet. Hier haben offenbar die Defaults für eine korrekte Darstellung gesorgt.
SET CHARACTER SET kannst du wieder vergessen, das macht ein paar Details anders als man sie normalerweise braucht. SET NAMES brauchst du nur, wenn du mysql(i)_set_charset() nicht zur Verfügung hast, also in ganz alten PHP-Versionen.
Nun habe ich ein kleines zugekauftes Modul eingekauft, das im Intranet eigenständig angezeigt werden soll. Diese DB ist komplett im UTF8 und alle Seiten dieses Moduls zeigen die eigenen Inhalte der eigenen Tabellen korrekt an. Soweit ich gesehen habe, wird hier auch nicht SET NAMES oder SET CHARACTER SET genutzt, also verursachen die Defaults so erstmal auch auch keine Anzeige-Probleme.
Dann wird es wohl so sein, dass das DBMS dein UTF-8 als Latin1 interpretiert. Das sieht auf den ersten Blick problemlos aus, aber der phpMyAdmin dürfte dann nicht mitspielen, weil er korrekt UTF-8 mit dem DBMS spricht, dann aber das vom DBMS angenommene Latin1 nochmal nach UTF-8 kodiert, woraufhin du doppelt-UTF-8-kodierte Zeichen hast. Oder wenn er Latin1 verwendet, geht er davon aus, solches zu bekommen und kein UTF-8, was auch zu Murks in der Anzeige führt.
In dieser neuen DB im UTF8 habe ich eine View erstellt (damit die bereits vorhandenen Logins genutzt werden können) und nur bei der Anzeige der Daten aus dieser View, also die Daten die von DB1 kommen, werden die Umlaute nicht korrekt dargestellt.
Zunächst ist CONVERT(... USING ...) gedacht um Binär-Inhalte als Text zu interpretieren. Also wenn du ein BLOB-Feld hättest und da jemand Text abgelegt hat, dann wird der als die Bytes abgelegt, die MySQL übegeben bekommt. Um ihn als Text zu verwenden, muss dessen Kodierung bekannt sein, deshalb ein USING. Wenn du allerdings Text mit bekannter Kodierung so behandelst, passiert irgendwas, was ich erst durch Versuche rausfinden müsste.
Weil du im UTF-8-Teil keine Zeichenkodierung auf der Verbindung angegeben hast und MySQL dein von Latin1 ausging, hast du nun Murks in den Feldern stehen. Diesen Murks umkodieren zu wollen macht ihn nicht besser.
Was muss ich denn jetzt tun, damit die Anzeige korrigiert wird?
Den Verbindungsaufbau in diesem Modul suchen und nochmal explizit das Character Set setzen?
Ich gehe mal davon aus, dass der alte Teil unangefasst auf Latin1 bleiben und der neue UTF-8 verwenden soll. Dann müsstest du erst einmal mit einem Programm, das korrekt mit MySQL spricht (phpMyAdmin zum Beispiel) alle Nicht-ASCII-Zeichen (Umlaute etc.) korrigieren. Dann muss der neue Teil die Verbindungskodierung UTF-8 bei jedem Verbindungsaufbau aushandeln. Der alte sollte es mit seinem Latin1 auch tun, sonst kann ein ähnliches Problem auftreten, wenn der Default-Wert mal geändert wird. Konvertierfunktionen brauchst du nicht, das kann MySQL von selbst, wenn es zu den Verbindungsangaben (oder Defaultwerten) die passend kodierten Daten bekommt.
Wenn es zu viele Daten im neuen Teil sind, dann ist händisches Korrigieren nicht praktikabel. Dann müsste es in deinem Fall gehen, einen Dump als Latin1 ausgeben zu lassen und diesen unverändert als UTF-8 zu importieren. Anschließend muss phpMyAdmin alles korrekt anzeigen. Vor solchen Versuchen bitte Kopien der Tabellen/Datenbank anlegen (mit PMAs Kopierfunktion unter "Operationen"), sonst geht vielleicht noch mehr kaputt.
dedlfix.
Auge