Bij gebruik van Entity Framework met MySQL worden Unicode-tekens vervangen door basistekens

MySQL maakt het mogelijk om verschillende aspecten van de client-servercommunicatie te configureren (volgens de 10.4 Verbindingstekensets en -sorteringen documentatie):

• Bron (d.w.z. client) codering:character_set_client
• Bestemmingscodering (d.w.z. server):character_set_connection
• Geretourneerde gegevens en metagegevens:character_set_results

Ik vermoed dat wordt aangenomen dat de broncodering, afkomstig van een Microsoft-technologie, UTF-16 Little Endian is.

Wat de andere twee betreft, de Connector/ NET Connection-String Opties Referentie documentatie vermeldt:

De verbinding met MySQL moet worden verteld dat de doelcodering UTF-8 is (wat uw MySQL-kolommen gebruiken). MySQL gaat er momenteel van uit dat u niet-Unicode-tekenreeksen verzendt, en doet in feite hetzelfde als converteren naar VARCHAR in SQL Server, ervan uitgaande dat de codepagina die is opgegeven door de standaardsortering van de huidige database 1252 is (Windows Code Page 1252 wordt gewoonlijk "ANSI ", zelfs als dat een technisch . is onjuiste naam).

Het volgende toont het gedrag in SQL Server door de tekenreeks niet vooraf te laten gaan door een hoofdletter "N":

SELECT 'α'; -- Database's default Collation = Latin1_General_100_CI_AS_SC
-- a

SELECT 'α'; -- Database's default Collation = Hebrew_100_BIN2
-- ?

Probeer het volgende om dit op te lossen:

1. De eerste poging zou moeten zijn om het volgende aan uw verbindingsreeks toe te voegen om tekengegevens als UTF-8 naar MySQL te verzenden (dit zou gewoon character_set_connection moeten instellen ):

   CharSet=utf8;
   

   Voorbeeld van volledige verbindingsreeks hier

2. De tweede poging zou moeten zijn om bij de eerste verbinding een SQL-opdracht te verzenden om de variabele op sessieniveau in te stellen die de bestemmingscodering bestuurt:

   SET character_set_connection = utf8;
   

Zie het volgende voor meer informatie:

MySQL Charset/Collate

Volgens de sectie "utf8 Collations" van die pagina zou het veel beter zijn om utf8_unicode_ci te gebruiken voor de sortering in plaats van utf8_general_ci (voor alle duidelijkheid, deze aanbeveling heeft niets te maken met het probleem van tekenconversie dat hier wordt behandeld).

PS Deze vraag/antwoord heeft een begeleidende vraag en antwoord op DBA.StackExhange:

Waarom krijg ik onjuiste tekens bij het decoderen van een Base64-tekenreeks naar NVARCHAR in SQL Server?