Пишу второй раз, потому что мое предыдущее письмо не получило сообщений.
Я настраиваю 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
mbstring включал не помогает. Пробовал включить функцию overload для регулярных выражений сайт перестает работать.
Покопался как работает поисковик, если правильно понял создается таблица search_index. Русские символы туда заносятся правильно только если используется в MySQL кодирвка UTF8 но при этом поиск русских символов не работает.
При использовании cp1251 в MySQL вместо русских символов заносятся крякозябры (видно что пишется UTF так как строка из крякозябров в 2 раза длиней строки при использовании UTF8) Но самое странное поиск русских при этом работает, с учетом регистра (что не есть приятно).
Вот уже неделю мозги парю. Какой вариант выбрать?
Какие тонкости настройки php, MySQL, apache (готов перейти на apache если заработает)?
--
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 большое спасибо, что решили обсудить этот вопрос. Надеюсь увидеть ваши сообщения.
Ссылку то на поиск ты выключил ...
Хорошая шутка получается
--
USU-Lug http://usu-lug.org.ru
Да, с поиском у нас беда. Таки уже неудобно давать советы, когда у себя на сайте поиск похерился Юзайте google
--
Axel,
www.axel.drupal.ru
А что случилось с поиском на сайте?
Только что написал в другой топик, но повторюсь и здесь.
У меня тоже не работал русский поиск, посмотрел табличку 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. А я поставил оттого, что начинает 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`ов, которое индексируется за раз, настраивается все на той же странице).
[b]upd:[/b] точнее, менять надо параметр "Минимальная длина слова для индексации:", при изменеии других параметров, 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
Вы что-то путаете. Понятие "кодировка" в 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.
Вчера тестил 4.7 из CVS и заметил, что в admin/settings пишется, что func_overload не поддерживается! Но помню, что без нее начинаются какие-то проблемы, уже забыл какие именно... то ли поиск кривой, то ли сортировка...
что, с поиском так косяк и в новой версии?
нифига не работает, зараза....