newspaper4k : résultats sur 22/22 jeux de tests contrôlés

Sur un jeu de tests annoté et centré sur les articles, newspaper4k a produit une sortie pour les 22 fixtures, a récupéré 98,65 % des unités d’article scorées, et n’a inclus aucun des tokens de boilerplate étiquetés. Ces trois critères en font un bon candidat au regard des priorités de ce test ; ils ne suffisent toutefois pas à en faire un gagnant universel.

Aucun autre outil de cet ensemble n’a réuni ces trois résultats en même temps. Mozilla Readability a récupéré toutes les unités de contenu scorées, mais a conservé davantage de boilerplate étiqueté ; goose3 n’a inclus aucun boilerplate étiqueté, mais a renvoyé deux chaînes vides. D’autres règles de décision peuvent donc tout à fait faire pencher la balance vers une autre bibliothèque.

Un défaut de récupération mérite d’être signalé clairement avant tout déploiement.

Qu’est-ce que newspaper4k ?

newspaper4k est un fork maintenu de newspaper3k, lui-même la continuation sous Python 3 du projet original newspaper. Cette filiation compte quand tu cherches de l’aide, parce que la plupart des ressources en ligne renvoient à son ancêtre et qu’une partie de son API a évolué.

Référence officielle : dépôt officiel de newspaper4k.

L’erreur la plus fréquente avec cette bibliothèque, par exemple, consiste à utiliser set_html(). Cette méthode n’existe pas. Le HTML doit être passé via download() :

from newspaper import Article
a = Article(url="https://example.com/story")
a.download(input_html=html)     # not set_html()
a.parse()
text = a.text

Je m’étais trompé de cette façon lors de mon premier essai et j’avais noté la bibliothèque 0 sur 22 avant de vérifier si l’erreur venait de moi. C’était bien le cas.

La sortie ne se limite pas au texte. L’objet Article expose des champs comme text, title, authors, publish_date, top_image, images, movies, meta_description, meta_lang, tags et article_html. Les champs keywords et summary nécessitent l’installation NLP optionnelle et la configuration du corpus décrite plus bas. Les champs ont été inventoriés, mais la précision des métadonnées n’a pas été évaluée.

Version testée : 0.9.6, licence MIT, 1 135 étoiles GitHub, avec un push du dépôt daté du 2026-07-31. Cette activité datée n’est qu’un instantané, pas une évaluation complète de la santé de maintenance. Python 3.14.2.

Le résultat

sixway-scores.json. Chaque unité dans chaque fixture porte un jeton sentinelle unique, de sorte que « recovered » et « leaked » correspondent à une appartenance exacte à une sous-chaîne, et non à un score de similarité. Le rappel est calculé sur les 22 fixtures ; la fuite et la précision sur les 11 contenant à la fois du contenu d’article et du boilerplate.

Trois colonnes méritent d’être mises en avant.

Il a répondu sur chaque page. Ce n’est pas le cas de goose3 ni de jusText — 20 et 19 sur 22. Cela compte plus qu’il n’y paraît, parce que la précision et le F1 d’un tableau comme celui-ci sont conditionnels à la production d’une sortie : une bibliothèque qui renvoie une chaîne vide n’influence aucun des deux côtés du ratio, donc l’absence de sortie est “gratuite”. La précision de 1.0000 de goose3 a été mesurée sur 10 des 11 fixtures ; celle de newspaper4k, à 0.9452, sur 11 des 11. Ce ne sont pas exactement les mêmes mesures.

Il n’a rien laissé fuiter. Les fixtures incluent volontairement du boilerplate adversarial — des blocs promotionnels à classe neutre placés à côté de l’article, des fils de commentaires avec des noms de classes anodins, des blocs publicitaires qui ne disent pas « ad ». Le mécanisme d’assemblage par frères de Readability en a absorbé plusieurs ; newspaper4k n’en a conservé aucun.

Il n’a raté qu’une unité sur 74, et celle qu’il a manquée est partagée.

L’oubli concerne la fixture non prose — une page construite à partir de tableaux, d’un bloc de code, de courts éléments et d’une légende d’image plutôt que de paragraphes — et l’unité perdue est la légende. newspaper4k n’est pas seul dans ce cas :

