Hoe vermijd ik ongewenste tekens/vuilnistekens bij het lezen van gegevens uit meerdere talen?

De Gujarati begint રેલવે , juist? En de Malyalam begint നേപ , juist? En de Engelsen hadden Bureau’s moeten bevatten .

Dit is het klassieke geval van

De bytes die je in de client hebt, zijn correct gecodeerd in utf8. (Bureau is gecodeerd in de Ascii/latin1 subset van utf8; maar ’ is niet de ascii-apostrof.)
Je hebt verbinding gemaakt met SET NAMES latin1 (of set_charset('latin1') of ...), waarschijnlijk standaard. (Het had utf8 moeten zijn .)
De kolom in de tabel is verklaard CHARACTER SET latin1 . (Of misschien is het overgenomen van de tabel/database.) (Het had utf8 moeten zijn .)

De oplossing voor de gegevens is een "2-staps ALTER".

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

waar de lengtes groot genoeg zijn en de andere "..." hebben wat anders (NOT NULL , enz.) stond al op de kolom.

Helaas, als je veel kolommen hebt om mee te werken, zijn er veel ALTERs nodig. U kunt (moet) MODIFY alle benodigde kolommen voor VARBINARY voor een enkele tafel in een paar ALTERs .

De fix voor de code is om utf8 tot stand te brengen als de verbinding; dit hangt af van de api die in PHP wordt gebruikt. De ALTERs zal de kolomdefinitie veranderen.

Bewerken

Je hebt VARCHAR met de verkeerde CHARACTER SET . Daarom zie je Mojibake als àª°à«‡àª² . De meeste conversietechnieken proberen àª°à«‡àª² . te behouden , maar dat is niet wat je nodig hebt. In plaats daarvan, een stap zetten naar VARBINARY behoudt de bits en negeert de oude definitie van de bits die latin1-gecodeerde karakters vertegenwoordigen. De tweede stap bewaart opnieuw de bits, maar beweert nu dat ze utf8-tekens vertegenwoordigen.