- PVSM.RU - https://www.pvsm.ru -
Разделим парсинг (скраппинг) сайтов на две подзадачи.
Вначале опишем приложения:
Методов парсинга много, это и регулярные выражения и банальный поиск подстроки. Все эти способы имеют один большой недостаток – при небольших изменениях на сайте необходимо править сам парсер.
Для себя лично (пишу под .net на c#) остановился на библиотеке HtmlAgilityPack [1], описание например на Хабре [2].
Что она дает – она читает HTML (даже многие не валидные документы) и строит DOM дерево. А дальше вступает в дело вся мощь XPATH запросов. При правильно написанных XPATH запросах нет необходимости править парсер при изменениях на сайте.
Пример:
Для ориентации в DOM часто используются классы, но еще чаще минорные изменения в дизайне сайта выполняются добавлением соответствующих классов к элементам (было class=”productInfo” стало class=”productInfo clearfix”). Поэтому в XPATH лучше написать:
div[contains(@class,’productInfo’)]
вместо
div[@class=’productInfo’]
Да, это может сказаться на производительности, но не сильно. Универсальность кода – важнее.
Точно также при ориентации в дереве при помощи id элементов я, как правило, использую «//» (т.е. поиск по всему поддереву), вместо «/» (поиск только среди дочерних элементов). Это спасает в ситуациях, когда дизайнер обертывает какие-либо тэги (как правило, для фикса какого-нибудь бага отображения):
div[@id=’productInfo’]//h1
вместо
div[@id=’productInfo’]/h1
Парсить нам нужно основную информацию о товарах: наименование, фотография и, самое главное, список свойств. Полученные данные мы будем хранить в БД с примитивной структурой:
Т.е. для каждого товара будет список пар значений: название свойства (propertyName) и ее значение (propertyValue).
Допустим мы написали парсер, разобрали все данные с сайта и хотим теперь создать БД и сайт для поиска товаров по параметрам. Для этого нам нужно структурировать данные.
Создадим еще пару таблиц в БД для хранения структурированных данных.
Dict_Property – справочник свойств (цвет, размер, вес и т.д., т.е. все свойства по которым мы потом будем искать)
Product_Property – значения этих свойств у конкретного товара.
Маленькая «хитрость» — поле FloatValue – для числовых свойств, формируется при помощи попытки конвертации поля Value во float:
update product_property
set floatvalue = CASE WHEN ISNUMERIC(value + 'e0') = 1 THEN CAST(value AS float) ELSE null END
Оно будет нужно для поиска (например: поле «вес», запрос от 100 до 300 грамм, поиск по текстовому полю «Value» будет медленный и не правильный, а по floatValue – быстрый и корректный).
Теперь все готово для того чтобы начать структурировать данные.
Практика показала, что даже самые плохо оформленные Китайские магазины стараются унифицировать описания товаров.
Пример: сайт dx.com, распарсено 1267 товаров. Всего у них 49398 свойств. Если сгруппируем по названию получим всего 580 значений, что в принципе не много.
Сгруппируем свойства по названиям и по значениям, получим табличку (свойство, значение, сколько раз встречается) и отсортируем их по частоте появления.
Всю таблицу приводить смысла нет, отметим несколько моментов:
Для структурирования данных напишем приложение для создания «правил парсинга». Введем 2 типа правил:
(?<value1>d*.?d+)g
Для каждого правила определим набор свойств, которые необходимо добавить к товару.
Как это выглядит на практике:
Правило для сайта «PandaWill», свойство «Net Weight(Including battery)», значений должно удовлетворять регулярному выражению:
(?<value1>d*.?d+)g
При совпадении к товару будет добавлено свойство «Weight» со значением VALUE1 – выбранным из регулярного выражения.
Этим правилом мы «структурируем» порядка 90% значений для поля Weight, остальные 10% — через правила точных соответствий:
Для сайта «PandaWill», если свойство «GPS» равно «Yes, built in» — добавить свойство GPS со значением GPS, аналогично для значений «Yes», «No», «N/A»
Конечно встречаются свойства для которых приходится создавать множество правил, например разрешение экрана. Для каких-то товаров оно названо «Display»:
А для каких-то «Screen resolution»:
Немного статистики: в моем случае создано порядка 7000 правил для структурирования данных, которые добавили чуть меньше 50000 значений свойств. Т.е. одно правило — 7 значений.
С добавлением новых товаров это число увеличивается, что не может не радовать.
После всех этих манипуляция мы получаем БД со структурированной информацией о товарах. А уж поиск по этой БД – тривиальная задача.
P.S. Намеренно не привожу ссылки на результат трудов, чтобы не сочли за рекламу, и не выкинули еще дальше с хабра, кто захочет – тот нагуглит.
Автор: pokryshkin
Источник [3]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/programmirovanie/27124
Ссылки в тексте:
[1] HtmlAgilityPack: http://htmlagilitypack.codeplex.com/
[2] например на Хабре: http://habrahabr.ru/post/112325/
[3] Источник: http://habrahabr.ru/post/169409/
Нажмите здесь для печати.