nicht angemeldet
Tach!
Ich glaube, wir kommen der Sache jetzt etwas näher, denn ich habe jetzt wiederholt nachgeschaut, dass er die sowohl die tatsächliche Tabelle in latin1 als auch die View korrekt anzeigt.
Aber der phpmyadmin zeigt nicht die Werte der anderen Tabellen korrekt an.
So wird z.B. Mindesthöhe anstatt Mindesthöhe angezeigt.
Du machst in der View irgendwas mit Konvertierung. Das wäre nicht notwendig, wenn die Daten korrekt im DBMS drin wären. Du versuchst damit nur die durch die nicht richtig ausgehandelte Verbindungskodierung kaputten Daten zu reparieren und das klappt wohl nicht in allen Situationen. Ich hab allerdings keine Erfahrung und keine Muße nachzuvollziehen, was da genau abläuft. Jedefalls ist es kaputt so wie es jetzt ist, und mein Vorachlag ist, es grundlegend zu reparieren anstatt mit expliziten Konvertierungen irgendwas richten zu wollen.
Das bedeutet jetzt, dass alle Tabellen in dern neuen DB in UTF8 angelegt sind, die View aber beim Erstellen dennoch wieder in Latin1 erstellt wurde?
Nein und nein. Die Kodierungsangabe der Felder in der neuen Tabelle mag UTF-8 sein. Der Inhalt ist es aber nicht, weil du UTF-8 als Latin1 deklariert (Default-Einstellung der Verbindung) geliefert hast. Wenn man sich die Bytes in der Tabelle anschauen könnte, müsste man doppelt kodiertes UTF-8 sehen.
Die View hat nichts mit der Zeichenkodierung zu tun. Sie ist nur ein abgespeichertes SELECT-Statement, also Code ohne irgendwelche Daten, für die eine Kodierung relevant wäre. (Sollte aber (für ein WHERE zum Beispiel) ein fester Text mit Nicht-ASCII-Zeichen im Code enthalten sein, so wird MySQL diesen gemäß der Verbindungskodierung interpretieren. Alles weitere ist für uns Außenstehende nicht weiter relevant. Wenn dieser Text beim Ausführen der View mit konkreten Daten in Feldern verglichen wird, ist es MySQLs Aufgabe, notwendige Konvertierungen vorzunehmen. - Unsere Aufgabe beim Arbeiten mit MySQL ist lediglich, die Feldkodierungen zu konfigurieren und beim Verbindungsaufbau die zu verwendende Kodierung auszuhandeln.)
Die Lösung wäre, dass ich beim Erstellen der View sicherstelle, dass diese in UTF8 angelegt wird?
Nein, die Lösung wäre, auf explizite Konvertierungen zu verzichten, die Daten in der neuen DB zu korrigieren und beim Verbindungsaufbau die gewünschte Kodierung auszuhandeln. Und das ist die, die die Anwendung benötigt, also die, mit der die Daten gesendet und erwartet werden. Die alte also Latin1, die neue UTF-8. MySQL kümmert sich selbst um die notwendigen Konvertierungen.
Mehr neues hab ich an dieser Stelle nicht zu sagen, ich wiederhole mich ja jetzt schon dauernd ;)
Das Korrigieren der Daten in der neuen DB kann wie folgt ablaufen: Einen Dump erstellen und zu diesem als Parameter mitgeben, dass er Latin1 sein soll. Am besten an der Kommandozeile, nicht mit irgendwelchen Tools. Diesen Dump unverändert nehmen und importieren, dabei aber sagen, dass er UTF-8 ist. Damit sollte sich die doppelte UTF-8-Kodierung auflösen.
dedlfix.
Auge