Сразу хочу поблагодарить комментаторов в предыдущем посте за проявленный к теме интерес, за вопросы и за предложения. Ознакомившись с комментариями (целых 14 штук, чуть не надорвался!), я решил написать этот промежуточный пост и разобрать альтернативные пути дальнейших действий.
Итак, прошлый пост закончился на том, что я успешно перехватил трафик с приложения Пикабу для Android, увидел волшебную ссылку https://api.pikabu.ru/v1 и определил, что обмен данными производится по JSON (логично). Но пикабушники не были бы пикабушниками, если бы обошлись без подколов в комментах. Люблю вас, честно.
Проблема в том, что в обнаруженном API мог оказаться вообще любой формат - JSON, XML, YAML или, прости хоспаде, голый HTML. И я покажу HTML внутри ответа от сервера в формате JSON чуть далее. Морально я был готов увидеть в протоколе вообще всё, что угодно, но это оказался JSON, чему я был несказанно рад, так как лично мне с ним работать много проще, чем с тем же XML, да и читать его в сыром виде приятнее, чего греха таить. В качестве особого извращения, можно возвращать результат в виде base64(zlib(protobuf())). Упаковка и распаковка ляжет целиком на плечи серверов и клиентов, зато, с высокой долей вероятности, будут пересылаться меньшие пакеты данных, что актуально для спутникового интернета где-нибудь у черта на куличиках.
Ладно, не буду превращать пост в ответы на комментарии, я только один раз, всего лишь на пол шишечки <3
В комментариях пользователи также предложили еще два способа получить данные с сайта для последующей обработки. Рассмотрю их в порядке возрастания интереса лично для меня.
На данный момент, самый горячий пост - Оскорбил. Его и буду препарировать. Погнали.
Справедливое замечание. Но мне это даже в голову не пришло. Наверняка, это была заводская блокировка, чтобы я не заморачивался всякими анализами HTML. У меня Firefox, поэтому выполню аналогичные действия. Тут это называется "Адаптивный дизайн".
Вероятно, так выглядит Пикабу на iPhone X/XS. Не знаю, не хочу проверять в живую. Открываю devtools (они же инструменты разработчка на F12) и первое, что я вижу - разметка страницы. Допустим. Ищу текст статьи, вот он:
Чтобы до него добраться надо, как я понимаю, найти блок div с классом(-ами?) "story-block story-block_type_text". Но не пинайте строго, я в вебе не особо разбираюсь и сайты ранее не парсил, умею только читать (глазами и головой) разные штуки и анализировать прочитанное. Как по мне, такое название класса не выглядит чем-то фундаментально неизменяемым, но кто его знает, на самом деле. Могу ошибаться, но это, вроде, ссылка на таблицу стилей. Получается, если стилисты поменяют название класса, то парсер посыпется. Неприятно. Однако, хочу заметить, что посыпется любая программа, заточенная под специфическую строку, даже в случае JSON.
Итог - требуется парсер HTML. Конкретно эта страничка весит ~404 кб (для проверки размера я сохранил .html файл на диск и посмотрел его размер). Пока не знаю, много это или мало, разберемся чуть позже.
@gosnorkocontrol
не проще ходить парсером по https://zalipaka.icu/new?twitmode=1&of=v2&page=1 и т.д.? там html в data - простетский, все посты удобно разбиты на обьекты.
Та-а-ак, а это уже интересно. Давай попробуем: Оскорбил
{"result":false,"message":"Krasavchik"}
Спасибо, товарищ программист бэкэнда, стараемся! Жаль, что не удалось договориться :) Ответ пришел, тем временем, в JSON. С конкретным постом не прокатило, надо попробовать в общей ленте: https://zalipaka.icu/?twitmode=1&of=v2
Есть ответ! В JSON! Похоже, загрузилась какая-то часть из 7006 постов в горячем. Есть какая-то реклама (ключ ads), есть какие-то stories (aka посты), поглядим...
Спасибо, Киану. Ты очень точно передал моё выражение лица. Продолжим... Ключ "html", да и содержимое со всякими там div-ами. Да, похоже на правду. Вот только множество переносов строк (\n) и табуляций (\t) напрягает. Ладно, надо найти какой-нибудь html beautifier, чтобы посмотреть на это дело в нормальном виде.
Как обычно, искать лень, а на первом попавшемся сайте по выравниванию HTML эскейп-символы не убираются. Но я же программист C++, я знаю аж 2 способа, как от них избавиться. Их можно заменить в каком-нибудь Notepad++ на пустой символ или просто напечатать все содержимое в программе С++. Программисты С++ не всегда ищут простые пути. Зачастую, лучший путь тот, что занимает меньше кликов :)
Хорошо, но можно сделать еще лучше.
Во, в самый раз. И что же я теперь вижу? То же название класса в теге div, то же содержимое. Дальше углубляться не вижу смысла.
Сразу виден минус этого подхода - предоставленные мне ключи запроса не подошли для получения данных конкретного поста, а было бы хорошо грузить только конкретные посты, а не всю пачку целиком. И еще возникает вопрос о способе получения "среза" постов за определенный период. Думаю, способа запросить у сервера список допустимых ключей для запроса нет, ну да ладно. Требуется два инструмента - парсер для JSON и парсер HTML. Размер - ~156 кб, но это не один пост, а целая пачка с главной страницы. Требование двух инструментов не является таким критичным, как невозможность использовать этот способ при загрузке конкретно одного поста.
Итого, если очень хочется парсить HTML, то первый способ с готовой страницей все-таки более гибкий, чем этот, но там наверняка всплывут какие-нибудь проблемы с определением номера поста из пачки загруженных. Сомневаюсь. Короче, хочу перейти к разбору третьего способа, уже и колется, и чешется узнать, какие там получатся результаты.
Третий способ - воспользоваться API мобильного приложения. Поехали.
Я буду пользоваться всё тем же mitmproxy и эмулятором с установленным пропатченным приложением Пикабу, хотя и ознакомлюсь с питоновскими библиотеками, предложенными в комментариях, чуть позже. Открываю через приложение страничку горячего. Запрос:
Щьёрт побьери! Пока писал пост, горячее обновилось и сравнить размеры не получится. Вижу номер запроса страницы. Хорошо. Ответ:
Содержимое ответа скрыто, поэтому предлагаю поверить мне на слово, что там JSON :) Никакой пользы этот скриншот, кроме размера в 241.9 кб в рамках текущего разбора не несет, но почему бы и нет? Интернет не казенный, так что расчехляйте свои байты, гулять так гулять! А, вы уже?...
Но теперь-то появилась возможность проверить страничку тестового поста! Ищу пост по имени пользователя за последние сутки, нахожу и открываю его. Приложение генерирует следующий запрос:
Вах, целочисленный story_id, по которому можно просто в цикле грузить посты с Пикабу. Супер. Страница номер 1? Комментарии? В ответе пришла вся информация по посту, включая какой-то список комментариев, возможно полный. Приведу наиболее интересную часть ответа:
story_data - список блоков поста, в нашем случае, один блок типа "t" (text), но который содержит какие-то теги HTML. Вполне возможно, тут же будет присутствовать и форматирование, и ссылки, но с этим буду разбираться потом. Также, тут присутствует полный URL на пост. Я не знаю, возможно ли осуществлять переход по конкретным постам в десктопной/мобильной версии, имея на руках только номер поста, но тут есть полная ссылка, что, определенно, плюс. Хотя я бы возвращал только относительный путь к посту, независимо от домена, а сам домен настраивал в момент первого включения приложения или периодически возвращал бы его в процессе обновления ленты. Короче, я бы не стал отправлять его постоянно, только время от времени. Мало ли... Есть также информация о пользователе - его идентификатор в БД, ник и ссылка на профиль. Ну и был обнаружен интересный ключ sber_donation_url, но тут и так всё понятно :)
К этому моменту каждый уже мог сделать для себя выводы о плюсах и минусах, но для адептов ЛЛ я их все-таки сформулирую, я про вас помню, ребятки.
Плюсы - можно грузить что угодно, в каком угодно порядке и в любое время. Все эксперименты проводились на приложении без аккаунта :) Нужен один инструмент для работы с JSON. Данные приходят в подготовленном для обработки виде, удобнее не придумаешь. Размеры пакетов.... Ну хз, где-то может быть больше, где-то меньше. В готовой странице можно оставлять только необходимые для работы данные/ссылки, тут же прилетает куча дополнительной информации (количество плюсов и минусов для самостоятельного подсчета соотношения, например), многое дублируется. Я бы добавил в запрос еще ключ типа verbose, и если false - то присылать только то, что необходимо для отображения по минимуму, без комментариев. Короче, тут есть простор для воображения.
Минус я вижу только один - нужно исследовать алгоритм авторизации приложения и расколоть формат запросов (есть там один противный hash, пока не ясно, от чего он считается). К каждому запросу (кроме двух первых) прикрепляется два каких-то неопознанных идентификатора. Один из них - deviceuid, и вполне может оказаться, что он не просто сгенерирован на устройстве один раз. Есть подозрение, что придется изрядно помучаться, прежде чем получится эмулировать процесс получения данных по этому способу.
Для себя я сделал выбор - буду продолжать намеченный курс и исследовать приватный API приложения Пикабу. Мне он кажется наиболее гибким и наиболее простым в починке, в случае, если что-то поломается.
Это должен был быть маленький оффтоп-пост, я не хотел, честно! Благодарю за внимание, мне приятно, что вы проявляете интерес к моему творчеству. Будьте чуточку добрее, мы тоже люди.
