Dit is hoogstwaarschijnlijk te wijten aan een verschil in de instellingen voor tekencodering. Dit kan op een aantal plaatsen van kracht zijn. Ik raad je aan om op beide servers in te loggen en het volgende te doen:
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)
Kijk of je daar verschil ziet. Als de standaard verbindingstekenset bijvoorbeeld anders is voor de nieuwe server, kunt u deze resultaten krijgen.
Je moet ook zorgen voor de karaktercoderingsinstellingen voor de kolommen:doe een SHOW CREATE TABLE <table-name> en controleer of de tekensets nog steeds hetzelfde zijn op kolomniveaumysql>
EDITAls alternatief, zoals Martin in de opmerkingen aangaf, zou je te maken kunnen hebben met een SQL-dump die is gecodeerd in een codering die je niet had verwacht. Hier is wat meer informatie over:http://dev.mysql.com/doc/refman/5.1/en/mysqldump.html#option_mysqldump_default-character-set . In dit geval kunt u proberen het dumpbestand opnieuw te coderen met een tool zoals iconv (http://www.gnu.org/software/libiconv/documentation/libiconv/iconv.1.html )