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

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

Пишу второй раз, потому что мое предыдущее письмо не получило сообщений.
Я настраиваю 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

Комментарии

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

--
Axel,
www.axel.drupal.ru

24 марта 2005 в 12:59

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

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

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

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

24 марта 2005 в 15:07

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

--
Axel,
www.axel.drupal.ru

24 марта 2005 в 16:25

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

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

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

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

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

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

25 марта 2005 в 6:17

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

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

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

25 марта 2005 в 8:13

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

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

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

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

25 марта 2005 в 12:06

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, '/'));

25 марта 2005 в 13:09

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

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

25 марта 2005 в 15: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) . "...";

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

26 марта 2005 в 13:27

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

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

29 марта 2005 в 16:30

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

30 марта 2005 в 5:32

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

19 июня 2005 в 10:14

Да. Только надо:
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

19 июня 2005 в 10:27

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

29 июля 2005 в 23:57

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

30 июля 2005 в 0:09

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

2 сентября 2005 в 18:26

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

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

6 сентября 2005 в 0:11

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

2 сентября 2005 в 19:50