Wie vermeide ich Junk-/Müllzeichen beim Lesen von Daten aus mehreren Sprachen?

Der Gujarati startet રેલવે , Korrekt? Und das Malyalam beginnt നേപ , Korrekt? Und die Engländer hätten Bureau’s einschließen sollen .

Dies ist der klassische Fall von

• Die Bytes, die Sie im Client haben, sind korrekt in utf8 codiert. (Bureau ist in der Ascii/latin1-Untergruppe von utf8 kodiert; sondern ’ ist nicht das ASCII-Apostroph.)
• Sie haben sich mit SET NAMES latin1 verbunden (oder set_charset('latin1') oder ...), wahrscheinlich standardmäßig. (Es sollte utf8 gewesen sein .)
• Die Spalte in der Tabelle wurde als CHARACTER SET latin1 deklariert . (Oder möglicherweise wurde es von der Tabelle/Datenbank geerbt.) (Es hätte utf8 sein sollen .)

Der Fix für die Daten ist ein "2-stufiges ALTER".

ALTER TABLE Tbl MODIFY COLUMN col VARBINARY(...) ...;
ALTER TABLE Tbl MODIFY COLUMN col VARCHAR(...) ... CHARACTER SET utf8 ...;

wobei die Längen groß genug sind und die anderen "..." was auch immer haben (NOT NULL , usw.) war bereits auf der Säule.

Wenn Sie mit vielen Spalten arbeiten müssen, sind leider viele ALTERs erforderlich. Sie können (sollten) MODIFY alle notwendigen Spalten zu VARBINARY für eine einzelne Tabelle in einem Paar ALTERs .

Die Korrektur für den Code soll utf8 als Verbindung aufbauen; Dies hängt von der in PHP verwendeten API ab. Die ALTERs ändert die Spaltendefinition.

Bearbeiten

Sie haben VARCHAR mit dem falschen CHARACTER SET . Daher sehen Sie Mojibake wie રેલ . Die meisten Konvertierungstechniken versuchen, રેલ beizubehalten , aber das ist nicht das, was Sie brauchen. Machen Sie stattdessen einen Schritt zu VARBINARY behält die Bits bei, während die alte Definition der Bits ignoriert wird, die latin1-codierte Zeichen darstellen. Der zweite Schritt behält die Bits wieder bei, behauptet aber jetzt, dass sie utf8-Zeichen darstellen.