nicht angemeldet
Hi!
das würde bedeuten, die daten sind schon falsch in die Datenbank gekommen, was meine verfälschten sonderzeichen erklärt.
Ja.
Beim Abfragen macht es daraus wieder Latin1 und übergibt es dem Client, woraufhin dieser davon ausgeht, die Bytes seien UTF-8.
gut, das geht dann aber nur in dieser gesonderten konstellation, mein workbench client arbeitet ja mit utf-8. du meinst dadurch fällt es den anderen nicht auf, dass die codierung falsch ist ?
(Deine) Workbench handelt im Gegensatz zu den anderen Pappnasen explizit eine Verbindungskodierung aus. Es nützt dir nun nichts, wenn es irgendwo generell auf Latin1 umzukonfigurieren wäre, denn dann ginge die Workbench sicherlich auch davon aus, dass es nun Latin1-Zeichen gäbe, was im Ergebnis nichts ändert. Aber, Trick 17: SET NAMES latin1; SELECT ...; So wie es aussieht, wertet die Workbench das SET NAMES nicht aus. Damit erreichst du nun, dass der MySQL-Server aus der doppelten UTF-8-Kodierung der Felddaten nun noch eine einfache macht, weil es denkt, es solle nun Latin1 liefern. Die Workbench hingegen geht weiterhin davon aus, UTF-8 zu bekommen, und so stimmt das ja auch. Damit hast du nun den gleichen Fehler beim Abfragen wie die fehlerhaften Programme der anderen.
ich schreibe gar keine daten rein, ich kann/solll die daten nur auslesen. das mache ich dann am ende über oracle, aber ich will zum besseren vergleich das auch parallel mit der workbench machen.
Das heißt, Oracle fragt über eine ODBC-Verbindung Daten aus MySQL ab. Dann musst du Latin1 als Verbindungskodierung konfigurieren oder SET NAMES latin1; als erstes Statement senden und dann UTF-8-Daten erwarten.
Lo!