problème d'encodage de base de données? Les guillemets doubles et simples affichés w/points d'interrogation

Question

ancien serveur db = MySQL v4.0.21 Nouveau serveur db = MySQL v5.0.45

Je me déplace une application vers un nouveau serveur, et je copiais sur la base de données.

L'application envoie un ordre du jour pour la journée et chaque fois qu'il ya doubles & guillemets simples " », ils apparaissent comme des points d'interrogation?

Comes comme ça sur le serveur, il a été déplacé à ?The Horror of Race: HBO?s True Blood?

Voici ce qu'il ressemble à l'application du serveur d'origine a été construit sur: “The Horror of Race: HBO’s True Blood”

Capture d'écran de base de données w/i phpMyAdmin http://grab.by/2EsU (serveur d'origine MySQL v4.0.21) et http://grab.by/2EtN (nouveau serveur MySQL 5.0.45)

Capture d'écran de la table les données sont stockées dans: http://grab.by/2Et2 (il arrive que w/i la colonne du corps)

Capture d'écran de données dans une nouvelle table de serveur: (vous remarquerez les points d'interrogation) http://grab.by/2Etb

Capture d'écran de données dans le tableau du serveur d'origine: http://grab.by/2Etl

l'application est construite w/PHP, et il imprime le corps comme nl2br($body);

la chaîne est stockée w/i le corps $ vari avant d'être inséré dans la table de db, comme ceci: $body=addslashes($_POST['body']);

Toute aide pour expliquer pourquoi il affiche le? marques à la place de guillemets doubles et simples, serait utile - très apprécié.

Answer 1

Ceci est probablement dû à une différence dans les paramètres de codage de 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) 

Voir si vous voyez une différence là-bas. 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 assurer que les paramètres de codage de caractères pour les colonnes: faire SHOW CREATE TABLE <table-name> et vérifier si les jeux de caractères sont toujours les mêmes au niveau de la colonne mysql>

EDIT Sinon, comme Martin a souligné dans le commentaires, vous pourriez avoir affaire à un vidage SQL qui est codé dans un encodage que vous n'avez pas anticipé. Voici quelques informations à 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 en utilisant un outil comme iconv (http://www.gnu.org/software/libiconv/documentation/libiconv/iconv.1.html)

Answer 2

Pour être honnête, je pense qu'il y a une autre pièce du puzzle qui manque pour cette description du problème car tout semble valide . Il existe deux autres fonctions que vous pouvez utiliser pour empêcher l'injection SQL qui peut résoudre votre problème étrange.

$var=addslashes(htmlspeicalchars($var,ENT_QUOTES)); 

ou une meilleure approche:

$var=mysql_real_escape_string($var);