Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 40
У хабра есть свой удобный API c оберткой на php
Речь не о создании API хабра, а о библиотеке.
не в ту ветку написал! habrahabr.ru/post/241335/#comment_8085921
В данном случае хабр — всего лишь пример. Я использовал его как всем вам известный ресурс. В большинстве случаев библиотеку я использую для доступа к данным на маленьких локальных сайтах, которые были бы плохим примером.
Понял, был не прав.
ну хабр. тут для примера, и насколько я помню то у хабра. закрытое API и ключ выдается по запросу.
Извиняюсь промахнулся, это ответ на habrahabr.ru/post/241335/#comment_8085891
У «Хабрахабра» есть непубличный API, доступ к которому предоставляется только по запросу через форму обратной связи.
В обращении расскажите о себе и подробно опишите, для каких целей вы собираетесь использовать API.
Извиняюсь промахнулся, это ответ на habrahabr.ru/post/241335/#comment_8085891
Для выбора элемента из dom-дерева используется «symfony/dom-crawler» и трансляцией css-селектора в xpath и выборкой элементов занимается эта библиотека. Моя же библиотека с dom-документом ни одной строкой кода не связана, основной целью имеет объединение этих селекторов в структуру, которую нужно получить на выходе.
Тут используется еще один уровень абстракции над dom-документом, который при этом не запрещает вам получить DomNode объект. Но для меня использование стандартных объектов для парсинга html выливается в десятки строк кода и сложную поддержку. Dom-crawler же позиционирует себя как некий аналог jQuery на php и намного проще позволяет модифицировать документ, а также получить полный html обратно. Я не пропагандирую, что это единственно верное решение, оно превносит ограничения в работу, но для большинства задач, с которыми я сталкивался, серьезно упрощает жизнь.
Например — готовую структуру для складывания данных в БД.
На всякий случай, вдруг кому-то пригодится, была статья на Хабре о сравнении скорости парсеров. И мои две копейки PHP+tidy+SimpleXML, в чем принципиальное отличие решения, предлагаемого автором, от этой связки не совсем понятно.
Отличная библиотека, буду пользоваться
P.S.: Спасибо за Guzzle, не знал, использовал раньше свой велосипед
P.S.: Спасибо за Guzzle, не знал, использовал раньше свой велосипед
По мне, так лучше jsoup пока лучше ничего нет
В свое время активно пользовался phpquery.
Отличная библиотека.
Комментаторы выше видимо не сталкивались с написанием сложным парсеров для 10 и более ресурсов, с условиями различными настройками зависящими от того что указал пользователь.
Если кто-то ещё не въехал поясню — это не аналог и не замена xpath phpquery или каким-нибудь другим средствам работы с dom, автор да, добавил слой абстракции над парсерами для возможности чуть ли не динамической генерации api по работе с различными сайтами на основе каких-нибудь настроек из БД. Мне в нескольких проектах это очень поможет, сам хотел что-то подобное написать но на грамотную реализацию мозгов не хватило.
Комментаторы выше видимо не сталкивались с написанием сложным парсеров для 10 и более ресурсов, с условиями различными настройками зависящими от того что указал пользователь.
Если кто-то ещё не въехал поясню — это не аналог и не замена xpath phpquery или каким-нибудь другим средствам работы с dom, автор да, добавил слой абстракции над парсерами для возможности чуть ли не динамической генерации api по работе с различными сайтами на основе каких-нибудь настроек из БД. Мне в нескольких проектах это очень поможет, сам хотел что-то подобное написать но на грамотную реализацию мозгов не хватило.
по сути просто обертка над селекторами, которые используются в PHP Simple HTML DOM Parser, который довольно удобен
а что скажете о производительноти по сравнению с другими библиотеками?
а что скажете о производительноти по сравнению с другими библиотеками?
habrahabr.ru/post/241335/#comment_8086091 — нет никаких других библитотек для сравнения.
к сожалению (или к счастью), я не вижу особой проблемы самостоятельно завернуть некий парсер в удобную для проекта обертку. вспоминается ситуация с «нужно создать еще один универсальный стандарт»
я писал парсеры на php, node.js видел другие парсеры — все упиралось либо в использование библиотеки либо в написание регулярного выражения или xpath
я не утверждаю, что библиотека не имеет права на существование, а говорю о том, что мы пишем те же селекторы (query, xpath, regexp), но в другом месте
я сужу сугубо по статье
я писал парсеры на php, node.js видел другие парсеры — все упиралось либо в использование библиотеки либо в написание регулярного выражения или xpath
я не утверждаю, что библиотека не имеет права на существование, а говорю о том, что мы пишем те же селекторы (query, xpath, regexp), но в другом месте
я сужу сугубо по статье
Запросы к апи в большинстве случаев не стоит делать в основном потоке, а выполнять в фоне и кэшировать. Поэтому для меня производительность не так важна, как удобство использования. А производительность у symfony/dom-crawler не хуже других php-парсеров, посколько все они основаны на трансляции css-селектора в xpath и в конечном итоге используют одни и те же методы.
Еще б допилить немного исполнение в более удобный и расширяемый вид
Выделить getBaseUrl, чтобы не трогать протектед переменную, для построения фильтров вынести фабричный метод вместо статика, each сделать менее декларативным — дать возможность засунуть не только массив правил, но и коллбэк (в который передается каждая нода) — аналогично я бы все расширил коллбэками для постобработки того же text(). Т.е. надо манипулировать ситуациями, когда вложенность json и исходного html может совпадать, а когда нет (например, дату не запихнули в .post, а положили рядом дивом).
Пр опостобработку еще вот что — существует много постоянно необходимых обработок (вроде убрать лишние пробелы внутри, вырезать теги, сделав br2nl) и прочее, что было бы хорошо иметь в ООП-стиле, а лучше и расширять собственными правилами.
Плюс конструкция exist -> then -> else не особо нравится (и не хватает аналога для условного выражения).
Плюс не заметил обработки хттп-ошибок — т.к. порой надо парсить и по 404 считать данные по странице отсутствующими.
Выделить getBaseUrl, чтобы не трогать протектед переменную, для построения фильтров вынести фабричный метод вместо статика, each сделать менее декларативным — дать возможность засунуть не только массив правил, но и коллбэк (в который передается каждая нода) — аналогично я бы все расширил коллбэками для постобработки того же text(). Т.е. надо манипулировать ситуациями, когда вложенность json и исходного html может совпадать, а когда нет (например, дату не запихнули в .post, а положили рядом дивом).
Пр опостобработку еще вот что — существует много постоянно необходимых обработок (вроде убрать лишние пробелы внутри, вырезать теги, сделав br2nl) и прочее, что было бы хорошо иметь в ООП-стиле, а лучше и расширять собственными правилами.
Плюс конструкция exist -> then -> else не особо нравится (и не хватает аналога для условного выражения).
Плюс не заметил обработки хттп-ошибок — т.к. порой надо парсить и по 404 считать данные по странице отсутствующими.
Теперь я и сам вижу недостаток в расширяемости, буду развивать проект и постараюсь учесть комментарии. Коллбэки были в первоначальном варианте, но показались мне слишком громоздкими в описании и метод начинал превращаться в нечитаемую кашу. Попробую поискать достойное решение, чтобы и функционал не страдал, и удобство в использовании и поддержке тоже. Хттп-ошибки возвращают результат всегда одного вида (в документации есть пример) с урлом и статусом ошибки.
а бывает, чтобы получить нужный контент со страницы, надо там с нее определенный js выполнить
А если не хочешь, то надо js парсить… Ну это, наверное, особо грустный случай.
А если не хочешь, то надо js парсить… Ну это, наверное, особо грустный случай.
Скорее developer.yahoo.com/yql/
Access Data Across the Web
Select, filter, sort and join data across web services. You can even insert, update and delete from YQL.
Easily Scrape HTMLи все это из любого языка и платформы
Scrape HTML from the web and turn it into data to reuse. Create an API where one doesn’t exist.
Недавно делал доклад по теме «Парсинг на PHP», где рассматриваю 5 разных способов достать информацию с сайта.
Вот видео: www.youtube.com/watch?v=KZnrb6U2uw8
Вот слайды: www.slideshare.net/pavelpolyakov58/think-php-10-parsing-with-php
Вот код: github.com/PavelPolyakov/parsing-with-php
Надеюсь кому-то понадобится :)
Вот видео: www.youtube.com/watch?v=KZnrb6U2uw8
Вот слайды: www.slideshare.net/pavelpolyakov58/think-php-10-parsing-with-php
Вот код: github.com/PavelPolyakov/parsing-with-php
Надеюсь кому-то понадобится :)
вывести rest через sql-injection
Спасибо. Просто спасибо.
Кстати, есть ли поддержка регулярных выражений в селекторах?
Кстати, есть ли поддержка регулярных выражений в селекторах?
Подскажите, а как загрузить картинку?
Речь идёт о капче, т.е. с теми же куками, что и обычный запрос.
так не работает (и не должно похоже).
Речь идёт о капче, т.е. с теми же куками, что и обычный запрос.
$this->get("/captha.png",[]);
так не работает (и не должно похоже).
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Как использовать API сайта, у которого нет API?