Innanzitutto dovrei dire che non uso MySQL ma conosco i driver ODBC. In ODBC ci sono diverse API per unicode e ansi. Le API ansi terminano con A e le API unicode con W (ad es. SQLPrepareA e SQLPrepareW). Le API ansi accettano byte/ottetti per stringhe di caratteri e quindi possono gestire solo chrs 0-255. Le API unicode accettano SQLWCHAR che sono codepoint Unicode codificati UCS-2 a 2 byte (le versioni più recenti di MS SQL Server possono gestire stringhe codificate UTF16) e quindi possono gestire circa i primi 65000 codepoint in Unicode.
Quindi, se hai bisogno di archiviare dati Unicode, non hai scelta quale driver usare.
Non lascerei che i commenti sulla velocità di Carnangel ti scoraggiassero usando il driver unicode e in ogni caso i suoi commenti non includono alcun fatto. Potrebbe riferirsi a:
Se memorizzi dati Unicode in MySQL, saranno codificati UTF-8 e trasferiti sulla tua rete come UTF-8. All'estremità del client, il driver ODBC dovrà convertire i dati codificati UTF-8 in UCS-2 poiché questo è ciò di cui ODBC ha bisogno. Ovviamente vale il contrario.
Se scrivi un'applicazione ANSI ODBC (ovvero una che utilizza l'apis ansi ODBC) con un driver ODBC unicode, il gestore driver ODBC dovrà convertire l'UCS-2 il driver ritorna a 8 bit (con perdita) e convertire gli 8 bit dati trasmessi al conducente a UCS-2. Quindi non farlo.
In questi giorni sarei sorpreso se qualcuno utilizza ancora i driver ANSI ODBC.
