Помогите, пожалуйста, не могу понять, в чем дело. Иcпользую плагин jQuery Autocomplete. При выполнении запроса Ajax возникла фигня - при вводе английских букв - всё работает, а русских - ничего не находит. Помогите, как обойти эту проблему. Код файлика, коотрый генеритв ыборку привожу ниже:

я бы начал вот с чего:

Это не решает проблемы, разве что время выполнения запроса, по идее должно вырости... Но не в этом суть. Оно как не находило ничего по русским буквам, так и не находит. Всё упирается в строку 

А чего ей не нравятся советские буквы - никак не пойму.

Это сообщение отредактировал(а) kulikoff - 16.2.2011, 22:56

при наличии СВ, это как минимум упрощает ее решение... 
выбрать все нужные - гораздо более эффективный способ, нежли выбрать все и перебрать потом.

есть логическое обоснование использования mb_strtolower при обработке данных mysql и strtolower для GET? 

нет, логического нет, просто было указано в примере. Но преобразование в строку вида

не дает результата. Вычитал, что можно попробовать решить вопрос командой дял локали 

глухо, как в танке. Эмперическим путем вывел, что всё упирается в функцию strtolower Она не может переварить кириллицу. Как побороться с ней?

Это сообщение отредактировал(а) kulikoff - 16.2.2011, 23:15

во-первых, проблема может быть в БД(set name перед первым же запросом делаешь?)
во-вторых, зачем использовать strtolower, которая завязана на проблемы однобайтности кодировок, если есть СУБДшные функции(mysql, да?)?

видимо я пропустил, что то в этой жизни.

Вытащить ВСЕ данные (а их по всей видимости будет очень много) будет быстрее, чем искать нужные. Мда

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

Во-первых если работаем с mb_string то хорошо бы ему 1 раз и навсегда выставить кодировку:
mb_internal_encoding("cp-1251");
mb_regex_encoding("cp-1251");

Вот например в этой строке
(mb_strpos(mb_strtolower($temp['good_name'],'windows-1251'), $q) !== false)

Тут для mb_strtolower кодировка указана а для mb_strpos нет, почем ее обделили?

Хотя вообще говоря не очень понятно даже зачем тут mb_, ибо если все в ср-1251 то вполне можно использовать обычные ф-ции строчные и на заморачиваться.

Далее, где может быть зарыта собака. Надо бы понять в какой кодировке приходят данные от ajax-запроса. Могу поделиться вот такой вот ф-цией для определения "а не ютф ли нам пришло", ф-ция реально помогла мне сохранить много нервов. Дело в том, что разные браузеры могут передавать данные в разной кодировке, если данные передаются аяксом, тем более через GET.
http://www.php.net/manual/en/function.mb-d...oding.php#68607
Только советую проверить, свою я потерял где-то, не уверен именно ли эту использовал сам.

Ну и наставления.
Как тут уже совершенно справедливо заметили - это не дело - доставать ВСЮ таблицу и перебирать средствами рнр. Никогда так не делайте. Действительно, что будет если в таблице будут десятки или сотни тысяч значений?

Можно начать с того, что предлагали во 2м посте:

Кстати не забудте про mysql_real_escape_string() и слэшировать символы _ и % в ручную, т.к. вышеназванная ф-ция их не обрабатывает.

Но вот беда, такой запрос все равно вызовет перебор всей таблицы даже если имеется индекс по полю good_name. По моему опыту нормально это будет до тех пор, пока в таблице не более 3-5 тыс. записей. Если больше - начнет подтормаживать. Автокомплит вызывается часто, поэтому в перспективе этим можно и сервер завалить.

Я у себя применял такую практику. Я создал в базе поле first_3_chars, куда, как следует из названия, поместил первые 3 символа из основного поля good_name в нашем случае. По полю first_3_chars ставится индекс. Далее когда приходит запрос от пользователя мы откусываем от запроса первые 3 символа и целиком запрос к БД выглядит так:


Ну понятно дело, что его еще все к нижнему регистру привести надо, это я уж тут не обсуждаю. Так вот, такая практика позволяет использовать индекс в тяжелых запросах на автокомплит. У меня успешно работает на таблице в 20к записей при весьма приличном числе обращений. Но такой подход не позволяет ничего показать, когда введено меньше 3х символов. Если это критично, я бы сложил результаты таких запросов в кеш и выдавал бы оттуда. Просто 3 символа в моем случае было оптимальной границей, т.к. полей с одинаковыми первыми тремя символами было максимум 500-600, т.е. LIKE-запрос делает перебор не более 600 строк, в противном бы случае он перебирал все 20к.

Добавлено через 4 минуты и 51 секунду
Ну и да, следите за тем, в какой кодировке данные в базе. SET NAMES в помощь.

Это сообщение отредактировал(а) Dima 2015 - 18.2.2011, 05:44