Comments 4
Дмитрий, спасибо за доклад и за то, что тезисы здесь изложили. Очень интересно, правда! После доклада на СПИКе залезла на Rambler и была приятно удивлена))) Очень понравилась идея с вертикальным поиском. Вакансии отлично ищутся! Ждем таких же тематических поисков и по другим жизненным вопросам))))
Про SearchMe ни слова, хотя у них половина инноваций в предложении категорий поиска. Категории поиска, там они так просты на вид, а тут они так сложны на обсуждение...
Сейчас стоит задача парсить нн-ое количество сайтов с целью извелчения однотипной информации. Допустим, извлечение каталога из различных интернет магазинов. Родилась идея вот такого проектика.
Проект универсального парсера.
Предлагаемый алгоритм работы.
1. Из исходного файла формируется форматированный исходный код с подстветкой синтаксиса в виде HTML (см. пример модуля templavoila в typo3).
Любой тэг из текста исходника заключается в , при клике на который определяется его путь (XPath) в структуре DOM.
2. Пользователь добавляет новый ресурс, указав адрес страницы и указав имя, под которым будут храниться конкретные настройки парсера именно этого ресурса.
2.1 После указания стартовой страницы парсинга пользователю выводятся обработанные исходники этой страницы в соотвествеии с п.1.
Здесь он выбирает (просто кликнув по имени тэга) ближайший контейнер, который содержит данные для парсинга.
Дальнейшая работа будет осуществляться только внутри этого контейнера, весь остальной HTML-документ во внимание не будет браться.
2.1.1 Каждый раз при запуске парсинга каждого ресурса необходимо проверять, что путь к контейнеру не изменился (точнее, что такой контейнер вообще существует).
Если это не так, то нужно уведомлять пользователя о том, что исходный код страницы изменился, поэтому необходимо перенастроить парсер, иначе будут извлечены неверные данные со страницы.
В будущем имеет смысл сделать более продвинутую проверку
(например отслеживать, чтобы на одном уровне в дереве элементов не появился одноименный элемент,
или тем более элемент с одинаковым id!, или сообщать об изменениях внутренней структуры первого вложенного уровня контейнера)
2.2 Далее в проект добавляются объекты для парсинга. Предполагается 2 типа объектов:
а) Одиночные. Парсер просто ищет внутри контейнера по XPath нужный объект и извлекает требуемые данные.
б) Повторяющиеся. Пользователь указывает на один из повторяющихся объектов, а парсер на этом же уровне отбирает все одноименные объекты. (Например это могут быть строки ).
* внутри повторяющегося объекта обязательно указывается один или несколько одиночных объектов.
* допустима вложенная структура повторяющихся объектов
* допустима вложенная структура одиночных объектов
2.3.
Каждый одиночный объект имеет XPath и путь в базе данных, куда его необходимо сохранить (для краткости назовем его DBPath, формат произвольный).
В настройках контейнера должен быть указан столбец для хранения уникальных Id новых записей (должен быть AUTO_INCREMENT, вообще его лучше определять автоматом (Primary key), и если такого поля нет, нужно предложить создать его).
Одиночным объектом может быть или содержимое тэга, или его атрибут.
DBPath добавляется с помощью выбора пользователем из разворачивающегося списка таблицы и столбца, из БД, указанной в настройках ресурса. Из всех полей необходимо делать фильтр по типам
и оставлять только те, которые подходят для хранения выбранных данных (например, нельзя сохранить текст в столбце с типом INT).
В дополенение третья разновидность одиночного объекта - файл по ссылке. В этом случае пользователю предлагается указать из всех элементов тот, который является ссылкой на файл.
В форме указания DBPath должны быть только поля типа BLOB, если в настройках указано сохранять файлы в БД, или в противном случае -
строковые поля нужной длины, чтобы уместилось уникальное сгенерированое имя файла, под которым будет сохранен загруженный файл в каталоге, указанном в настройках.
2.4. При добавлении нового объекта внутрь существующего, необходимо указать, каким образом хранить данные в БД. Возможно 2 варианта:
а) Дочерний элемент хранится в той же таблице, что и родительский, но с указанием pid (parent id). В этом случае при создании вложенного объекта необходимо
указать столбец для хранения pid (это делается один раз при создании первого вложенного объекта).
б) Дочерний элемент хранится в отдельной таблице. В этом случае каждый раз при создании вложенного объекта указывается:
- таблица, в которую будут поступать данные
- Primary Key этой таблицы (лучше определять автоматом, а если он не создан, то предлагать создать)
- столбец Foreign Key, куда будет записываться Primary Key родительской таблицы
Проект универсального парсера.
Предлагаемый алгоритм работы.
1. Из исходного файла формируется форматированный исходный код с подстветкой синтаксиса в виде HTML (см. пример модуля templavoila в typo3).
Любой тэг из текста исходника заключается в , при клике на который определяется его путь (XPath) в структуре DOM.
2. Пользователь добавляет новый ресурс, указав адрес страницы и указав имя, под которым будут храниться конкретные настройки парсера именно этого ресурса.
2.1 После указания стартовой страницы парсинга пользователю выводятся обработанные исходники этой страницы в соотвествеии с п.1.
Здесь он выбирает (просто кликнув по имени тэга) ближайший контейнер, который содержит данные для парсинга.
Дальнейшая работа будет осуществляться только внутри этого контейнера, весь остальной HTML-документ во внимание не будет браться.
2.1.1 Каждый раз при запуске парсинга каждого ресурса необходимо проверять, что путь к контейнеру не изменился (точнее, что такой контейнер вообще существует).
Если это не так, то нужно уведомлять пользователя о том, что исходный код страницы изменился, поэтому необходимо перенастроить парсер, иначе будут извлечены неверные данные со страницы.
В будущем имеет смысл сделать более продвинутую проверку
(например отслеживать, чтобы на одном уровне в дереве элементов не появился одноименный элемент,
или тем более элемент с одинаковым id!, или сообщать об изменениях внутренней структуры первого вложенного уровня контейнера)
2.2 Далее в проект добавляются объекты для парсинга. Предполагается 2 типа объектов:
а) Одиночные. Парсер просто ищет внутри контейнера по XPath нужный объект и извлекает требуемые данные.
б) Повторяющиеся. Пользователь указывает на один из повторяющихся объектов, а парсер на этом же уровне отбирает все одноименные объекты. (Например это могут быть строки ).
* внутри повторяющегося объекта обязательно указывается один или несколько одиночных объектов.
* допустима вложенная структура повторяющихся объектов
* допустима вложенная структура одиночных объектов
2.3.
Каждый одиночный объект имеет XPath и путь в базе данных, куда его необходимо сохранить (для краткости назовем его DBPath, формат произвольный).
В настройках контейнера должен быть указан столбец для хранения уникальных Id новых записей (должен быть AUTO_INCREMENT, вообще его лучше определять автоматом (Primary key), и если такого поля нет, нужно предложить создать его).
Одиночным объектом может быть или содержимое тэга, или его атрибут.
DBPath добавляется с помощью выбора пользователем из разворачивающегося списка таблицы и столбца, из БД, указанной в настройках ресурса. Из всех полей необходимо делать фильтр по типам
и оставлять только те, которые подходят для хранения выбранных данных (например, нельзя сохранить текст в столбце с типом INT).
В дополенение третья разновидность одиночного объекта - файл по ссылке. В этом случае пользователю предлагается указать из всех элементов тот, который является ссылкой на файл.
В форме указания DBPath должны быть только поля типа BLOB, если в настройках указано сохранять файлы в БД, или в противном случае -
строковые поля нужной длины, чтобы уместилось уникальное сгенерированое имя файла, под которым будет сохранен загруженный файл в каталоге, указанном в настройках.
2.4. При добавлении нового объекта внутрь существующего, необходимо указать, каким образом хранить данные в БД. Возможно 2 варианта:
а) Дочерний элемент хранится в той же таблице, что и родительский, но с указанием pid (parent id). В этом случае при создании вложенного объекта необходимо
указать столбец для хранения pid (это делается один раз при создании первого вложенного объекта).
б) Дочерний элемент хранится в отдельной таблице. В этом случае каждый раз при создании вложенного объекта указывается:
- таблица, в которую будут поступать данные
- Primary Key этой таблицы (лучше определять автоматом, а если он не создан, то предлагать создать)
- столбец Foreign Key, куда будет записываться Primary Key родительской таблицы
Sign up to leave a comment.
Вертикальные поисковики — некоторые части доклада