Предложения по улучшению инструментов парсинга и взаимодействия с элементами сайтов

[ibred]

Продолжаем рубрику полезных опросов для улучшения пользовательского опыта при работе с ProjectMaker и ZennoPoster

Коллеги, расскажите, пожалуйста, каким методом вы чаще всего парсите данные с сайтов?
Это позволит нам сделать определенные выводы и улучшить инструменты для сбора данных с сайтов, в частности конструктор действий.

Варианты:

• Конструктор действий
• Помощник парсинга (xPath)
• Помощник парсинга (CSS Selector)
• Регулярные выражения
• C# (с помощью встроенных методов FindChildByXPath и др.)
• C# сторонние библиотеки
• Другое _______________

Проголосуйте и напишите ваш вариант ниже и если не затруднит, объясните почему вы используете именно его - чем он лучше остальных способов по вашему мнению.
Что удобно и неудобно, что радует или наоборот заставляет вас нервничать? Делитесь!

И второй вопрос: Что вы хотели бы улучшить в текущих инструментах парсинга и взаимодействия с элементами сайта (клики, установка значений и т.п.)?

 

[amyboose]

весь html в htmlagility и парсишь сколько хочешь за 0.000000000001 сек с минимальной нагрузкой

 

[Asmus003]

Пользуюсь только XPath на C#. Мне удобно там собирать коллекции элементов и обрабатывать их как нужно. Парсинг регуляркой считаю извращением) Кубик "парсинг текста" часто не находит то, что мне нужно.

 

[Nilsoner]

Расскажу.
1. Смотрю как расположены необходимые данные на странице.
2. Смотрю как реализован переход между страницами, как понять что парсинг должен быть закончен.
3. Реализую эту логику в PM, т.е. это или счетчик, или проверка регуляркой на наличие определенного символа на странице.
4. Затем использую GET запросы и регулярные выражения для поиска необходимых данных.

Но обычно для парсинга использую Python и библиотеки request и BS4, там уже xpath.

 

[tatarin]

• Конструктор действий - самый легкий!

 

[ibred]

весь html в htmlagility и парсишь сколько хочешь за 0.000000000001 сек с минимальной нагрузкой

Насколько встроенные методы парсинга через C# уступают htmlagility по вашему мнению?

Пользуюсь только XPath на C#. Мне удобно там собирать коллекции элементов и обрабатывать их как нужно. Парсинг регуляркой считаю извращением) Кубик "парсинг текста" часто не находит то, что мне нужно.

Конструктор действий - самый легкий!

Пользовались ли вы "Помощником парсинга"?

 

[tatarin]

Пользовались ли вы "Помощником парсинга"?

Нет! Бесполезная штука для меня! Еще регулярками паршу если в конструкторе получаеться их создать!

 

[ibred]

Нет! Бесполезная штука для меня! Еще регулярками паршу если в конструкторе получаеться их создать!

Почему бесполезная, что именно у Вас не получилось?

 

[Lord_Alfred]

Конструктор действий: использую для заполнения форм регистрации/постинга, хватает в 95% случаев его
Регулярные выражения: парсинг ссылок на активацию из почты
C# (с помощью встроенных методов FindChildByXPath и др.): заполнение сложных форм, где нужно рандомно расставить какие-то галочки/селекты в зависимости от предыдущих результатов

 

[andrey-ka]

Пользуюсь только XPath на C#. Мне удобно там собирать коллекции элементов и обрабатывать их как нужно. Парсинг регуляркой считаю извращением) Кубик "парсинг текста" часто не находит то, что мне нужно.

Я аналогично.

Правой кнопкой на элементе, смотрю как он расположен в дереве, есть ли стандартные id, name, class.
Далее если нет то уже поиск по вложенности, расположению, содержимому.

 

[Asmus003]

Насколько встроенные методы парсинга через C# уступают htmlagility по вашему мнению?



Пользовались ли вы "Помощником парсинга"?

Мне этот кубик не нужен, поскольку я паршу не просто названия, как на скрине, а названия и кучу характеристик для каждого названия, и потом это все в табличку ложу. Мне на C# это удобнее, не представляю как это удобно делать регулярками или кубиком этим. Кроме того, я там же на C# обрабатываю результаты и удаляю ненужные, например по дате или кол-ву. И это все в 1 кубике. У меня код есть, в котором я меняю только пути xPath и немного адаптирую его под каждый сайт.

 

[orka13]

Если шаблон на запросах, то только "C# + HtmlAgilityPack.dll + xPath".
Если в браузере, то "C# + xPath". Обычные кубики использую только если надо много условий нагородить, типа как дополнительно высоту элементов на странице проверить для отброса невидимых и влом в C# это городить.

 

[gevolushn]

1. Конструктор.
2. Регулярки.
Пока хватает.

 

[ibred]

Если шаблон на запросах, то только "C# + HtmlAgilityPack.dll + xPath".
Если в браузере, то "C# + xPath". Обычные кубики использую только если надо много условий нагородить, типа как дополнительно высоту элементов на странице проверить для отброса невидимых и влом в C# это городить.

Подскажите, а почему не используете встроенные методы парсинга через C#?

1. Конструктор.
2. Регулярки.
Пока хватает.

Пользовались ли Вы "Помощником парсинга" и если нет, то почему?
Что хотели бы улучшить в конструкторе?

 

[gevolushn]

