For det første vil jeg sige, at jeg ikke bruger MySQL, men jeg kender til ODBC-drivere. I ODBC er der forskellige API'er til unicode og ansi. Ansi API'erne ender på A og unicode API'erne ender på W (f.eks. SQLPrepareA og SQLPrepareW). Ansi API'erne accepterer bytes/oktetter for tegnstrenge og kan derfor kun håndtere chrs 0-255. Unicode-API'erne accepterer SQLWCHAR'er, som er 2 byte UCS-2-kodede unicode-kodepunkter (nyere MS SQL Server-versioner kan håndtere UTF16-kodede strenge) og kan således håndtere cirka de første 65.000 kodepunkter i unicode.
Så hvis du har brug for at gemme unicode-data, har du ikke noget valg, hvilken driver du skal bruge.
Jeg ville ikke lade kommentarerne om hastighed fra Carnangel afskrække dig fra at bruge unicode-driveren, og under alle omstændigheder indeholder hans kommentarer ingen fakta. Han henviser muligvis til:
Hvis du gemmer unicode-data i MySQL, bliver det UTF-8-kodet og overført over dit netværk som UTF-8. I klientenden bliver ODBC-driveren nødt til at konvertere de UTF-8-kodede data til UCS-2, da dette er, hvad ODBC har brug for. Det omvendte gælder naturligvis.
Hvis du skriver en ANSI ODBC-applikation (dvs. en, der bruger ansi ODBC-apis) med en unicode ODBC-driver, bliver ODBC-driveradministratoren nødt til at konvertere UCS-2, driveren vender tilbage til 8 bit (tab) og konverterer 8-bit. data du videregiver til chaufføren til UCS-2. Så gør det ikke.
I disse dage ville jeg blive overrasket, hvis nogen stadig bruger ANSI ODBC-drivere.