Cela est probablement dû à une différence dans les paramètres d'encodage des caractères. Cela peut être en vigueur dans quelques endroits. Je vous conseille de vous connecter aux deux serveurs et de faire :
mysql> show variables like '%character%';
+--------------------------+-----------------------------------------------+
| Variable_name | Value |
+--------------------------+-----------------------------------------------+
| character_set_client | latin1 |
| character_set_connection | latin1 |
| character_set_database | latin1 |
| character_set_filesystem | binary |
| character_set_results | latin1 |
| character_set_server | latin1 |
| character_set_system | utf8 |
| character_sets_dir | D:\Servers\MySQL\MySQL_5_1_36\share\charsets\ |
+--------------------------+-----------------------------------------------+
8 rows in set (0.00 sec)
Voyez si vous y voyez une différence. Par exemple, si le jeu de caractères de connexion par défaut est différent pour le nouveau serveur, vous pouvez obtenir ces résultats.
Vous devez également vous assurer des paramètres d'encodage des caractères pour les colonnes :faites un SHOW CREATE TABLE <table-name> et vérifiez si les jeux de caractères sont toujours les mêmes au niveau de la colonne mysql>
EDITAlternativement, comme Martin l'a souligné dans les commentaires, vous pourriez avoir affaire à un vidage SQL encodé dans un encodage que vous n'aviez pas prévu. Voici quelques informations supplémentaires à ce sujet :http ://dev.mysql.com/doc/refman/5.1/en/mysqldump.html#option_mysqldump_default-character-set . Dans ce cas, vous pouvez essayer de ré-encoder le fichier de vidage à l'aide d'un outil comme iconv (http://www.gnu.org/software/libiconv/documentation/libiconv/iconv.1.html )
