Парсинг характеристик товарів для наповнення 1С-Бітрікс

Парсинг характеристик товарів для наповнення 1С-Бітрікс

Характеристики — основа фільтрації каталогу. Без правильно заповнених властивостей (b_iblock_element_property) розумний фільтр 1С-Бітрікс не працює, фасетний пошук дає нульовий результат, і покупець не може відібрати потрібні товари. Парсинг характеристик технічно складніший за парсинг описів: потрібно не просто витягти текст, а розпізнати структуру «назва параметра — значення» і правильно покласти дані у властивості інфоблоку.

Формати характеристик на джерелах

Таблиця специфікацій буває кількох типів:

HTML-таблиця (<table>) — класика, парситься через XPath //table//tr. Перша комірка рядка — назва, друга — значення.

Список dl/dt/dd — часто використовується в сучасних магазинах. Парсимо пари dt+dd.

JSON-LD або мікророзмітка schema.org — ідеальний варіант. Дані вже структуровані, не потрібно парсити HTML:

preg_match('/<script type="application\/ld\+json">(.*?)<\/script>/s', $html, $m);
$data = json_decode($m[1], true);

JS-змінні — дані у window.productData або __REDUX_STATE__. Витягуємо regex'ом.

Нормалізація назв характеристик

Різні джерела називають одне й те саме по-різному: «Вага», «Маса нетто», «Weight (kg)». Прямий маппінг у властивість інфоблоку без нормалізації створює хаос.

Рішення: таблиця аліасів property_aliases:

CREATE TABLE parser_property_aliases (
    alias VARCHAR(255),
    canonical_name VARCHAR(255),
    property_code VARCHAR(100)
);

При парсингу кожну знайдену назву шукаємо в таблиці аліасів. Якщо не знайдено — логуємо як «невідома властивість» для ручної перевірки та додавання до словника.

Маппінг на властивості інфоблоку

Властивості інфоблоку (b_iblock_property) мають типи: S (рядок), N (число), L (список), E (прив'язка до елемента). Для характеристик зазвичай використовують:

• S — текстові значення («Колір: червоний»)
• N — числові з одиницею виміру (PROPERTY_TYPE = N, USER_TYPE порожній)
• L — фіксований список значень (важливо для фільтра)

Для фасетного фільтра 1С-Бітрікс (bitrix:catalog.smart.filter) значення типу L працюють швидше, ніж S — вони індексуються в b_iblock_element_prop_enum.

Створення значення типу L при імпорті:

// Отримуємо або створюємо enum-значення
$propEnum = CIBlockPropertyEnum::GetList([], [
    'PROPERTY_ID' => $propId,
    'VALUE' => $parsedValue
])->Fetch();
if (!$propEnum) {
    CIBlockPropertyEnum::Add(['PROPERTY_ID' => $propId, 'VALUE' => $parsedValue]);
}

Робота з одиницями виміру

Джерела дають «10 кг», «10kg», «10 кілограмів». Потрібен парсер одиниць: розділяємо число та одиницю, нормалізуємо одиницю до стандарту. Простий regex: /^([\d.,]+)\s*(.*)$/.

Числові значення властивостей у 1С-Бітрікс зберігаються як рядки в b_iblock_element_property.VALUE — одиниці виміру краще виносити в окрему властивість або додавати до CODE властивості (WEIGHT_KG).

Кейс: електроніка, 15 000 SKU, 120+ типів характеристик

Завдання: наповнити властивості для розумного фільтра по ноутбуках, телефонах, телевізорах — три інфоблоки з різними наборами властивостей.

Реалізація:

• Парсинг із сайту виробника через JSON-LD (70% товарів) + HTML-таблиця (30%)
• Словник аліасів з 380 записів, зібраний за перші 3 дні розробки
• Всі числові характеристики — тип N, спискові (бренд, колір, країна) — тип L
• Паралельний запуск 5 воркерів через PHP-CLI, кожен обробляє свою категорію

Результат: розумний фільтр запрацював коректно за 48 параметрами після 2 ітерацій налагодження словника аліасів.

Часові рамки робіт

Разом: 7–12 робочих днів — це одне з найбільш трудомістких завдань наповнення каталогу.