Podczas korzystania z Entity Framework z MySQL znaki Unicode są zastępowane znakami podstawowymi

MySQL pozwala na konfigurację kilku aspektów komunikacji klient-serwer (zgodnie z 10.4 Zestawy znaków połączenia i sortowanie dokumentacja):

Kodowanie źródła (tj. klienta):character_set_client
Kodowanie miejsca docelowego (tj. serwera):character_set_connection
Zwrócone dane i metadane:character_set_results

Domyślam się, że zakłada się, iż kodowanie źródłowe, pochodzące z technologii Microsoftu, to UTF-16 Little Endian.

Jeśli chodzi o pozostałe dwa, Łącznik/ Opis opcji parametrów połączenia NET stany dokumentacji:

Połączenie z MySQL musi zostać poinformowane, że docelowe kodowanie to UTF-8 (którego używają Twoje kolumny MySQL). MySQL obecnie zakłada, że wysyłasz ciągi znaków innych niż Unicode, w efekcie robiąc to samo, co konwersja do VARCHAR w programie SQL Server, zakładając, że strona kodowa określona przez domyślne sortowanie bieżącej bazy danych to 1252 (strona kodowa systemu Windows 1252 jest powszechnie określana jako „ANSI ”, nawet jeśli jest to technicznie niedokładna nazwa).

Poniżej przedstawiono zachowanie w SQL Server bez poprzedzania ciągu wielkimi literami „N”:

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

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

Aby to naprawić, spróbuj wykonać następujące czynności:

Pierwszą próbą powinno być dodanie następujących znaków do ciągu połączenia, aby wysłać dane znakowe jako UTF-8 do MySQL (powinno to po prostu ustawić character_set_connection ):
```
CharSet=utf8;
```
Przykład pełnego ciągu połączenia tutaj
Druga próba powinna polegać na wysłaniu polecenia SQL przy początkowym połączeniu, aby ustawić zmienną poziomu sesji, która kontroluje docelowe kodowanie:
```
SET character_set_connection = utf8;
```

Aby uzyskać więcej informacji, zobacz następujące:

MySQL Charset/Collate

Zgodnie z sekcją „Układanie utf8” tej strony, znacznie lepiej byłoby użyć utf8_unicode_ci dla sortowania zamiast utf8_general_ci (żeby było jasne, to zalecenie nie ma nic wspólnego z omawianym tutaj problemem konwersji postaci).

PS To pytanie/odpowiedź ma towarzyszące pytania i odpowiedzi na DBA.StackExhange:

Dlaczego otrzymuję nieprawidłowe znaki podczas dekodowania ciągu Base64 do NVARCHAR w SQL Server?