Créer un extracteur du contenu principal des pages web et retrouver le contenu perdu

## Faire fonctionner l’extracteur de la même façon dans chaque environnement Concevez l’extracteur autour d’une interface de document stable plutôt que d’une implémentation particulière de navigateur. Répertoriez tous les environnements pris en charge et leurs contraintes avant de modifier le comportement d’analyse partagé. - Les versions pour navigateur peuvent utiliser le modèle de document natif. - Les versions pour serveur peuvent accepter des documents créés par différentes implémentations du DOM et proposer une API asynchrone. - Les versions en ligne de commande doivent préserver la même sémantique d’extraction tout en proposant des modes lisibles par machine et orientés texte. - Les environnements d’exécution en périphérie peuvent fournir l’implémentation de document la plus contrainte et doivent définir le niveau minimal de compatibilité. - Les points d’entrée des paquets doivent proposer le même comportement public, même si leurs formats de modules diffèrent. Gardez les adaptateurs d’environnement légers. Placez l’analyse, la notation, la normalisation, l’assainissement et les comportements propres aux éléments dans des couches partagées, sauf si une limite de l’environnement d’exécution exige une exception explicite. ## Garder l’ordre des étapes de nettoyage sans le changer pour un seul site Traitez la chaîne d’extraction comme un algorithme ordonné, et non comme un ensemble de fonctions de nettoyage interchangeables. Chaque étape peut créer des hypothèses utilisées par les étapes suivantes. Utilisez cette séquence par défaut : 1. Aplatissez les arbres de documents encapsulés. 2. Résolvez le contenu diffusé en continu ou différé. 3. Détectez le contenu principal automatiquement ou au moyen d’un sélecteur explicite. 4. Normalisez les structures que les règles de suppression pourraient autrement masquer ou éliminer. 5. Convertissez les encadrés reconnus en une représentation sémantique stable. 6. Supprimez les médias trop petits et les éléments masqués. 7. Supprimez les blocs faiblement notés. 8. Appliquez les sélecteurs exacts et partiels visant les éléments parasites. 9. Supprimez les textes répétitifs et les autres motifs de contenu. 10. Normalisez le document restant. 11. Résolvez les liens relatifs et les emplacements des ressources. Documentez pourquoi une étape doit en précéder une autre lorsque la dépendance n’est pas évidente. Ne réordonnez pas les étapes partagées pour corriger un seul site avant qu’un test ciblé ne prouve que le nouvel ordre conserve toutes les représentations intermédiaires nécessaires. ## Utiliser le journal des suppressions pour trouver où le contenu a disparu Fournissez un mode de débogage qui indique la racine de contenu sélectionnée et chaque suppression avec son étape, son sélecteur, sa raison et un texte représentatif. Le mode de débogage peut préserver les attributs de diagnostic et éviter les opérations d’aplatissement de structure qui effaceraient les preuves. Lorsque du contenu attendu disparaît : 1. Recherchez le contenu manquant dans le journal des suppressions. 2. Désactivez une étape à la fois pour identifier la première qui provoque la perte. 3. Si un sélecteur est en cause, distinguez les sélecteurs exacts des sélecteurs à correspondance partielle. 4. Contournez la détection automatique avec un sélecteur explicite lorsque la mauvaise racine a été choisie. 5. Vérifiez que les zones de code protégées ou préformatées sont exclues de la suppression générique. 6. Réactivez toutes les étapes sans rapport avec le problème avant d’accepter la correction. Privilégiez les preuves issues de la première transition incorrecte plutôt que les suppositions fondées sur le document final. Ne désactivez pas définitivement un nettoyage étendu lorsqu’un sélecteur, un ordre ou une règle d’élément ciblés peuvent résoudre le défaut. ## Traiter le HTML de la page comme hostile et bloquer l’injection de scripts Analysez le balisage à l’aide d’un outil sûr de construction de documents qui n’exécute aucun script et ne charge aucune ressource. N’affectez jamais directement un balisage non fiable à un point d’analyse du navigateur. - Retirez des attributs de liens et de médias les schémas d’URL capables d’exécuter des scripts. - Supprimez des cadres le contenu source des documents intégrés. - Supprimez les attributs de gestionnaires d’événements. - Échappez chaque valeur provenant de la page avant de l’insérer dans le balisage généré. - Préférez la création de nœuds et les méthodes d’affectation d’attributs lorsqu’elles rendent explicites les exigences d’échappement. - Assainissez le résultat final comme protection supplémentaire, et non comme substitut à une construction sûre. Supposez que des guillemets contrôlés par un attaquant dans les URL de médias, les textes alternatifs, les images de métadonnées et les descriptions peuvent fermer un attribut et en injecter un autre. Tout extracteur qui génère du balisage doit disposer d’un test hostile d’injection d’attribut. ## Prouver chaque correction avec une petite page de test qui échoue d’abord Pour les défauts d’extraction, créez le plus petit document de test qui reproduit encore l’échec et associez-le au résultat attendu exact. Gardez les échantillons de test déterministes et exempts d’identifiants personnels ou propres à la source. - Remplacez les noms réels, les adresses électroniques, les URL, les identifiants de compte et les textes reconnaissables par des substituts génériques. - N’incluez que la structure nécessaire pour déclencher l’étape défaillante de la chaîne. - Pour les corrections de sécurité, incluez un attribut piégé ou une charge hostile équivalente. - Vérifiez que l’échantillon de test échoue avant d’appliquer la correction. - Appliquez la plus petite modification de comportement qui permet au test de réussir. - Exécutez le test ciblé et l’ensemble partagé des tests d’extraction dans tous les environnements pris en charge. Un échantillon de test qui réussit avant et après la modification de l’implémentation ne prouve pas qu’une régression a été corrigée. S’il est difficile d’annuler la correction, construisez le résultat attendu ou un mécanisme contrôlé afin que l’ancien comportement continue de démontrer son échec. ## Tester les différences de DOM et de bundle dans chaque environnement Testez les comportements limites lorsque les implémentations de documents et les formats de paquets diffèrent, même si l’algorithme partagé reste inchangé. - Convertissez les collections dynamiques d’éléments en tableaux statiques avant de modifier le document. - Vérifiez que les utilitaires nommés restent accessibles lorsqu’un paquet n’expose qu’une exportation par défaut. - Testez les adaptateurs de serveur asynchrones séparément des adaptateurs de navigateur synchrones. - Testez le comportement de l’environnement d’exécution en périphérie par son véritable point de requête au lieu de supposer qu’il est équivalent au navigateur. - Vérifiez les modes texte et structuré de la ligne de commande avec le même ensemble d’échantillons de test. - Limitez aux adaptateurs les solutions de contournement propres à un environnement et couvrez chacune d’elles par un test de compatibilité ciblé. Lorsqu’une correction propre à un environnement modifie le résultat partagé, traitez-la comme un changement de comportement interenvironnements et validez chaque adaptateur pris en charge. Ne laissez pas une solution de contournement du conditionnement redéfinir silencieusement le contrat public de l’extracteur.