Пока заметил некорректную работу LIKE и MATCH..AGAINST. ORDER BY сортирует правильно. Как через шел поменять кодировку по умолчанию? (доступ есть)
character_set_client = cp1251 character_set_connection = cp1251 character_set_database = cp1251 character_set_results = cp1251 character_set_server = cp1251 character_set_system = utf8 collation_connection = cp1251_general_ci collation_database = cp1251_general_ci collation_server = cp1251_general_ci
Ну нет у меня проблемы вопросиков! Проблема с работой некоторых строковых функций.
Например, в запросе, испоьзующем составной fulltext - индекс, запрос по слову "хостинг" показывает правильные результаты, а по слову "искусство" - вываливает совсем неожиданные результаты.
Точно, вопросик там не нужен :)
Итак, совместными усилиями выведем результат:
preg_match_all('~<li[^>]*?>([^<\/]*)~', $file1, $file2);
Это если нужно обработать все тэги li, в противном случае вариант Kolyaj:
preg_match_all("/<li class=\"raz\">([^\/<]*)/U", $file1, $file2)
P.S. А мне с MySQL никто не поможет в соседней ветке? 🚬
Сорри, в прошлом примере есть ошибочка. Правильно будет так:
preg_match_all('~<li[^>]*?>(.*?)\/.*?<\/li>~i', $s, $res);
Ай! Сразу засаду не увидел, это не будет работать, если нет слэша. Сейчас добавлю пример, поторопился :)
Пробуй так:
preg_match_all('~<li[^>]*?>(.*?)[<|\/]~i', $s, $res);
Странно, Ваш пример у меня работает с этой регуляркой. У вас там не UTF-8 кодировка случайно? Тогда добавьте ключ u и будет счастье.
Так это проще некуда:
preg_match_all('~<li[^>]*?>(.*?)\/*?<\/li>~i', $s, $res);
Повеселили их правила, особенно:
У них там что, все каталоги с посещаемостью >= 1К посетителей? 😕
Говоря по совести, это сервис должен платить владельцу каталога, за добавление в базу. Это конечно их бизнес, но правила местами маразматические :)
Зачем такое надо. Недавно где-то читал, что такое для гугла вредно из-за supplemental results (если найду ссылку-выложу). А если по теме, то через htaccess такое можно сотворить.
Вебальте явно поиска не хватает. Неужели так сложно добавить? 🚬