Trois bibliothèques perdent exactement la même légende, et aucune autre unité, ce qui fait penser moins à trois bugs distincts qu’à une hypothèse héritée commune sur ce qu’une légende est censée valoir. Si ton contenu relève de la documentation, de recettes ou de tout autre format où la légende apporte une information que le paragraphe ne donne pas, ça mérite d’être testé avant de trancher — et Readability comme jusText l’ont toutes deux conservée.

La même fixture est aussi celle où goose3 s’écroule complètement, en perdant les trois quarts de la page ; le contenu non prose est donc un axe sur lequel ces six outils diffèrent bien davantage que ne le laisse croire le tableau principal.

Côté vitesse, la médiane d’extraction de newspaper4k sur les 22 fixtures était de 2,69 ms, la plus lente des six, avec un pire cas à 199,81 ms. Face à la médiane de 0,06 ms de resiliparse, cela représente un écart de 45× dans cette exécution contrôlée. La médiane peut être négligeable dans un flux à page unique, mais le débit et la latence en queue sous charge n’ont pas été testés. L’import à froid est mesuré plus bas séparément.

Le défaut que je changerais dès la première ligne

Référence officielle : documentation newspaper4k.

En lisant l’objet Configuration fourni, on trouve vingt-deux paramètres. L’un d’eux est celui-ci :

_honor_robotstxt = False

newspaper4k ne respecte pas robots.txt tant que tu ne le lui demandes pas. Si tu le laisses récupérer la page — Article(url).download() sans input_html — il ira chercher ce que tu lui indiques, sans tenir compte du fichier robots du site.

C’est un choix défendable pour une bibliothèque dont l’usage principal est d’analyser du HTML déjà en main, mais c’en est un bien moins acceptable à découvrir en production après lui avoir donné mille URLs. Défini honor_robotstxt=True dans ta Configuration, ou transmets input_html et gère toi-même la récupération, ce que j’ai fait tout au long de ce test.

Deux autres points méritent d’être connus :

number_threads = 10. Le parallélisme par défaut de ses assistants multi-articles est de dix. La concurrence n’est pas un débit par seconde, mais elle peut déclencher une rafale de requêtes simultanées si tu ne définis pas de limites par hôte et de planification explicites.

fetch_images = True. La récupération des images est activée par défaut, ce qui pose la question de l’usage hors ligne. Avec socket.connect bloqué, le chemin testé de newspaper4k 0.9.6 — download(input_html=…) suivi de parse() sur une entrée HTML gardée en mémoire — s’est terminé correctement, a renvoyé 1 292 caractères et n’a tenté zéro connexion réseau. Cela valide ce chemin précis, pas toutes les configurations, tous les plugins, tous les types de contenu ni les futures versions.

Le reste est cohérent : min_word_count 300, min_sent_count 7, max_text 100 000, http_success_only True, memorize_articles True, follow_meta_refresh False, allow_binary_content False.

Réalité de l’installation

pip install newspaper4k installe 22 paquets et 47,5 MiB en environ six secondes. Import à froid dans un sous-processus neuf : 2,812 s — le plus lent de la comparaison.

install-and-import.json. Chaque bibliothèque est placée dans son propre virtualenv vide, de sorte qu’aucune ne hérite des dépendances d’une voisine.

2,812 secondes pour importer, c’est 187 fois les 15 millisecondes de resiliparse. Dans un worker longue durée, tu ne paies ce coût qu’une fois et il devient négligeable. Dans une fonction serverless, tu le paies à chaque démarrage à froid, et c’est précisément le cas où newspaper4k est le mauvais choix, quelle que soit la qualité de son extraction.

Un point à noter à l’installation. L’import affiche un avertissement :

UserWarning: nltk is not installed. Some NLP features will be unavailable. Install it with: pip install 'newspaper4k[nlp]'

Aucune fonctionnalité de ce test n’en avait besoin et l’extraction a parfaitement fonctionné sans elles, mais l’installation de base n’est pas l’installation complète, et newspaper4k[nlp] ajoute un arbre de dépendances nettement plus lourd ainsi que des téléchargements de corpus. Ne prévois ce surcoût que si tu veux les mots-clés et les résumés.

Mémoire, et effet du HTML cassé

Deux aspects que chaque revue de ce lot indiquait comme non testés sont désormais mesurés.

Le contexte plus large du stress test se trouve dans la comparaison mémoire et HTML mal formé de dix bibliothèques.

