Po pierwsze powinienem powiedzieć, że nie używam MySQL, ale znam się na sterownikach ODBC. W ODBC istnieją różne API dla unicode i ansi. Interfejsy API ansi kończą się na A, a interfejsy API Unicode na W (np. SQLPrepareA i SQLPrepareW). Interfejsy API ansi akceptują bajty/oktety dla ciągów znaków i dlatego obsługują tylko chrs 0-255. Unicode API akceptują SQLWCHARs, które są 2 bajtowymi punktami kodowymi Unicode zakodowanymi w UCS-2 (nowsze wersje MS SQL Server mogą obsługiwać łańcuchy zakodowane w UTF16), a więc mogą obsłużyć około 65000 pierwszych punktów kodowych w Unicode.
Więc jeśli potrzebujesz przechowywać dane Unicode, nie masz wyboru, którego sterownika użyć.
Nie pozwolę, aby komentarze Carnangela dotyczące prędkości zniechęciły Cię do korzystania ze sterownika Unicode, a w każdym razie jego komentarze nie zawierają żadnych faktów. Może odnosić się do:
Jeśli przechowujesz dane Unicode w MySQL, będą one zakodowane w UTF-8 i przesłane przez Twoją sieć jako UTF-8. Po stronie klienta sterownik ODBC będzie musiał przekonwertować dane zakodowane w UTF-8 na UCS-2, ponieważ tego potrzebuje ODBC. Oczywiście ma to zastosowanie na odwrót.
Jeśli napiszesz aplikację ANSI ODBC (czyli taką, która używa interfejsu API ANSI ODBC) ze sterownikiem ODBC Unicode, to menedżer ODBC Driver będzie musiał przekonwertować UCS-2, sterownik powróci do 8-bitowego (stratnego) i przekonwertuje 8-bitowy dane, które przekazujesz kierowcy do UCS-2. Więc nie rób tego.
W dzisiejszych czasach zdziwiłbym się, gdyby ktoś nadal używał sterowników ANSI ODBC.
