Начну пожалуй с ложки меда) Апарсер -крутой линейный парсер! Для примера возьмем задачу. Чисто для формализации объекта парсинга. Данные любые могут быть) Для списка доменов зоны ru (5kk) пройтись по всем страницам этих доменов и собрать Email. Если смотреть на задачу линейно, страшно...? Сразу мысли, сколько Апарсеров, серваков и за какое время это все ... Как мы будем решать эту задачу? 1. Натравим LinkExtractor c Parse to level 2. Вторым проходом натравим на эти ссылки Net.HTTP парсер. Очень дорого выходит тратить 2 запроса ради поиска мыла. Не так ли? Почему бы нам, имея сорс страницы не парсить его регуляркой по поиску мыльника на лету? Скрестив эти два парсера в единый мы уже увеличим производительность в 2 раза. Напрашивается фича #1 - Рекурсивный режим Net.HTTP. Сам себя кормит ссылками. Но что еще полезного можно выжать из этого, и то что уже умеет Апарсер? Чекер CMS и TextExtractor. Сразу, на лету мы можем детектить CMS и извлекать текстовку. Подытожим на текущий момент какие сопутствующие данные (признаки для нашей глобальной задачи ) мы можем получать имея сорс страницы за 1 запрос. - Сама ссылка страницы как признак - CMS - Текстовку страницы 1. Сама ссылка страницы как признак Какие типы ссылок у нас есть. с ЧПУ и без -host.ru/cat-1/subcat-1/page-1 -host.ru/index.php?cat=1&subcat=1&page=1 1.1 Если в ссылке есть цифры, мы можем включить генерацию ссылок на лету для данного хоста. Сплитим ссылку по параметрам и подставляем с разным шагом значения и чекаем на 200 ОК. Потратить некоторое время и ресурсы на такую генерацию, будет куда дешевле чем линейно ходить по ним. Сразу можем прикинуть на лету порядок диапазонов возможных страниц имея динамический шаг подстановки. 1.2 Не знаю как работает алгоритмически LinkExtractor, ходит по level page Предполагаю что линейно. Парсим home ложим в буфер лист ссылок. Потом на 2 итерации на вход этот список идет и так до указанного левела. Предлагаю такую схему добавить: -парсим level1 -удаляем дубли и сортируем -берем скажем 30% ссылок из листа L1 -берем со второго листа L2 30% ссылок и так до нужного нам Ln тут можно задавать % единый для всех Ln или функционально для каждого Ln. Тем самым мы пропарсим сектор на нужную нам глубину. Дальше включаем следующую логику парсеру. Если результат парсинга регулярки для каждого Ln вернул нам значение не null, регулярка возвращает значения, то мы заводим отдельный лист рейтинга ссылок который дают нам не null. Разбиваем ссылку на левелы и делаем +1 В противовес другому листу, где мы получаем null делаем -1 Сегментируем признаки по левелам. Это канешь самый примитивный вариант. Можно прикрутить полноценный классификатор. Нужно проштудировать тему более подробно для такой задачи. Возможно тот-же k-means отлично подойдет. В идеале мы должны получить такую логику. Если скажем на входе форум, мы канешь часть запросов отрабатываем линейно. Пока на лету не соберем признаки ссылок дающих нам результат по нашей регулярке. Потом, уже парсер сам должен детектить что больше всего результатов мы получаем от ссылок с признаком /profile.php&id=123 и левел с которого мы больше всего получаем ссылок ведущих на левел со значением. Если распарсив сегмент сайта в глубину (30%) мы получили результатов меньше чем некий порог который задали, мы просто переходим на другой хост, и не тратим время и ресурсы на парсинг остальных 60-70% сайта. 2.0 CMS Если мы задетектили известную нам в базе признаков CMS Всю эту логику мы можем завязать на этом. Имея лист паттернов ссылок для нашей регулярки, мы уже можем планировать маршрут парсинга. Из листов L1/L2/L3 брать уже не рандомные 30% ссылок, а имеющие признаки по паттерну для текущей таски 3.0 Текстовка Если регулярка вернула не null. Мы ищем окружающий ее (наше значение) текст. Задаем сколько текста брать по бокам от значения. Ранжируем словарь. Если некое слово или фраза имеет выше частоту упоминания, мы ему добавляем веса. В итоге получим словарь фраз для парсинга пс. Будет выявлено что регулярка чаще всего парсит наше значение рядом со словами: контакты/мыло/емейл/профиль/пользователь - это мы и так знаем Сможем выделять неявные признаки для будущих задач парсинга. Немного сумбурно канешь расписал, но суть думаю понятна о чем речь. Понятно что это требует накладных расходов CPU/RAM гонять веткора эти. Но можно это сделать гибридным все. Включать/выключать на лету. Зависит от уровня реализованной экспертной системы)) Машинное обучение, кластеризация... Возможно это целесообразно сделать в виде подключаемого модуля ядра нейронки которая уже обучена на все это дело. Тогда не нужно обучение на лету. Главное извлекать информацию из true/false и банально сохранять в список ссылки с которых мы получали значения в ходе парсинга. Сделав сортировку уже руками самому, можно выделить признаки /about /contacts /user?id=123 /member?u=123 Получать базы признаков для парсинга того или иного рода значений. Пис)
На форуме множество примеров по правильной работе с HTML::LinkExtractor, где нет необходимости дополнительно использовать Net::HTTP Parse to level переходит наиболее оптимальным образом чтобы покрыть весь сайт, без всяких бредовых переборов Из всего что здесь написано - не хватает только кэширования запросов, чтобы парсеры на подобии Rank::CMS и т.д. не делали повторный запрос, но это уже есть в задачах остальное действительно очень сумбурно и явно не в рамках парсера Пис)
