Analyseurs HTML et XML en Ruby : une comparaison basée sur la charge de travail

Les versions actuelles et les versions de Ruby prises en charge n’ont pas été vérifiées en production pour cette ébauche ; les recommandations sensibles à l’état actuel doivent donc être vérifiées au moment de la publication.

• Choisissez Nokogiri comme point de départ pratique pour le traitement d’HTML statique ou imparfait et le travail général sur les arbres XML.
• Optez pour Ox lorsque l’analyse XML, l’écriture, le traitement de type SAX ou la sérialisation d’objets sont au cœur de vos besoins.
• Optez pour LibXML Ruby lorsque votre pipeline XML nécessite des fonctionnalités XPath, de validation ou XSLT.
• Considérez Oga et Hpricot comme des alternatives nécessitant une analyse particulièrement minutieuse en matière de compatibilité et de maintenance.
• N’utilisez Selenium que lorsque le rendu, les clics, le défilement, les formulaires ou l’état du navigateur font partie de la tâche.

Cette distinction fondée sur la charge de travail est plus utile que de déclarer qu’un ensemble particulier de parseurs HTML et XML pour Ruby est universellement le meilleur.

Les mêmes critères s’appliquent aux six outils. Un astérisque indique les éléments fournis qui doivent encore être confirmés dans la documentation officielle actuelle.

La catégorie « Analyse HTML » de Ruby Toolbox propose des informations utiles sur les paquets, mais les données de répertoires ne suffisent pas à elles seules à établir la compatibilité actuelle ni un classement universel.

Classez les données d’entrée avant de comparer les API. Demandez-vous s’il s’agit de HTML ou de XML, si vous avez besoin d’une récupération tolérante ou d’un échec strict, si les données tiennent en mémoire, et quelles fonctionnalités de requête ou de transformation sont requises.

Ajoutez des contraintes opérationnelles : compilation native, bibliothèques système, runtime Ruby, image de conteneur et cible de déploiement. Enfin, vérifiez si les octets contiennent les données souhaitées. Si ce n’est pas le cas, une récupération, une authentification ou un rendu par le navigateur doit avoir lieu avant que les analyseurs HTML et XML de Ruby puissent les extraire.

Le HTML Web est souvent imparfait. Un analyseur HTML Ruby doit pouvoir reconstituer un arbre utilisable à partir de balises manquantes, d’imbrications inhabituelles et de fragments, tout en garantissant la prévisibilité des requêtes. Nokogiri s’appuie sur le code source pour le CSS et le XPath, ainsi que pour la gestion du HTML mal formé, ce qui en fait un choix judicieux pour une première expérience.

Le XML a des contraintes différentes. La structure, les espaces de noms et les règles de validation peuvent être des exigences métier ; une récupération silencieuse peut donc s’avérer pire qu’un échec manifeste. Choisissez un mode axé sur le XML et définissez comment les erreurs sont signalées.

La récupération est distincte. Les cookies, l’authentification, les redirections et Ajax déterminent le balisage que vous recevez. Si la réponse contient le nœud cible, analysez-le directement. Si JavaScript crée ce nœud ultérieurement, effectuez d’abord le rendu, puis analysez le DOM résultant.

Un arbre DOM charge le document dans un graphe de nœuds en mémoire. Il est pratique pour la navigation entre nœuds parents, frères ou descendants, ainsi que pour les requêtes répétées. L’utilisation de la mémoire augmente avec la taille du document et la représentation arborescente du parseur.

Une interface de type SAX ou « reader » émet des événements au fur et à mesure que l’analyseur progresse. Elle convient aux flux volumineux, aux transformations en mode « append-only » et aux pipelines capables de produire des enregistrements sans conserver l’intégralité du document. Le compromis réside dans la gestion de l’état : votre gestionnaire doit suivre explicitement le contexte, les espaces de noms et les enregistrements partiels.

Parmi ces analyseurs HTML et XML pour Ruby, les exemples fournis illustrent le traitement SAX avec Ox et plusieurs interfaces non-DOM avec Nokogiri et LibXML pour Ruby. Vérifiez les API exactes et mesurez la mémoire résidente maximale à l’aide de fixtures avant de concevoir votre application en fonction de celles-ci.

Pour l’extraction, déterminez si l’équipe préfère les sélecteurs CSS, XPath ou les deux. Le CSS est concis pour les modèles de classes et d’attributs ; XPath est souvent plus adapté aux conditions textuelles, aux axes et au XML tenant compte des espaces de noms. Une analyse ciblée comparant XPath et les sélecteurs CSS peut empêcher que le style des sélecteurs ne devienne une architecture accidentelle.