Пользовались ли Вы "Помощником парсинга" и если нет, то почему?
Что хотели бы улучшить в конструкторе?

Пользовался. Не понравилось.
Работает вроде как хорошо, но например если парсить выдачу в поисковике, то не всегда правильно берет выдачу. Еще одна причина - перехожу на запросы.

Добавить привязку "по умолчанию" к innertext, value или aria-label. Но это спорный момент. Чисто мое мнение, потому что на "продвинутых" сайтах, привязаться к элементу получается только такими способами.

 

[ibred]

Пользовался. Не понравилось.
Работает вроде как хорошо, но например если парсить выдачу в поисковике, то не всегда правильно берет выдачу.

Не понравилось только то, что не всегда верно забирает данные?

Еще одна причина - перехожу на запросы.

На запросах как раз тоже можно использовать помощник парсинга и разбирать данные из переменной, не только из вкладки браузера.

Чисто мое мнение, потому что на "продвинутых" сайтах, привязаться к элементу получается только такими способами.

Как раз для продвинутых сайтов и рекомендуется использоваться xPath выражения, которые есть в помощнике парсинга.

 

[gevolushn]

Не понравилось только то, что не всегда верно забирает данные?

Да. Все равно приходится "дорабатывать". Функция прикольная, но, наверное, только для самых новичков.

На запросах как раз тоже можно использовать помощник парсинга и разбирать данные из переменной, не только из вкладки браузера.

Не пробовал. Да и не знал.

Как раз для продвинутых сайтов и рекомендуется использоваться xPath выражения, которые есть в помощнике парсинга.

Это было по поводу конструктора. Сделать привязку для кнопок (и т.п.) по умолчанию к innertext, value или aria-label. Потому что привязка изначально идет к name, а в значении там "шифр".

 

[Bablozavr]

Использую конструктор действий и C# с регулярками, для моих задач хватает с лихвой

Было бы удобно, добавить в "конструктор действий" кнопку, чтобы автоматом заполняло поле "Текст для обработки" текущим кодом страницы или кодом из выбранной переменной

 

[orka13]

Подскажите, а почему не используете встроенные методы парсинга через C#?...

Когда только начинал изучать xPath в зенке (2017 год, еще тогда сделал пост с шаблоном-примером и ссылками на теорию по xPath+Zenno+HtmlAgilityPack ) то помощника еще не было. Да и на форуме не было примеров как на запросах без браузера в C# xPath родными методами работать. Старожилы тогда HtmlAgilityPack советовали, вот я на него и перешел.

 

[Alexmd]

А я не буду понтоваться. Если делать шаблон надолго, чтобы парсить много и относительно часто, то парсинг строю через get и разбор регулярками. Но большинство доноров перебирается единожды в ПМ так и не доходя до полноценного шаблона и этот помощник экономит кучу времени. Однозначно ЗА! Помощник помогает.
P.S.: Да и 90% пользователей зенки, насколько я понимаю, пишут все на стандартных кубиках, но стесняются в этом признаваться, потому что почему-то считается зазорным не писать ботов на C#. А, если я правильно понимаю концепцию продукта, он позволяет программировать даже тем людям, которые только вчера клавиатуру запомнили.
Не понял, как откопал эту тему.. Кстати, я в интерфейсе зенки как раз с 5.22 и разобрался и почему-то мне казалось, что эта полезняшка должна была быть там с самых первых версий

 

[Roman48]

Гет запрос и через регулярки, а иногда есть там спарсить, на запись поставил, текст выделил и спарсил.

 

[smartwisard]

От знатока своего дела неторопливое описание с подробностями, как собирать данные, как противодействовать сбору данных.
vc.ru/services/87999-prostaya-instrukciya-kak-zashchitit-svoy-sayt-ili-internet-magazin-ot-parsinga .
На vc.ru по запросу "парсинг" стоит по диагонали просмотреть заголовки.

 

[specialist]

Подскажите, а почему не используете встроенные методы парсинга через C#?

Когда парсинг на запросах, нет возможности использовать встроенный xpath, т.к. он работает (или работал) только во вкладке.

Помощник использую активно в простых шаблонах, пусть чуть медленнее, но удобно и быстро. Где ошибается, перехожу на C#.
Часто важна именно скорость разработки, оптимизации потом будем делать.

Так я уже сравнивал скорость простой генерации порядкового номера ID.
На C# гораздо быстрее, чем на кубиках, но на кубиках оно просто работает, этого часто достаточно.

Так первую версию просто сделал на кубиках и подождал пару минут вместо доли секунды, удивился скорости, подумал что нужно разобраться.
Вначале спарсил сайт, только потом вернулся и сделал заготовку.

Поэтому я за готовые встроенные решения, гибкость и скорость будет после, если она там нужна.

 

[Meteorburn]

Если браузер, то отладка в Хроме, там составляю Xpath и потом переношу на C# используя методы ZP
Если запросы, то всё тоже самое, только через HtmlAgilityPack

 

[Yuriy Zymlex]

Когда парсинг на запросах, нет возможности использовать встроенный xpath, т.к. он работает (или работал) только во вкладке.

Давно есть, для html в строке: https://help.zennolab.com/en/v5/zennoposter/5.30.0.0/webframe.html#topic832.html

 

[zortexx]

Регулярки. Особенно после реализации поддержки групп стало вообще замечательно. Для особо запущенных случаев - xPath.