Pic de mémoire résidente, via /usr/bin/time -l, un processus neuf par cellule — le plancher d’import correspond au coût de la bibliothèque chargée mais inactive, les pics incluent le document.

memory-results.json. Les bases Python et Node ne sont pas comparables entre elles ; l’interpréteur est inclus dans les deux.

Le plancher de newspaper4k est de 52,6 MiB et son pic sur 10 MB atteint 668,5 MiB — le deuxième plus lourd des bibliothèques Python. Aucun de ces chiffres n’est problématique pour des pages ordinaires ; ils deviennent importants si tu traites en lot de gros documents dans un worker à mémoire limitée.

HTML cassé. Douze documents cassant chacun une seule chose — balises non fermées, éléments inline mal imbriqués, attributs non quotés avec des espaces, fermetures parasites, absence totale de <html>, attributs dupliqués, document tronqué au milieu d’une balise, entités incorrectes, <script> non fermé, déclaration de charset mensongère, commentaire contenant du balisage, et 600 niveaux d’imbrication — auxquels s’ajoutent deux contrôles bien formés de taille comparable, car « il n’a rien renvoyé » ne dit quelque chose sur le malformedness que si la bibliothèque reste aussi muette sur un document propre de même taille.

Les contrôles et les cas mal formés se distinguent clairement dans les résultats bruts :

Les deux contrôles ont produit 70 et 1 351 caractères, tandis que dix des douze entrées mal formées ont renvoyé une chaîne vide. La disparition peut donc être attribuée au malformedness dans ce design de fixtures, et non simplement à une entrée courte. Le scoreur vérifie les sentinelles de titre, de paragraphe et de lien sur les onze documents mal formés éligibles. La fixture du <script> non fermé est exclue car, avec le parsing HTML5, le balisage qui suit reste du contenu de script. Voir malformed-results.json. Il s’agit d’une vraie limite de récupération à prendre en compte dans le choix, et non d’un simple succès du type « n’a pas levé d’exception ».

Avantages et inconvénients

En sa faveur. Aucun token de boilerplate étiqueté dans cette comparaison, une sortie sur les 22 fixtures d’articles contrôlées, et un rappel scoré de 0,9865 sur le contenu article. Il expose le texte de l’article ainsi que des champs de métadonnées, même si la précision des métadonnées n’a pas été testée. Le chemin testé avec HTML en mémoire n’a tenté aucune connexion réseau lorsque socket.connect était bloqué. Le dépôt avait récemment reçu un push daté lors de la vérification ; la santé globale de la maintenance n’a pas été évaluée.

Contre lui. L’import à froid le plus lourd de l’ensemble, à 2,812 s et 22 paquets / 47,5 MiB de site-packages mesurés. honor_robotstxt vaut False par défaut, et les assistants multi-articles utilisent dix threads par défaut. L’installation de base avertit de l’absence de NLTK, donc les mots-clés et les résumés exigent une installation optionnelle plus lourde. Surtout, dix des douze fixtures mal formées ont renvoyé une sortie vide alors que les deux contrôles bien formés de taille équivalente produisaient du texte.

Qui devrait l’utiliser, et qui devrait l’éviter

Considère newspaper4k si ton ordre de priorité est le suivant : produire du texte non vide sur un corpus contrôlé orienté article, minimiser le boilerplate étiqueté dans ce corpus, et accepter un import à froid plus lent. Selon cette règle explicite, il ressort en tête de cette comparaison. Une autre règle peut préférer Readability pour maximiser la conservation scorée du contenu, ou resiliparse pour le démarrage et la vitesse médiane d’extraction.

Évite-le ou teste-le avec beaucoup de soin si le temps de démarrage à froid domine, si 47,5 MiB de site-packages mesurés est un facteur important, ou si la récupération sur HTML mal formé compte. Ici, resiliparse importe 187× plus vite, mais il n’égale pas trafilatura sur toutes les colonnes de qualité : trafilatura avait un rappel article plus élevé, tandis que leurs profils de fuite et de précision différaient aussi. newspaper4k est orienté article ; les listes de produits et les tableaux de bord n’ont pas été testés, donc aucun comportement n’est revendiqué pour eux.

Quoi qu’il en soit, définis honor_robotstxt si tu le laisses récupérer des pages. Ce n’est pas une note de performance.