Pour le XML, vérifiez séparément l’enregistrement des espaces de noms, la validation des DTD ou des schémas, l’XSLT et le signalement des erreurs. Ne déduisez pas une fonctionnalité d’une autre. L’installation mérite la même rigueur : les extensions natives peuvent améliorer les capacités, mais elles peuvent ajouter du travail au niveau du compilateur, des bibliothèques système ou de la création d’images.

Consignez la version du gem, la version de Ruby, les versions des bibliothèques natives et la date de l’examen dans la décision. Relancez les tests de fixture lors des mises à niveau au lieu de considérer le message « installation réussie » comme une preuve de compatibilité.

Nokogiri constitue le point de départ le plus complet, s’appuyant sur le code source, parmi cet ensemble de parseurs HTML et XML pour Ruby. Il analyse le HTML et le XML, permet d’effectuer des requêtes CSS et XPath, et peut construire une arborescence utile à partir d’un code HTML imparfait. Cette combinaison convient au scraping Web courant en Ruby, au nettoyage de flux, à l’inspection de documents et aux transformations nécessitant un accès aléatoire aux nœuds.

require "nokogiri"

html = "<article><h1>Parser choice</h1><a href='/next'>Next</a></article>"
doc = Nokogiri::HTML.parse(html)

title = doc.at_css("article h1")&.text&.strip
next_url = doc.at_xpath("//a[normalize-space()='Next']")&.attr("href")

Les appels de navigation sécurisée sont importants car les sélecteurs peuvent échouer en production même s’ils ont fonctionné sur un échantillon. Déterminez si un champ manquant signifie nilun enregistrement ignoré ou une erreur fatale, puis intégrez ce choix dans vos tests.

Nokogiri ne récupère pas de pages et n’exécute pas le JavaScript des sites. Associez-le à un client HTTP lorsque la réponse contient déjà les données. Passez à une couche de récupération supérieure lorsque l’authentification ou le rendu côté client modifie le document renvoyé.

Les sources fournies attribuent également à Nokogiri la prise en charge de SAX, de l’analyse Push, de XSLT et de plusieurs backends d’analyseurs natifs. Considérez ces fonctionnalités comme soumises à une vérification préalable, en particulier lorsque vous choisissez entre MRI et d’autres environnements d’exécution ou que vous construisez des conteneurs minimaux.

Ox et LibXML Ruby résolvent des problèmes « XML-first » différents. Ox couvre les entrées et sorties XML basées sur des arbres, la sérialisation d’objets Ruby et la consommation SAX pilotée par les événements. Il mérite d’être retenu lorsqu’un analyseur XML Ruby doit sérialiser des objets ou traiter de grands documents sans requêtes complexes.

LibXML Ruby encapsule libxml2 et convient aux pipelines comportant de nombreuses requêtes, où les recherches XPath, les vérifications de schéma ou les transformations XSLT sont importantes. L’aperçu du répertoire indique également que le gem dispose d’interfaces arborescentes, événementielles, de lecture par extraction et d’écriture, ainsi que de la validation DTD, RelaxNG et XSD. Vérifiez ces détails par rapport à la version exacte que vous prévoyez de déployer.

xml = "<person><name>Ada</name></person>"

require "ox"
ox_tree = Ox.parse(xml)

require "xml"
libxml_doc = XML::Parser.string(xml).parse
name = libxml_doc.find("//name").first&.content

Ne transformez pas un ancien benchmark en légende du type « Nokogiri contre Ox ». Un test équitable tient compte de Ruby, des options du compilateur, des versions des bibliothèques natives, de la structure du document, de l’encodage, du temps de préchauffage, du nombre de répétitions, ainsi que du fait que l’on mesure la construction de l’arborescence, les requêtes, la sérialisation ou le streaming. Indiquez séparément le débit, la latence, les allocations et la mémoire maximale utilisée.

La documentation fournie signale d’éventuelles limitations d’Ox concernant XPath, les espaces de noms et XSLT, ainsi qu’une chaîne de dépendances natives pour LibXML Ruby. Vérifiez ces deux points avant de faire votre choix, en particulier pour les intégrations faisant un usage intensif des espaces de noms et les builds de conteneurs portables.

