Tout d'abord, je dois dire que je n'utilise pas MySQL mais que je connais les pilotes ODBC. Dans ODBC, il existe différentes API pour unicode et ansi. Les API ansi se terminent par A et les API unicode se terminent par W (par exemple, SQLPrepareA et SQLPrepareW). Les API ansi acceptent les octets/octets pour les chaînes de caractères et ne peuvent donc gérer que les chrs 0-255. Les API Unicode acceptent les SQLWCHAR qui sont des points de code Unicode encodés UCS-2 de 2 octets (les nouvelles versions de MS SQL Server peuvent gérer les chaînes encodées UTF16) et peuvent donc gérer environ les 65 000 premiers points de code en Unicode.
Donc, si vous avez besoin de stocker des données Unicode, vous n'avez pas le choix du pilote à utiliser.
Je ne laisserais pas les commentaires sur la vitesse de Carnangel vous dissuader d'utiliser le pilote unicode et en tout cas ses commentaires n'incluent aucun fait. Il peut faire référence à :
Si vous stockez des données Unicode dans MySQL, elles seront encodées en UTF-8 et transférées sur votre réseau en UTF-8. Du côté client, le pilote ODBC devra convertir les données codées UTF-8 en UCS-2 car c'est ce dont ODBC a besoin. Évidemment, l'inverse s'applique.
Si vous écrivez une application ANSI ODBC (c'est-à-dire une application qui utilise l'apis ODBC ansi) avec un pilote ODBC unicode, le gestionnaire de pilotes ODBC devra convertir l'UCS-2, le pilote revient en 8 bits (avec perte) et convertir le 8 bits données que vous transmettez au pilote à UCS-2. Alors ne fais pas ça.
Ces jours-ci, je serais surpris si quelqu'un utilise encore les pilotes ANSI ODBC.
