est-ce que quelqu’un à une astuce/outil/process pour automatiser l’extraction XPath d’un élément d’une page (mail, adresse, nom, téléphone, etc…) ?
Je me forme depuis peu à la technique du scraping via la formule IMPORTXML de Google Spreadsheet, et mis à part une extraction « à la main » via le code source ou l’extension Data Miner je n’ai pas encore trouvé la solution.
C’est particulièrement fastidieux pour ce que je cherche à faire, à savoir récupérer les données d’exposants de salons.
Pas de souci pour exporter la liste des URL d’une page par contre (j’ai au moins compris un truc ;))…
Malheureusement on ne peut pas automatiser l’extraction de sélecteurs XPath, sinon comme tu t’en doutes ça serait trop facile et il y aurait beaucoup moins de business pour les « experts ».
Chaque site possédant sa propre structure, il nécessite une analyse approfondie, au cas par cas. Et quand bien même on pense avoir trouver le bon XPath sur une ou deux pages, il subsiste bien souvent d’autres pages dans lesquelles ce XPath ne matchera plus pour des raisons spécifiques à la structure HTML du site en question.
A la limite tu peux automatiser l’application de regexs, pour extraire les numéros de téléphones, les emails, mais ça reste très limité, et pas du tout ciblé.
Pour parser correctement des données depuis une source HTML, il est nécessaire d’être bien à l’aise avec soit XPath, soit CSS.
OK c’est bien ce que je pensais en tâtonnant un peu de mon côté… Je vais approfondir cette histoire de regexs, même si c’est un peu du chinois pour moi
Hello, en même temps, il suffit de savoir ce que tu veux récupérer : c’est en général toujours à peu près écrit de la même façon, … Il y a quelques années, j’avais trouvé des ressources pas mal concernant les Xpath http://scraping.pro/5-best-xpath-cheat-sheets-and-quick-references/
Ce n’est malheureusement pas aussi facile que cela…
Ce qu’il manque en réalité, pour rendre les choses beaucoup plus simples, c’est la prise en charge de regex au sein des XPaths.
Les XPaths se basent sur la structure du DOM, et non pas du contenu, ni des patterns possibles au sein des contenus/attributs. Alors qu’avec les regex on vient justement pallier à ce problème.
Je préfère largement le XPath, mais c’est une préférence personnelle, nettement baisée par le fait que je l’utilise de manière très intense depuis 8 ans. Je suis capable d’écrire des expressions XPath complexes et longues, avec une folle rapidité, mais uniquement car j’en ai mangé et mangé…
Pour essayer de rester neutre et objectif, je dirais que oui CSS peut être plus rapide, plus simple et intuitif en terme de lecture, de compréhension.
Cela dit, XPath est vraiment plus puissant lorsqu’il s’agit de sélectionner un ensemble de nodes selon des critères complexes et tordus (cela arrive souvent dans ce que je traite).
La meilleure preuve, c’est de jeter un oeil à ce document, tu verras que bon nombres de possibilités/écritures XPath n’ont pas leurs équivalents en CSS (hors section « Dynamic » qui correspond à un contexte de GUI utilisé par un user, avec l’aspect dynamique que cela implique: souris sur tel élément, etc): http://scraping.pro/res/xpath-cheat/xpath_css_dom_recipes.pdf
Un débat qui finalement repose sur des affinités personnelles je pense.
Ce que l’on reproche bien souvent aux sélecteurs CSS, c’est que tu ne peux pas en faire autant qu’avec le XPATH. C’est à dire par exemple remonter un noeud.
Je suis un total partisan du CSS. C’est plus stable et plus concret pour moi. Si tu utilises XPATH, c’est que tu cherches à faire de la sélection relative. De nœud à nœud. Après tu peux aussi utiliser XPATH avec les sélecteurs CSS pour te simplifier la vie (en utilisant des @class contains par ex) mais à ce moment là je ne vois pas pourquoi ne pas passer sur des sélecteurs CSS purs. Et pour palier à tous les côtés négatif du CSS, j’ai créé un wrapper sous forme de plugin qui me permet de tout faire, plus rapidement et plus simplement. Le plugin s’appelle jsonframe et est en libre accès.Il est dispo pour Cheerio et sera bientôt en ligne pour jQuery (pour le plugger plus facilement dans n’importe quel app, surtout en dehors de Node.js).
Tu peux voir un exemple de ce que ça donne dans cet article sur le blog Crème de la Crème : Extraire les données d’un site en 3 minutes avec Javascript (des nouvelles versions du plugin sont sorties depuis). Alors par contre oui, c’est sur une technologie particulière, pour un usage particulier. Et ce plugin/wrapper n’a pas pour but de palier aux problèmes de CSS mais surtout d’offrir une syntaxe d’extraction qui fait sens en passant par une structure JSON.
J’ai rendu public ce plugin après avoir re-factorisé du code que j’utilise depuis longtemps dans mes projets pro. A la suite de quoi j’ai également re-factorisé les outils qui l’utilisent (comme des crawlers http/headless 100% scalable) et qui eux resteront privés .
@ScrapingExpert m’avait justement intéterpelé à ce sujet dans ce post facebook il y a quelques jours. C’est bien toi ?
Pour ma part, j’en resterais sur « affinités personnelles », n’étant pas d’accord pour dire que CSS est plus stable (des soucis de stabilité avec XPath, où cela? ), ou plus concret. Les deux le sont tout autant.
N’oublions pas que les sélecteurs CSS sont à la base plus représentatifs de l’aspect « presentation » et donc du style d’une page, ainsi que de son aspect dynamique via les interactions users. Alors que XPath a été créé afin d’adresser des éléments d’un DOM, et surtout d’un XML si on remonte aux origines. Au final, les deux tendent quasiment au même but.
Mais en prêchant pour ta paroisse, tu ne fais que renforcer mes convictions: comme tu l’as si bien dis à plusieurs reprises, tu as dû dev un wrapper afin de palier à tous les cotés négatifs du CSS.
Par soucis de totale neutralité, si l’on fait abstraction de tes outils, et qu’on regarde d’un point de vue purement XPath / CSS, il y a un ensemble de requêtes non faisables via CSS, et malheureusement toutes les personnes ne pourront pas toujours utiliser ton wrapper au sein de leurs projets… CSS + ton plugin = XPath --> XPath > CSS ?
En fait il faudrait plutôt en venir à comparer du code et des cas d’utilisation. Le débat est un peu stérile sans
Quand je parle de stable et concret, j’entends 2 choses :
nul besoin de faire référence à l’ensemble du path pour cibler un élément. La structure autour peut donc évoluer sans altérer l’efficacité du script.
une fois le script écrit, nul besoin de revenir au code la page pour savoir à quoi correspond un code utilisant les sélecteurs CSS.
Mais au final ce qui m’intéresse / m’intrigue le plus serait de mettre face à face des scripts d’extraction pour voir la lisibilité / simplicité / rapidité.
P.S: Je me rends compte d’ailleurs que lorsque je parlais d’intégration de fonctions parant les faiblesses de CSS dans mon wrapper, c’est en fait car je me les étais créé moi même. En effet j’ai mis en place des logiques complexes qui impliquent de pouvoir indiquer le parent courant.
Quoi qu’il en soit, je pense faire un rapide tutoriel / démonstration vidéo de la dernière version de ce que j’utilise pour avoir des retours et comparer, améliorer, avancer J’apprécie que tu défendes XPATH et j’aimerais réellement découvrir des cas qui devraient me faire changer d’avis.
Je te partagerais cette vidéo si tu le souhaites pour que l’on en rediscute
Au plaisir !
Sur ce point, tu fais fausse route, car les XPaths ne font pas référence à l’ensemble du path pour cibler un élément. En 8 années, je n’ai jamais écris un seul XPath qui défini un chemin complet.
Exemple: //*[@id='whateverid'] :)
Je ne pense pas qu’en arriver à comparer du codes et cas d’utilisation soit utile dans le débat utilisation XPath / CSS.
Je motive cet avis par le fait que la lisibilité, la simplicité et la rapidité ne sont en rien dépendants de XPath / CSS. Ce qui va changer la donne, ça sera le language et les librairies utilisés.
Que l’on écrive un mapping metadata => XPath, ou metadata => CSS, on aura toujours des choses du genre:
Ces deux expressions me semblent tout autant lisibles :), quant à la rapidité/simplicité, je m’abstiendrais, cela dépend de l’expérience que l’on a avec l’un, ou l’autre.
Par contre, en codant une lib en Python, par rapport à du Java, oui y’a moyen que le 1er soit très lisible simple et rapide alors que le second soit beaucoup trop verbeux et complexe.
Pour en revenir au sujet, il s’agit vraiment selon moi d’une question de préférence, et surtout d’habitude, et d’expérience. Si tu écris aussi rapidement tes expressions CSS que j’écris mes XPaths, ce n’est pas car l’un est meilleur que l’autre, c’est simplement notre expérience qui parle
Simple incompréhension de ma part, je pensais à tord, que tu n’utilisais pas les éléments CSS du tout. Autant pour moi T’utilises le XPath comme je l’utilisais. Je trouvais que le langage n’apportait pas grand chose d’utile de plus à ce que j’utilisais à ce moment là déjà, les sélecteurs CSS.
Vive le XPath, vive les sélecteurs CSS! On fait la même chose de toute façon
P.S: Je vais prendre un peu de temps pour faire de la comparaison quitte à implémenter XPath dans mon wrapper et me forcer à l’utiliser d’avantage
Je regarde un peu du coup pour l’implémenter et je comprends mieux la difficulté. Techniquement, l’évaluation / accès à XPath est moins pratique que pour les sélecteurs CSS. Je vais passer mon chemin pour l’instant car soit je dois le porter sur une version propre à XPath (et c’est pas le but) soit je dois impliquer de la redondance dans les parsers html et ça ne me plaît guère.
Mais je garde ça sur la roadmap. Qui sait, peut être qu’une personne plus impliquée dans le XPath fera le portage elle même un jour
.
), ou plus concret. Les deux le sont tout autant.