Oga et Hpricot se situent dans une branche du tree de décision où le statut est déterminant. Oga conserve la majeure partie de son implémentation en Ruby, utilise une petite extension et gère le HTML et le XML à l’aide d’XPath ainsi que de requêtes XML tenant compte des espaces de noms. Hpricot est principalement axé sur le HTML, bien que les informations fournies indiquent qu’il peut accepter le XML et propose des sélecteurs CSS et XPath.

Les informations disponibles indiquent également une activité récente limitée pour Oga et précisent que Hpricot n’est plus maintenu, mais il ne s’agit pas de vérifications officielles à jour. Avant d’adopter l’un ou l’autre, examinez la dernière version, la prise en charge de Ruby, les problèmes de compatibilité et vérifiez si votre cible peut compiler son extension.

Pour les applications existantes, le risque lié au remplacement peut justifier l’utilisation d’un adaptateur protégé par des fixtures. Pour une nouvelle application, exigez un test de compatibilité concluant et la désignation explicite d’un responsable de la maintenance avant de choisir l’un ou l’autre comme alternative à Nokogiri.

Selenium est un outil d’automatisation de navigateur, et non un analyseur HTML Ruby ordinaire. Utilisez-le lorsque JavaScript crée le DOM requis, ou lorsque le flux de travail doit cliquer, faire défiler, valider des formulaires ou préserver l’état du navigateur. La documentation officielle de Selenium WebDriver explique son modèle de contrôle du navigateur.

Commencez par une requête HTTP associée à un analyseur. Si une réponse enregistrée ne contient pas les données visibles dans un navigateur, transférez uniquement le rendu ou l’interaction vers Selenium. Extrayez ensuite les données à l’aide de localisateurs ou transmettez le code source de la page rendue à Nokogiri pour un traitement CSS ou XPath.

Cela ajoute des processus de navigateur, la gestion des pilotes, des temps d’attente et davantage de modes de défaillance. La sémantique actuelle des temps d’attente et la configuration des pilotes dépendent de la version ; vérifiez-les donc plutôt que de reprendre d’anciennes recommandations. Ne payez pas ce surcoût pour un balisage statique qu’un client HTTP renvoie déjà.

Pour l’analyse de données en production, utilisez un contrat d’entrée et de sortie explicite :

1. Recevez ou récupérez les octets, puis enregistrez l’URL finale, le statut, le type de contenu et le jeu de caractères déclaré.
2. Déterminez l’encodage avant l’exécution des sélecteurs. Conservez les octets d’origine en cas de transcodage ou si une entrée mal formée nécessite une analyse.
3. Effectuez l’analyse dans le mode choisi : tolérance HTML, XML strict ou streaming.
4. Extrayez les champs à l’aide de sélecteurs qui gèrent délibérément les nœuds manquants.
5. Validez les champs obligatoires, les types, les espaces de noms ou les schémas avant de générer un enregistrement.
6. Enregistrez des fixtures représentatives, y compris des balises mal formées, des mises en page modifiées, des champs vides et des échantillons non UTF-8.
7. Exécutez des tests de sélecteurs sur ces fixtures à chaque mise à jour du parseur ou des dépendances.

def extract_title(html)
  doc = Nokogiri::HTML.parse(html)
  title = doc.at_css("article h1")&.text&.strip
  raise KeyError, "article h1 missing" if title.to_s.empty?
  { title: title }
end

Consigner les erreurs d’analyse dans un contexte sécurisé par les fixtures, et non dans l’intégralité des documents sensibles. Traiter le XML non fiable comme un examen de sécurité distinct, plutôt que de supposer que les paramètres par défaut de l’analyseur sont sûrs.

Avant d’adopter ces analyseurs HTML et XML en Ruby, répondez aux questions suivantes :

• L'entrée est-elle du HTML statique, du HTML mal formé, du XML strict ou un DOM rendu par un navigateur ?
• Le document tient-il en mémoire, ou les enregistrements doivent-ils être traités en flux ?
• Le CSS, XPath, les espaces de noms, la validation ou le XSLT sont-ils requis ?
• La sérialisation d’objets fait-elle partie de la charge de travail ?
• Quelles bibliothèques natives, quels compilateurs, navigateurs ou pilotes doivent être fournis ?
• Le gem concerné a-t-il été testé avec la version cible de Ruby et le système d’exploitation cible ?
• Cet outil est-il une dépendance héritée qui devrait être placée derrière un adaptateur ?
• Les fixtures enregistrées prennent-elles en charge l’encodage, les entrées mal formées, les sélecteurs manquants et les mises à niveau ?

