Първо трябва да кажа, че не използвам MySQL, но знам за ODBC драйверите. В ODBC има различни API за unicode и ansi. Ansi API завършват на A и unicode API завършват на W (напр. SQLPrepareA и SQLPrepareW). Ansi API приемат байтове/октети за символни низове и следователно могат да обработват само chrs 0-255. Приложните програмни интерфейси (API) на unicode приемат SQLWCHAR, които са 2 байтови UCS-2 кодирани кодови точки на Unicode (по-новите версии на MS SQL Server могат да обработват низове, кодирани с UTF16) и така могат да обработват приблизително първите 65 000 кодови точки в unicode.
Така че, ако трябва да съхранявате Unicode данни, нямате избор кой драйвер да използвате.
Не бих позволил на коментарите за скоростта от Carnangel да ви отблъснат да използвате драйвера на unicode и във всеки случай коментарите му не включват никакви факти. Той може да има предвид:
Ако съхранявате unicode данни в MySQL, те ще бъдат кодирани в UTF-8 и прехвърлени през вашата мрежа като UTF-8. В края на клиента ODBC драйверът ще трябва да преобразува UTF-8 кодираните данни в UCS-2, тъй като това е, от което се нуждае ODBC. Очевидно важи обратното.
Ако напишете ANSI ODBC приложение (това е такова, което използва ansi ODBC apis) с unicode ODBC драйвер, тогава мениджърът на ODBC драйвери ще трябва да преобразува UCS-2, драйверът се връща в 8-битов (загуба) и да преобразува 8-битовия данни, които предавате на драйвера към UCS-2. Така че не правете това.
Тези дни ще се изненадам, ако някой все още използва ANSI ODBC драйвери.
