Как настроить поиск русских символов без учета регистра?

Не знаю насчёт iis и прочих виндовых премудростей, но в php регистронезависимый поиск можно получить с помощью mbstring. Поищи здесь на форуме сообщения по mbstring.

--
Axel,
www.axel.drupal.ru

mbstring включал не помогает. Пробовал включить функцию overload для регулярных выражений сайт перестает работать.

Покопался как работает поисковик, если правильно понял создается таблица search_index. Русские символы туда заносятся правильно только если используется в MySQL кодирвка UTF8 но при этом поиск русских символов не работает.

При использовании cp1251 в MySQL вместо русских символов заносятся крякозябры (видно что пишется UTF так как строка из крякозябров в 2 раза длиней строки при использовании UTF8) Но самое странное поиск русских при этом работает, с учетом регистра (что не есть приятно).

Вот уже неделю мозги парю. Какой вариант выбрать?
Какие тонкости настройки php, MySQL, apache (готов перейти на apache если заработает)?

Ссылку то на поиск ты выключил ...
Хорошая шутка получается ;)

--
USU-Lug http://usu-lug.org.ru

:) Да, с поиском у нас беда. Таки уже неудобно давать советы, когда у себя на сайте поиск похерился :) Юзайте google :)

--
Axel,
www.axel.drupal.ru

Значит неправильно заносятся, раз не работает. В дефолтной установке, без mbstring в друпале поиск на русском работает, но является регистрозависимым. Но я не пробовал 4ый mysql, а в 3* версии вовсе нет поддержки utf и mysql кодировкой не заморачивается - как положишь, так и хранит.

--
Axel,
www.axel.drupal.ru

А что случилось с поиском на сайте?

Пишу более подробно...
Вариант 1. MySQL сконфигурирован на UTF8.
В таблицы заносятся читаемые данные в кириллице. Но в таблицу search_index почему то слова из символов кирилицы не добавляются.
Поиск не работает.

Вариант 2. MySQL сконфигурирован на latin1.
В таблицы заносятся нечитаемые данные вместо символов кириллицы. Эти нечитаемые данные попадают в таблицу search_index. Поиск работает с учетом регистров.

Мне нужно обеспечить возможность читать данные из таблиц drupal внешними программами. Таким образом должен использовать 1ый вариант. Но в этом варианте не работает поиск.
Я считаю, что правильным является использование первого варианта, но в drupal есть какой то глюк, который проявляется при символах UTF8 кодировки соответствующих символам кирилицы.
У меня нет такого подхода к программированию "как положишь, так и хранит".

Я не согласен с фразой "Значит неправильно заносятся, раз не работает."
Я сделал вывод, что неправильно работает обновление search_index для символов принадлежащей кирилицы при использовании UTF. Надо бы разобраться в алгоритме работы поиска в drupal.

Предлагаю обсудить алгоритм поиска в drupal.

P.S. alex большое спасибо, что решили обсудить этот вопрос. Надеюсь увидеть ваши сообщения.

Только что написал в другой топик, но повторюсь и здесь.

У меня тоже не работал русский поиск, посмотрел табличку search_index, а там русских слов вообще нет, но много пустых слов. Вообщем с русским косяк. Начал в zend studio дебагить cron.php и search_cron (файл search.module) и обнаружил, что строки портятся функцией strtolower. Взял да поменял везде (2 места) strtolower на mb_strtolower(..., 'UTF-8') и все заработало, в том числе поиск без учета регистра(!)

Возможно это особенность именно виндовой пхп, хз.

Надеюсь у тебя заработал поиск русских без учета регистра? Ты можешь этот файл исправленный куда нибудь на сайт выложить? Или кинь мне на koyra@mail.ru (буду очень благодарен). Я почти неделю сижу бьюсь с этой проблемой поиска. На эти выходные думал дебагить...
У тебя какой модуль включен в php:
1) iconv?
2) mbstring?

Если включен mbstring то какие настройки? Если говорить точнее включены ли у тебя функции overload для регулярных выражений?

Мне интересно это потому, что я смотрел исходники search.module там используются регулярные выражения и поэтому решил включить overload для регулярных выражений. Но с включенными регулярными выражениями при работе drupal, php выдает ошибки про регулярные выражения.