Le meilleur analyseur XML ou HTML pour Ruby est celui qui répond à ces contraintes avec le temps d'exécution fiable le plus court.

• Classez la charge de travail avant de choisir un gem : le HTML statique, le XML strict, le XML en flux, la sérialisation d’objets et les pages rendues nécessitent des outils différents.
• Conservez la récupération, l’authentification, le rendu et l’analyse en tant qu’étapes distinctes du pipeline afin que les échecs soient attribués à la bonne couche.
• Vérifiez les versions actuelles, les dépendances natives et la prise en charge des plateformes avec la version exacte de Ruby et l’image de déploiement que vous utiliserez.
• Effectuez des tests de performance sur des données de test représentatives et testez les sélecteurs, les nœuds manquants, les encodages et les entrées mal formées avant de considérer un analyseur comme prêt pour la production.

Non. Nokogiri analyse la chaîne HTML ou XML qui lui est fournie et n’exécute pas les scripts de la page. Récupérez le DOM rendu à l’aide d’un outil de navigateur lorsque JavaScript crée l’élément cible, puis interrogez directement ce DOM ou transmettez le code source de la page à Nokogiri. Si un point de terminaison renvoie les mêmes données au format JSON ou HTML, il est généralement plus simple d’utiliser cette réponse que de contrôler le navigateur.

Utilisez le mode streaming ou SAX lorsque les documents sont trop volumineux pour permettre une construction aisée de l’arborescence ou lorsque chaque enregistrement peut être traité une seule fois dans l’ordre. Cela fonctionne bien pour les flux, les exportations et les transformations qui génèrent des résultats de manière incrémentielle. Privilégiez un DOM lorsque l’extraction nécessite une navigation arbitraire, des requêtes répétées ou des modifications dans des parties éloignées du document.

Considérez ces deux options comme des choix dépendant du contexte plutôt que comme des valeurs par défaut automatiques. Avant de les adopter, vérifiez qu’il s’agit d’une version récente, que votre version de Ruby est prise en charge, que la compilation réussit sur toutes les cibles de déploiement et que la réponse aux problèmes est satisfaisante. Un petit test de compatibilité devrait analyser vos fixtures réels et tester les espaces de noms, les entrées mal formées et les sélecteurs. Le code existant peut justifier le maintien derrière un adaptateur, même si une nouvelle version ferait un choix différent.

Une comparaison équitable nécessite tout d’abord un comportement identique en termes de sortie et d’échec, car une récupération plus rapide n’a aucun sens si les analyseurs construisent des arbres différents. Utilisez des groupes de fixtures distincts pour les petits documents, les grands documents, les espaces de noms, les entrées mal formées, le streaming et la sérialisation. Rendez compte de la distribution des résultats plutôt que d’un seul meilleur résultat, incluez les effets du ramasse-miettes et publiez le harnais de test afin qu’un autre ingénieur puisse reproduire le test.

Le choix entre les analyseurs HTML et XML pour Ruby devient beaucoup plus simple une fois que la charge de travail est clairement définie. Nokogiri constitue le point de départ pratique et polyvalent pour le traitement du HTML et des structures mixtes basées sur des arbres. Ox mérite d’être évalué pour la sérialisation XML et le traitement d’événements, tandis que LibXML Ruby convient aux pipelines XML nécessitant des fonctionnalités XPath, de validation ou de transformation. Oga et Hpricot nécessitent des contrôles de maintenance et de compatibilité plus rigoureux, et Selenium n’a sa place que lorsque le rendu ou l’interaction sont véritablement requis.

Quel que soit votre choix, maintenez l’analyseur derrière une interface restreinte. Conservez les données brutes, testez les sélecteurs et le comportement en cas de nœuds manquants, consignez les hypothèses d’encodage et identifiez les détails d’exécution qui affectent les extensions natives. Effectuez des tests de performance sur vos propres documents plutôt que de vous fier au classement de vitesse établi par d’autres.

La récupération peut finir par s’avérer plus difficile que l’analyse. Si les requêtes bloquées, les CAPTCHA ou la rotation des proxys grèvent le budget d’ingénierie, l’API Scraper de WebScrapingAPI peut renvoyer du HTML brut tout en gérant ce travail au niveau de la couche de requêtes, permettant ainsi à votre code Ruby de se concentrer sur une étape d’extraction réduite et testable. C’est là la délimitation la plus claire : la récupération produit un balisage fiable, et l’analyseur sélectionné le transforme en données validées.