проблема с кодировкой базы данных? Двойные и одинарные кавычки отображаются с вопросительными знаками

Question

Старый сервер db = MySQL v4.0.21 Новый сервер db = MySQL v5.0.45

Я перемещаю приложение на новый сервер и копирую базу данных.

Приложение отправляет повестку дня на день, и всякий раз, когда есть двойные и одинарные кавычки "', они отображаются в виде вопросительных знаков?

Появляется на сервере так, как было перемещено на ?The Horror of Race: HBO?s True Blood?

Вот как выглядит исходное серверное приложение, на котором было построено: “The Horror of Race: HBO’s True Blood”

Снимок экрана базы данных с phpmyadmin http://grab.by/2EsU (исходный сервер mysql v4.0.21) и http://grab.by/2EtN (новый сервер mysql 5.0.45)

Снимок экрана таблицы, в которой хранятся данные: http://grab.by/2Et2 (это происходит только в столбце тела)

Снимок экрана данных в новой таблице сервера: http://grab.by/2Etb (вы заметите вопросительные знаки?)

Снимок экрана данных в исходной таблице сервера: http://grab.by/2Etl

Приложение построено с PHP и печатает тело как nl2br($body);

Строка сохраняется в переменной $ body перед вставкой в ​​таблицу db, например: $body=addslashes($_POST['body']);

Любая помощь в том, почему он отображает? знаки в месте двойных и одинарных кавычек, было бы полезно - высоко ценится.

Answer 1

Это скорее всего из-за разницы в настройках кодировки символов. Это может быть в нескольких местах. Я бы посоветовал вам войти на оба сервера и сделать:

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)

Посмотрите, видите ли вы там разницу. Например, если набор символов для соединения по умолчанию отличается для нового сервера, вы можете получить эти результаты.

Вы также должны убедиться в настройках кодировки символов для столбцов: выполните SHOW CREATE TABLE <table-name> и проверьте, остаются ли наборы символов на уровне столбцов. MySQL>

EDIT В качестве альтернативы, как указал Мартин в комментариях, вы можете иметь дело с дампом SQL, который закодирован в кодировке, которую вы не ожидали. Вот еще немного информации об этом: http://dev.mysql.com/doc/refman/5.1/en/mysqldump.html#option_mysqldump_default-character-set. В этом случае вы можете попытаться перекодировать файл дампа, используя такой инструмент, как iconv (http://www.gnu.org/software/libiconv/documentation/libiconv/iconv.1.html)

Answer 2

Честно говоря, я думаю, что для описания проблемы не хватает другой части головоломки, потому что все выглядит корректно. Есть две другие функции, которые вы можете использовать для предотвращения SQL-инъекций, которые могут решить вашу странную проблему.

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

или лучший подход:

$var=mysql_real_escape_string($var);