P.S. похоже это на самом деле bug, файл патченный на drupal.org отправить надо бы...

iconv включен. А mbstring.func_overload=0 - видимо из-за этого strtolowercase и работает криво и поэтому пришлось мне в search.module менять strtolower на явный mb_strtolower. А =0 я поставил оттого, что начинает warning сыпаться на странице конфигурирования меню.

Короче, я все переиграл: восстановил прежний search.module, поставил в php.ini func_overload=7, а в drupal/.htacess дописал: mbstring.internal_encoding "UTF-8". Поиск вроде работает (проверил: добавил новость, запустил cron и поиск нашел эту новость). Чтобы не писался warning при настройки меню поправил includes/menu.inc строчку 910 добавив проверочку:

if (!empty($parent)) $parent = substr($parent, 0, strrpos($parent, '/'));

Повторил все ниже следующее

поставил в php.ini func_overload=7, а в drupal/.htacess дописал: mbstring.internal_encoding "UTF-8". Поиск вроде работает (проверил: добавил новость, запустил cron и поиск нашел эту новость). Чтобы не писался warning при настройки меню поправил includes/menu.inc строчку 910 добавив проверочку:

if (!empty($parent)) $parent = substr($parent, 0, strrpos($parent, '/'));

Предлагаю администратору сайта добавить выше написанное в FAQ drupal .

Я тут обнаружил сообщение еще об одной ошибке:

warning: mb_ereg(): mbregex compile err: invalid regular expression in c:\inetpub\wwwroot\modules\user.module on line 214.

Открыл файл user.module строка 214 выделена жирным шрифтом
/**
* Verify the syntax of the given name.
*/
function user_validate_name($name) {
if (!$name) return t('You must enter a username.');
if (substr($name, 0, 1) == ' ') return t('The username cannot begin with a space.');
if (substr($name, -1) == ' ') return t('The username cannot end with a space.');
if (ereg(' ', $name)) return t('The username cannot contain multiple spaces in a row.');

if (ereg("[^\x80-\xF7 [:alnum:]@_.-]", $name)) return t('The username contains an illegal character.');

if (ereg('@', $name) && !eregi('@([0-9a-z](-?[0-9a-z])*.)+[a-z]{2}([zmuvtg]|fo|me)?$', $name)) return t('The username is not a valid authentication ID.');

if (strlen($name) > 56) return t('The username %name is too long: it must be less than 56 characters.', array('%name' => "$name"));
}

edhel может сможешь исправить чтобы ошибки не было?
Эта ошибка проявляется при регистрации нового пользователя. Эта функция проверяет логин на действительность.

Поменяй регулярное выражение не следующее: [^\\x80-\\xF7 [:alnum:]@_.-] - то бишь поставь два "\" вместо одного.

Если я все правильно понимаю, то с utf более правильно использовать ereg, т.к. preg не подменяется mbstring и поэтому utc не поддерживает. В частности, только что правил aggregator.module, чтобы корректно обрабатывался случай, когда у новости (беру ленту с ЖЖ) нет заголовка и заголовок берется из description. В этом случае глюк, если в description идет html-код. Я поменял:

505: $title = preg_replace('/^(.*)[^\w;&].*?$/', "\\1", truncate_utf8($item['DESCRIPTION'], 40));

на:

$title = ereg_replace('<.*?(>|$)', '', truncate_utf8($item['DESCRIPTION'], 80));
$title = ereg_replace('/^(.*?)[^[:alnum:];&].*?$/', "\\1", $title) . "...";

зы: в общем, с национальными языками в друпале не все гладко... как и во многих других софтинах, впрочем

Вы об этих ошибках в drupal.org сообщали???
Может вы еще где либо ошибки нашли???

Не сообщал... ща посмотрю не исправили ли все это в 4.6...

ничего не исправили в 4.6... запостил

Я заменил строчки как вы указали.
Теперь вылез еще глюк - при регистрации высылается письмо пользователю. А там какая то кодировка не читаемая. Все что читается это "UTF-8" При просмотре письма используется UTF-8.

