Проблемы с кодированием в PHP / MySQL - PullRequest
1 голос
/ 13 июня 2009

РЕДАКТИРОВАТЬ: После отзыва из моего исходного сообщения, я изменил текст, чтобы прояснить мою проблему.

У меня следующий запрос (псевдокод):

$conn = mysql_connect('localhost', 'mysql_user', 'mysql_password');
mysql_query("SET NAMES 'utf8'; COLLATE='utf8_danish_ci';");

mysql_query("SELECT id FROM myTable WHERE name = 'Fióre`s måløye'", $conn);

Возвращает 0 строк.

В моем лог-файле я вижу это:

255 Connect     root@localhost on 
255 Query       SET NAMES 'utf8'; COLLATE='utf8_danish_ci'
255 Init DB     norwegianfashion
255 Query       SELECT id FROM myTable WHERE name = 'Fióre`s måløye'
255 Quit
  • Если я запускаю запрос непосредственно в phpMyAdmin, я получаю результат.
  • Таблица кодировки: UTF-8
  • Кодировка HTML-страницы: UTF-8
  • Я могу добавить записи (из формы ввода), где в именах используются акценты (например, "Fióre`s Häßelberg")
  • Я могу читать записи с ударением при использовании -> "name LIKE '$ labelName%'"
  • Информация в БД выглядит нормально

Понятия не имею, почему я не могу выбрать строки, в имени которых есть символы ударения.

Я действительно надеюсь, что кто-то может мне помочь.

ОБНОВЛЕНИЕ 1: Я пришел к компромиссу. Я буду конвертировать акценты с htmlentities при хранении данных и html_entity_decode при извлечении данных из БД. Кажется, это работает.

Единственный недостаток, который я пока вижу, это то, что я не могу читать имена в открытом тексте с помощью phpMySQL.

Ответы [ 6 ]

4 голосов
/ 13 июня 2009

Я думаю, вам лучше вернуть $result, чем $this->query.

Кроме того, вы должны знать о SQL-инъекции и рассмотреть возможность использования mysql_real_escape_string или подготовленных операторов для защиты вас от таких атак. addslashes не является надлежащей защитой.

2 голосов
/ 13 июня 2009

Как показывают другие ответы, это очень похоже на проблему кодирования. Я предлагаю включить ведение журнала запросов (http://dev.mysql.com/doc/refman/5.1/en/query-log.html), поскольку оно может показать вам, что база данных действительно получает.

UPDATE : Я наконец-то нашел страницу, объясняющую грязные детали PHP и UTF-8 (http://www.phpwact.org/php/i18n/charsets).. Также обязательно прочитайте это (http://niwo.mnsys.org/saved/~flavell/charset/form-i18n.html), чтобы понять, как получить правильные данные, возвращаемые из сообщений формы.

2 голосов
/ 13 июня 2009

Попробуйте этот запрос. Если вы получаете результаты, то это проблема с символом обратной галочки в запросе

SELECT * FROM sl_label WHERE name Like 'Church%'
0 голосов
/ 15 июня 2009

Я смотрю на эту строку

mysql_query("SET NAMES 'utf8'; COLLATE='utf8_danish_ci';");

и я думаю, что это может быть ошибкой. С ';' Вы отправляете два запроса на сервер, но COLLATE - это пункт, а не юридическое заявление само по себе. Попробуйте:

mysql_query("SET NAMES 'utf8' COLLATE 'utf8_danish_ci'");

Если предложение COLLATE не принимается сервером, возможно, у вас проблема с столбцом метки, имеющим параметры сортировки danish_ci, но входящие операторы имеют значение по умолчанию (prob utf_general_ci). Для акцентированных символов совпадения не будет, но подстановочный знак работает, потому что представление основных символов ascii одинаково.

0 голосов
/ 13 июня 2009

Это может быть проблема кодирования, «в церкви» может быть причудливым персонажем. PHPMyAdmin может быть UTF-8, а ваш собственный сайт PHP может быть iso-latin1.

0 голосов
/ 13 июня 2009

Возможно, попробуйте проверить сообщения об ошибках после вызова запроса (если вы еще не выполняли это вне этой функции). Это может точно сказать вам, что не так.

Как прокомментировал Артем, распечатка фактического запроса - это хорошая идея - иногда все не совсем так, как вы ожидаете.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...