Où une API managée s’intègre

newspaper4k peut analyser du HTML fourni par l’appelant et dispose aussi de chemins de récupération. Une solution d’extraction managée place l’acquisition, le rendu et la structuration derrière la frontière d’un fournisseur. Nous construisons Thunderbit, mais il n’a pas été exécuté sur ce jeu de tests ; cette revue ne permet donc aucune comparaison de qualité, de rendu, d’anti-bot, de latence ou de coût. Pour du HTML d’article fourni, les éléments de preuve ici concernent newspaper4k seul ; les cibles non article doivent faire l’objet de leur propre évaluation.

Pour les mêmes fixtures, comparées sur les six extracteurs, voir la comparaison des six bibliothèques d’extraction.

Pour l’offre hébergée, notre tour d’horizon des API de web scraping donne une vue plus large ; pour les alternatives auto-hébergées, le pilier des scrapers open source. Si le texte doit ensuite être envoyé à un modèle, convertir du HTML en Markdown en Python explique où la fidélité se perd.

Essayez Thunderbit pour l’extraction de données web

Faut-il utiliser newspaper4k ?

Considère newspaper4k comme un candidat solide pour l’extraction de texte d’article lorsque le HTML est déjà disponible, puis fais un test comparatif sur ton propre corpus avant de l’adopter. L’ensemble contrôlé montre un rappel élevé sur le contenu article, aucun boilerplate étiqueté, et une sortie non vide sur les 22 fixtures orientées article. Il ne couvre ni les pages réelles ni la précision des métadonnées, et dix des douze fixtures mal formées ont renvoyé une sortie vide.

Si tu utilises son chemin de récupération, examine explicitement honor_robotstxt=False, le parallélisme à dix threads et les limites de débit par hôte. Si le démarrage à froid ou l’empreinte de dépendances compte, mesure dans ton déploiement l’import local à 2,812 secondes et les 47,5 MiB de site-packages observés, au lieu de les considérer comme des coûts de conteneur universels.

Essayez Thunderbit pour l’extraction de données web Get Started Free

FAQ

Pourquoi set_html() ne fonctionne-t-il pas ? Parce que cette méthode n’existe pas dans newspaper4k. Le HTML doit être passé via download(input_html=html), puis parse(). Les résultats de recherche peuvent afficher des exemples pour newspaper3k, ce qui rend l’erreur facile à faire ; je l’ai faite au premier essai et j’ai corrigé le banc de test avant le scoring.

newspaper4k respecte-t-il robots.txt ? Pas par défaut. honor_robotstxt est livré à False. Mets-le à True dans ta Configuration si tu laisses la bibliothèque récupérer les pages, ou passe input_html et effectue toi-même la récupération. Le travail multi-articles utilise aussi dix threads par défaut. Il s’agit d’un parallélisme non choisi, pas d’un débit fixe ; définis des limites explicites par hôte pour la récupération.

parse() effectue-t-il des requêtes réseau ? Sur newspaper4k 0.9.6, le chemin testé download(input_html=…) puis parse() n’a tenté aucune connexion pour une entrée HTML gardée en mémoire alors que socket.connect était bloqué. Cela ne prouve pas que toutes les configurations d’analyse, tous les plugins, tous les types de contenu ou les futures versions soient exempts de réseau.

Quelle est l’alerte NLTK à l’import ? L’installation de base n’inclut pas NLTK, donc l’extraction de mots-clés et la génération de résumés ne sont pas disponibles, et la bibliothèque le signale à l’import. L’extraction elle-même n’est pas affectée — tout ce qui a été mesuré ici tournait sur l’installation de base. pip install 'newspaper4k[nlp]' les ajoute avec un arbre de dépendances plus lourd et des téléchargements de corpus.

Qu’est-ce que cette revue n’a pas testé ? Les pages réelles — ici, il s’agit de fixtures contrôlées avec unités étiquetées. Les champs de métadonnées ont été inventoriés, mais pas scorés pour la précision du titre, de l’auteur, de la date ou des images. L’extraction multilingue, les options NLP, le crawling multi-thread des sources et le débit sous charge n’ont pas non plus été testés. Le pic mémoire du processus a été mesuré sur une entrée HTML de 226 KB et une autre de 10 MB, pas en concurrence ni sous charge soutenue.