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

Главные вкладки

Аватар пользователя qman qman 24 марта 2005 в 8:57

Пишу второй раз, потому что мое предыдущее письмо не получило сообщений.
Я настраиваю Drupal 4.5.2 под windows web server iis (так же пробовал apache) php 4.3.10 mysql 4.1
При использовании в MySQL UTF8 не работает поиск русских символов.
Если использовать кодировку в MySQL latin1 (или которая идет по умолчанию) поиск русских символов работает но с учетом регистра.

Как настроить поиск русских символов без учета регистра?
P.S. Поклонникам Denver а сообщаю, что в Denver е поиск русских символов работает, но с учетом регистра.
P.S.S. При использовании latin1 русские символы не читаются из БД при доступе через phpMyAdmin

Комментарии

Аватар пользователя axel axel 24 марта 2005 в 12:59

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

--
Axel,
www.axel.drupal.ru

Аватар пользователя qman qman 24 марта 2005 в 15:07

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

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

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

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

Аватар пользователя axel axel 24 марта 2005 в 16:25

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

--
Axel,
www.axel.drupal.ru

Аватар пользователя qman qman 25 марта 2005 в 6:17

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

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

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

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

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

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

Аватар пользователя edhel edhel 25 марта 2005 в 8:13

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

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

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

Аватар пользователя qman qman 25 марта 2005 в 12:06

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

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

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

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

Аватар пользователя edhel edhel 25 марта 2005 в 13:09

iconv включен. А mbstring.func_overload=0 - видимо из-за этого strtolowercase и работает криво и поэтому пришлось мне в search.module менять strtolower на явный mb_strtolower. А Shok я поставил оттого, что начинает 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, '/'));

Аватар пользователя qman qman 25 марта 2005 в 15:27

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

поставил в 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 может сможешь исправить чтобы ошибки не было?
Эта ошибка проявляется при регистрации нового пользователя. Эта функция проверяет логин на действительность.

Аватар пользователя edhel edhel 26 марта 2005 в 13:27

Поменяй регулярное выражение не следующее: [^\\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) . "...";

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

Аватар пользователя qman qman 29 марта 2005 в 16:30

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

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

Аватар пользователя qman qman 30 марта 2005 в 5:32

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

Аватар пользователя Andrey Andrey (не проверено) 19 июня 2005 в 10:14

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

Аватар пользователя Nick Nick 19 июня 2005 в 10:27

Да. Только надо:
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`ов, которое индексируется за раз, настраивается все на той же странице).

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

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

Аватар пользователя sokrat sokrat 29 июля 2005 в 23:57

Почему то не работает (выдает - внутренняя ошибка сервера) если вставляешь эти строки в .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

Аватар пользователя Nick Nick 30 июля 2005 в 0:09

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

Аватар пользователя sokrat sokrat 2 сентября 2005 в 18:26

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

Аватар пользователя sokrat sokrat 6 сентября 2005 в 0:11

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

У меня без патча в файле 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.

Аватар пользователя edhel edhel 2 сентября 2005 в 19:50

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