Pertama saya harus mengatakan bahwa saya tidak menggunakan MySQL tetapi saya tahu tentang Driver ODBC. Di ODBC ada API yang berbeda untuk unicode dan ansi. API ansi diakhiri dengan A dan API unicode diakhiri dengan W (mis., SQLPrepareA dan SQLPrepareW). API ansi menerima byte/oktet untuk string karakter dan karenanya hanya dapat menangani chrs 0-255. API unicode menerima SQLWCHARs yang merupakan 2 byte UCS-2 encoded unicode codepoints (versi MS SQL Server yang lebih baru dapat menangani string yang disandikan UTF16) dan juga dapat menangani sekitar 65000 codepoint pertama dalam unicode.
Jadi, jika Anda perlu menyimpan data unicode, Anda tidak punya pilihan driver mana yang akan digunakan.
Saya tidak akan membiarkan komentar tentang kecepatan dari Carnangel menunda Anda menggunakan driver unicode dan dalam hal apa pun komentarnya tidak menyertakan fakta apa pun. Dia mungkin mengacu pada:
Jika Anda menyimpan data unicode di MySQL, itu akan dikodekan UTF-8 dan ditransfer melalui jaringan Anda sebagai UTF-8. Di ujung klien, driver ODBC harus mengubah data yang disandikan UTF-8 menjadi UCS-2 karena inilah yang dibutuhkan ODBC. Jelas berlaku sebaliknya.
Jika Anda menulis aplikasi ANSI ODBC (yaitu yang menggunakan apis ODBC ansi) dengan driver ODBC unicode maka manajer Driver ODBC harus mengubah UCS-2 driver kembali ke 8 bit (lossy) dan mengubah 8 bit data yang Anda berikan ke driver ke UCS-2. Jadi jangan lakukan itu.
Hari-hari ini saya akan terkejut jika ada yang masih menggunakan driver ANSI ODBC.
