Разбор на онлайн магазини. Малък пример

Нека разделим парсинга (изстъргването) на сайтовете на две подзадачи.

Самият анализ е търсене на данни, които ни интересуват на страниците.
Разбиране на получените данни.

Първо, нека да опишем приложенията:

Анализатор на "постоянна" информация за продукти от сайта. Този анализатор рядко ще се изпълнява (само за да проверява за нови продукти), ще анализира страници и ще извлича информация за продукта от тях: име, снимки, свойства.
Анализатор на условно променлива информация. Това приложение ще се стартира често и автоматично, ще анализира страниците на сайта, за да търси цени и наличност в склада, за да актуализира тази информация в базата данни (няма да я разглеждаме, тук няма нищо необичайно).
Административен панел, структуриращ получените данни. Това приложение ще бъде стартирано след анализатора на "постоянна" информация и позволява на администратора да анализира/структурира получените данни.

Така че нека да поговорим за парсери

Има много методи за синтактичен анализ, това са регулярни изрази и банално търсене на поднизове. Всички тези методи имат един голям недостатък - с малки промени в сайта, трябва да редактирате самия анализатор.
За себе си (пиша под .net в c #) се спрях на библиотеката HtmlAgilityPack, например описание на Habré.
Това, което прави, е, че чете HTML (дори много невалидни документи) и изгражда DOM дърво. И тогава цялата мощ на XPATH заявките влиза в игра. При правилно написани XPATH заявки няма нужда да редактирате парсера при смяна на сайта.

Пример:
Класовете често се използват за ориентиране в DOM, но още по-често незначителни промени в дизайна на сайта се извършват чрез добавяне на подходящи класове към елементите (от class = "productInfo" до class = "productInfo clearfix"). Следователно в XPATH е по-добре да напишете:

Да, това може да повлияе на производителността, но не много. Универсалността на кода е по-важна.

По същия начин, когато се ориентирам в дърво с помощта на идентификатори на елементи, аз съм склонен да използвам "//" (т.е. търсене в цялото поддърво) вместо "/" (търсене само сред деца). Това спестява в ситуации, в които дизайнерът обгръща някои тагове (като правило, за да поправи някакъв вид грешка в дисплея):

Следващият въпрос е "какво да се анализира?"

Трябва да анализираме основна информация за стоките: име, снимка и най-важното списък със свойства. Ще съхраняваме получените данни в база данни с примитивна структура:

Тези. за всеки продукт ще има списък с двойки стойности: име на свойство (свойствоНаименование) и неговата стойност (свойствоЗначение).

Да приемем, че написахме парсер, анализирахме всички данни от сайта и сега искаме да създадем база данни и сайт за търсене на стоки по параметри. За това трябва да структурираме данните.

Структуриране на данни

Нека създадем още няколко таблици в базата данни за съхраняване на структурирани данни.

Dict_Property - справка за свойства (цвят, размер, тегло и т.н., т.е. всички свойства, по които ще търсим по-късно)
Product_Property - стойностите на тези свойства за конкретен продукт.

Малък "трик" - полето FloatValue - за числови свойства, се формира чрез опит за преобразуване на полето Value в float:

Тя ще е необходима за търсенето (например: полето "тегло", заявката е от 100 до 300 грама, търсенето от текстовото поле "Стойност" ще бъде бавно и неправилно, но от floatValue - бързо и правилно).

Всичко вече е готово за започване на структуриране на данни.

Практиката показва, че дори и най-лошо проектираните китайски магазини се опитват да унифицират описанията на продуктите.
Пример: сайт dx.com, анализиран 1267 стоки. Всичко, което имат 49398 Имоти. Ако групираме по име, получаваме общо 580ценности, които по принцип не са много.

Нека групираме свойствата по име и стойност, вземем таблица (свойство, стойност, колко пъти се появява) и ги сортираме по честота на появяване.

Няма смисъл да се дава цялата таблица, отбелязваме няколко точки:

Първите 100 реда в таблицата (най-често срещаните стойности на свойствата) покриват около 35-40% от всички стойности на свойствата.
Има много свойства и стойности, които се различават един от друг само по регистър и/или интервали/печатни грешки.
Цифрови данни - обикновено в един формат - например тегло, размери, обем RAM.

За да структурираме данните, ще напишем приложение за създаване на "правила за синтактичен анализ". Нека въведем 2 вида правила:

Точно съвпадение. Например: свойство "Цвят", стойност "Черно"
Съвпадение на регулярен израз. Например: свойство Тегло, стойност
(? \ d * \.? \ d +) g

За всяко правило дефинираме набор от свойства, които трябва да бъдат добавени към продукта.
Как изглежда на практика:

С това правило ние "структурираме" около 90% от стойностите за полето Тегло, останалите 10% - чрез правилата за точно съвпадение:

За сайта „PandaWill“, ако свойството „GPS“ е „Да, вградено“ - добавете GPS свойство със стойността на GPS, подобно на стойностите „Да“, „Не“, „Н/А“

Разбира се, има свойства, за които трябва да създадете много правила, например разделителна способност на екрана. За някои продукти той носи името „Дисплей“:

И за някои "Разделителна способност на екрана":

Някои статистически данни: в моя случай бяха създадени около 7000 правила за структуриране на данни, които добавиха малко по-малко от 50 000 стойности на свойствата. Тези. едно правило - 7 стойности.
С добавянето на нови продукти този брой се увеличава, което е добра новина.

След всички тези манипулации получаваме база данни със структурирана информация за стоките. И търсенето в тази база данни е тривиална задача.