Если решил проблему подскажи как?

Попробуй поменять mbstring.func_overload = 7 на mbstring.func_overload = 6, чтобы mbstring не перекрывал функцию mail.

Большое спасибо. Должно быть mbstring.func_overload = 6. Я тут обнаружил что в user.module необходимо заменить в функции user_validate_name
^\x80-\xF7
на
^\\\\x80-\\\\xF7

Не понял. :) Что на что заменить?
^\x80-\xF7
на
^\x80-\xF7
?

fixed.
Вроде бы так.

--
USU-Lug http://usu-lug.org.ru

Что то никак не въеду, в версии 4.6.1 поиск стал нормально работать?
Имеется в виду без учета регистра и по русским словам.

Да. Только надо:
1. Включить mbsting
Добавь в .htaccess
php_value output_handler mb_output_handler
php_value default_charset UTF-8
php_value mbstring.language Russian
php_value mbstring.http_input auto
php_value mbstring.http_output UTF-8
php_value mbstring.internal_encoding UTF-8
php_value mbstring.substitute_character none
php_value mbstring.func_overload 6

2. Заного переидексировать сайт (так и не понял с чем это связано, но на практике зарабтало только так).
Для этого измени настройки search.module /admin/settings/search , тогда, index сбросится и будет построен заново через некоторое время.
(index строится при вызове cron.php, только с версии 4.6 ввели ограничение на кол-во node`ов, которое индексируется за раз, настраивается все на той же странице).

upd: точнее, менять надо параметр "Минимальная длина слова для индексации:", при изменеии других параметров, index не сбрасывается.

--
USU-Lug http://usu-lug.org.ru

Почему то не работает (выдает - внутренняя ошибка сервера) если вставляешь эти строки в .htaccess? Может php должен подключен быть как модуль? Сейчас у меня в httpd.conf он прописан так:
# Даём знать веб серверу, что у нас есть PHP интерпретатор
ScriptAlias /php5/ "D:/pub_server/apps/PHP5/"
Action application/x-httpd-php-5 "/php5/php-cgi.exe"

# Устанавливаем расширения для PHP скриптов
AddType application/x-httpd-php-5 .php .php5

Естественно, параметры php можно менять через .htaccess ТОЛЬКО есиль php работает как Апачевский модуль. Во всех остальных случаях -- править php.ini.

Это не работает при кодировке базы latin1 и MySQL 3.23. Хотя если если заменить UTF-8 на cp1251, то работает (регистронезависимо ищет), но как-то кривовато начинает с некоторыми функциями mbstring (не возможно включить отображение поля поиска в теме).
php_value mbstring.http_output UTF-8
php_value mbstring.internal_encoding UTF-8

Вчера тестил 4.7 из CVS и заметил, что в admin/settings пишется, что func_overload не поддерживается! Но помню, что без нее начинаются какие-то проблемы, уже забыл какие именно... то ли поиск кривой, то ли сортировка...

Вы что-то путаете. Понятие "кодировка" в mysql появилось начиная с версии 4.1.

Да, нет там кодировки. Сорри. Но вопрос остаётся открытым

А кроме изменения этих настроек нужно патчить ещё что нибудь?

У меня без патча в файле database.mysql.inc:
функция function db_connect($url)
mysql_query('SET NAMES utf8;',$connection); //добавляем строку
выдаёт огромную кучу варнингов.

Вот таких:

warning: array_keys() [function.array-keys]: The first argument should be an array in C:\webserver\home\gatovo.net\www\includes\menu.inc on line 916.

warning: Wrong parameter count for min() in C:\webserver\home\gatovo.net\www\includes\menu.inc on line 916.

Но при подключении, отключении модулей (добавлении, изменении узлов) и в таком виде выдается такой варнинг:
warning: mb_strrpos() [function.mb-strrpos]: Empty haystack in C:\webserver\home\gatovo.net\www\includes\menu.inc on line 974.

Как убрать (не отключать, а действительно убрать), или как исправить.

Apache 2.0.54 MySQL 4.13 UTF-8 кодировка, PHP5.

что, с поиском так косяк и в новой версии?
нифига не работает, зараза....