Не получается корректно спарсить данные со страницы

[Tony80]

Доброго дня.

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

Казалось, задача вполне простая - определить область по её признакам, определить переменную и поместить туда необходимые данные.

Демонстрирую по шагам.

Исходная страница и нужная область данных,



Да, оригинальный URL откуда берутся данные - https://www.browserscan.net/

По классике - нахожу часть кода "до" и "после", которая гарантирует точное и единственное попадание.

Пожалуйста, "до",



пожалуйста, "после",



Тестирую в конструкторе рег. выражений,



Всё чётко, единственные результат - то, что нужно.

Переношу рег. выражение в экшен парсинга,



Запускаю экшен,



Результат как видно из скриншота нулевой.

Это уже далеко не первый случай по данной странице, закономерности здесь следующие.

Если последовательность "до" в регулярном выражении достаточно длинная,



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



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

Заряжаю конструктор действий, указываю область, перевожу в вариант Xpath, тестирую,



Вроде бы всё чётко - забираю данные по внутреннему тексту, текст корректный.
Формирую экшен, переношу в проект, редактирую экшен, чтобы он клал результат парсинга в нужную мне переменную (по умолчанию кладёт во временную).

Запускаю экшен



и результат матчинга - совершенно другие данные.

Измучился уже.

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

Так, где код небольшой и данные матчатся без избыточной части "до", всё нормально,



я забираю - всё отлично.

Но в обработки части полей - прям мучаюсь уже второй день. И так, и сяк, и регулярка, и Xpath, нет корректного результата
И главное непонятно, что теперь с этим делать...

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

 

[volody00]

можно было бы эти 2 дня потратить на изучение xpath и не знать больше бед - https://www.youtube.com/playlist?list=PL2_pqCq0c-daHITdyuSS-oe7QSz1T2rWz .

вот так можете попробовать

//div[contains(text(), 'Время на основе IP-адреса')]/parent::div/following-sibling::div

 

[Tony80]

можно было бы эти 2 дня потратить на изучение xpath и не знать больше бед - https://www.youtube.com/playlist?list=PL2_pqCq0c-daHITdyuSS-oe7QSz1T2rWz .

Вы правы - если во всех случаях заранее знать правильный путь, то бЕды не будут более одолевать однако это невозможно, потому что незнание как и преодолевается узнаванием

Хорошо, что есть возможность спросить и замечательно, что есть те, кто не отказывает в помощи.
Мат. часть надо подтягивать, потому что штатные возможности программы не покрывают даже такие, казалось бы, простые задачи.

Благодарю Вас и за указание на справочный материал, и за то, что вникли в конкретику проблемы + потратились на решение

Принципиально ещё вот в чём бы хотелось разобраться - как быть с тем обстоятельством, что тестер регулярных выражений выдаёт нужный результат, а в проекте экшен не отрабатывает? Почему так происходит?

 

[volody00]

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

Это к разработчикам, я не знаю. @Sergodjan

 

[Sergodjan]

Это к разработчикам, я не знаю. @Sergodjan

DOM для составления рег-выражения вы берете через инструмент ПМ (см. скриншот)?
У себя я вижу отличающийся DOM, если брать из ПМ. То есть он выглядит не так как у вас например, со значительными достаточно отличиями (и я сейчас не про язык отображ. сайта).

Могу добавить, что такие длинные рег-выражения, особенно с динамическими частями, которые в любой момент могут измениться, лучше не использовать. Чем короче выражение, тем лучше и надежнее.

 

[Tony80]

DOM для составления рег-выражения вы берете через инструмент ПМ (см. скриншот)?

Да, конечно, только я беру не DOM, я беру исходный код.
Если я работаю с регулярными выражениями, то мне нужен исходный код.

У себя я вижу отличающийся DOM, если брать из ПМ. То есть он выглядит не так как у вас например, со значительными достаточно отличиями (и я сейчас не про язык отображ. сайта).

Т.е. из этого я делаю вывод, что нужно строго работать со вкладкой DOM?

Могу добавить, что такие длинные рег-выражения, особенно с динамическими частями, которые в любой момент могут измениться, лучше не использовать. Чем короче выражение, тем лучше и надежнее.

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

 

[Sergodjan]

Да, конечно, только я беру не DOM, я беру исходный код.
Если я работаю с регулярными выражениями, то мне нужен исходный код.

DOM и HTML исходник отличаются.
Если вы составляете рег-выражение с определенным исходником, то и кубик должен работать с точно таким исходником.

Т.е. из этого я делаю вывод, что нужно строго работать со вкладкой DOM?

Да. Либо составляйте рег-выражение для HTML-исходника и работайте в кубике с таким же исходником.

 

[Tony80]

DOM и HTML исходник отличаются.

А вот здесь я уже не понимаю. DOM модель формируется на основе HTML кода.
Формально, DOM это и есть HTML только в его структурном представлении.

Если мы работаем с элементами HTML через DOM, то каким образом исходники отличается, если оригинальный источник один? Всё та же страница которая не менялась и я соответственно этот оригинальный источник и использую.

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

Так в том то и дело, что кубик будет работать с той же страницей, которая и была. Кубик то работает с конкретной странице, а не с вкладкой при копировании источника.

Я вот сейчас скопировал из вкладки DOM-модель и Код страницы - разницу вижу только в двух строчках.
В DOM модели первая строчка пустая и комментарий <!--...--> в Коде странице этого нет, далее всё тоже самое.

Что принципиально меняется в содержании страницы (по части окружающего кода) между двумя этими представлениями?

 

[Sergodjan]

А вот здесь я уже не понимаю. DOM модель формируется на основе HTML кода.
Формально, DOM это и есть HTML только в его структурном представлении.

Если мы работаем с элементами HTML через DOM, то каким образом исходники отличается, если оригинальный источник один? Всё та же страница которая не менялась и я соответственно этот оригинальный источник и использую.



Так в том то и дело, что кубик будет работать с той же страницей, которая и была. Кубик то работает с конкретной странице, а не с вкладкой при копировании источника.

Я вот сейчас скопировал из вкладки DOM-модель и Код страницы - разницу вижу только в двух строчках.
В DOM модели первая строчка пустая и комментарий <!--...--> в Коде странице этого нет, далее всё тоже самое.

Что принципиально меняется в содержании страницы (по части окружающего кода) между двумя этими представлениями?

Все так, но есть нюансы и особенности, просто нужно взять за правило, что нужно учитывать эту особенность - используйте одинаковые виды исходников. Разве это трудно?

 

[Tony80]

Все так, но есть нюансы и особенности, просто нужно взять за правило, что нужно учитывать эту особенность - используйте одинаковые виды исходников. Разве это трудно?

Конечно не трудно, просто хотелось для себя разобраться.
Спасибо