Kage - un outil pour supprimer JavaScript d’un site web et l’archiver hors ligne

 (github.com/tamnd)
2 points par GN⁺ 2 시간 전 | 1 commentaires | Partager sur WhatsApp
  • Rend la page avec Chrome headless pour capturer un instantané du DOM final tel qu’un humain le verrait, puis supprime tout le JavaScript et télécharge CSS, images et polices vers des chemins locaux afin de créer une copie statique fonctionnant sans code
  • Résout le problème des pages enregistrées via « Save As » qui, avec le temps, finissent en écran vide, spinner figé ou tentatives de connexion à des serveurs d’analytics disparus
    • Fournit un fichier .html qui s’ouvre directement depuis le disque, sans suivi, appels réseau ni comportements inattendus
  • Utilise un crawl en largeur d’abord pour lire robots.txt, prendre ses points de départ dans sitemap.xml et rester sur l’hôte seed
    • Grâce à sa propriété idempotente, récupère une même page une seule fois, qu’il s’agisse de http ou https, avec ou sans slash final
    • Enregistre sa position avec Ctrl-C et reprend au redémarrage, avec --refresh pour rerendre et --force pour repartir de zéro
  • Fournit des flags de contrôle de la portée et du comportement du crawl comme --max-pages, --max-depth, --scope-prefix, --subdomains, --scroll, --workers
  • Avec kage pack, compresse la copie en un fichier unique, au choix sous forme d’archive ZIM ou d’exécutable autonome qui se comporte comme le site lui-même
    • ZIM est compatible avec l’écosystème Kiwix et peut être consulté via kiwix-serve ou les applications Kiwix desktop et mobile
    • Le binaire autonome ne demande aucune installation au destinataire, et --base permet de générer un viewer pour un autre OS (environ 13 MiB + la taille du site)
  • Grâce au packing déterministe, une même copie produit toujours un fichier byte-identical, et l’UUID de l’archive est dérivé du contenu, ce qui le rend sûr pour les checksums et le cache
  • Construit avec le tag webview, utilise la WebView de l’OS (WKWebView, WebView2, WebKitGTK) pour s’ouvrir dans sa propre fenêtre plutôt que dans un onglet de navigateur
  • Pipeline de traitement : URL seed → rendu headless Chrome → instantané du DOM final → suppression du JS → localisation des assets → écriture sur disque
  • Licence MIT

À lire aussi

1 commentaires

 
GN⁺ 2 시간 전
Avis sur Hacker News

  • Le GIF de démo du README m’a intrigué, alors je suis allé voir comment il avait été généré : https://github.com/tamnd/kage/blob/01e75b87ecc893bbba7943c63...
    Il s’avère qu’il utilise un autre projet du même auteur : https://github.com/tamnd/ascii-gif
    Le script utilisé pour la démo est ici : https://github.com/tamnd/kage/blob/01e75b87ecc893bbba7943c63..., avec la méthode d’exécution indiquée en commentaire : ascii-gif render docs/demo/kage.tape -o docs/static/demo.gif
    On dirait un wrapper très orienté préférence autour de https://github.com/charmbracelet/vhs

    • Avez-vous entendu la bonne parole d’asciinema, le sauveur du terminal : https://asciinema.org/
    • J’ai aussi pas mal de binaires personnels de ce genre dans mon $HOME/bin/. Des choses comme delete-all-npm, clean-rust-cache, download-youtube-playlist, get-markdown, et c’est pratique parce qu’il n’y a pas besoin de retenir les commandes
      Parfois, les agents de code trouvent même tout seuls comment appeler ce type d’outils
    • On peut aussi faire ça en SVG animé au lieu d’un GIF, et comme ce ne sont que des keyframes textuelles, c’est bien plus léger qu’un GIF : https://github.com/vytskalt/pseudoc/blob/main/assets/factori...
    • À noter que sur d’autres plateformes, Windows/macOS, LiceCAP est un excellent outil pour enregistrer l’écran en petits GIF. C’est fait par l’auteur de Winamp et du DAW Reaper : https://www.cockos.com/licecap/
    • VHS est excellent pour scénariser la génération de vidéos en ligne de commande

  • Je pourrais utiliser ça pour rendre un wiki d’entreprise facilement accessible hors ligne. Par exemple, il peut y avoir dans le wiki de la documentation utile sur un site de terrain où le réseau mobile ne passe pas
    Le fait de pouvoir empaqueter tout le site dans un binaire unique est sympa, mais une version ne nécessitant pas de processus de service séparé serait particulièrement bien
    On pourrait aussi imaginer quelque chose comme un shim avec un unique point d’entrée HTML contenant un peu de JavaScript pour parcourir une archive du contenu du site, idéalement embarquée

    • Le publier sur Hacker News était exactement ce qu’il fallait. Je vais réfléchir à la possibilité d’implémenter l’idée
      J’ai déjà en tête un script/programme qui convertit le HTML en Markdown, donc on pourrait en pratique tout enregistrer sur disque sous forme de dossier de fichiers Markdown, puis le commit dans un dépôt Git

  • C’est excellent. Je voulais récupérer hors ligne une copie d’un prototype créé par quelqu’un sur Lovable ou un outil du même genre, afin de pouvoir le versionner et le partager dans un format plus simple
    On a décrit notre approche ici : https://productnow.ai/blogs/extracting-html-from-ai-prototyp...
    Je vais regarder ça maintenant pour voir si je peux en modifier certaines parties. J’aime bien l’idée du miroir hors ligne, et ça simplifie beaucoup les cas d’usage liés à la collaboration

  • Il est indiqué kage serve $HOME/data/kage/paulgraham.com, mais si le résultat est statique, je ne vois pas pourquoi un serveur est nécessaire. On ne pourrait pas faire en sorte que ça s’ouvre directement dans le navigateur ?
    Si on pouvait faire quelque chose comme $ firefox $HOME/data/kage/paulgraham.com, le résultat serait utilisable même sur une machine où kage n’est pas installé

    • À la place, on devrait pouvoir utiliser python -m http.server. Je n’ai pas encore essayé, mais ça devrait marcher
      En fait, Kage a deux parties. L’une est un crawler qui capture le DOM après le rendu par Chrome/Chromium, explore les pages et les transforme en HTML propre, et l’autre est le composant pack/serve qui empaquette le résultat en fichier ZIM pour Kiwix ou en exécutable
    • En général, charger une page de cette manière fait que JavaScript est bloqué
    • Il est aussi très probable qu’on se heurte à énormément de problèmes de CORS

  • Je considère que SingleFile [0] est une version bien plus robuste de ça
    Il supprime aussi tout le JavaScript, mais regroupe l’ensemble dans un fichier HTML unique facile à transmettre. Les ressources binaires comme les polices web ou les images y sont intégrées sous forme de chaînes base64
    Il fournit aussi une CLI basée sur Puppeteer [1]
    [0]: https://github.com/gildas-lormeau/singlefile
    [1]: https://github.com/gildas-lormeau/single-file-cli

    • Ce dépôt semble ne sauvegarder qu’une seule page web
      Ici, ce qui est en cours d’implémentation, c’est le miroir d’un site web entier, y compris les sous-pages, pour pouvoir tout parcourir hors ligne. Par exemple, toutes les dissertations de paulgraham.com
    • J’aime vraiment beaucoup SingleFile. L’extension Firefox fonctionne plutôt bien pour faire des sauvegardes propres
      Cela dit, si Kage peut combiner une qualité de restitution au niveau de SingleFile avec une approche de spidering façon HTTrack, ça semble prometteur. Les single-page apps sont un peu délicates à archiver, donc je me demande à quel point Kage les gérera bien
    • Merci pour le lien. Je vais essayer d’implémenter cette fonction de HTML unique. Ça me semble utile à avoir
    • Quelle est la différence avec faire File -> Save as dans n’importe quel navigateur web sur un ordinateur ?
    • C’est aussi ce à quoi j’ai pensé au début, et je trouve que c’est une solution très élégante. Ce n’est pas inutilement complexe

  • J’ai essayé de dupliquer un site en HTTP, donc pas en HTTPS, mais j’obtiens navigation failed: net::ERR_NAME_NOT_RESOLVED. C’était pareil même en précisant le protocole avec http://

  • J’utilise httrack(https://www.httrack.com) quand je télécharge des wikis pour les lire en avion. Ce n’est pas parfait, mais c’était mieux que ce que j’avais trouvé avant
    Je vais aussi essayer ça, et je serais vraiment ravi si le résultat est bon

    • Que de souvenirs. Il y a une vingtaine d’années, Internet passait encore par un accès téléphonique coûteux, alors j’allais au cybercafé télécharger des sites web et des mangas avec HTTrack, puis je copiais tout sur une clé USB de 128 Mo — énorme à l’époque — avant de rentrer chez moi pour lire tout ça hors ligne
    • Pour les wikis en particulier, y a-t-il une raison de ne pas utiliser Kiwix ? En dehors des releases « officielles », c’est plus compliqué, mais il existe des services qui génèrent des fichiers ZIM. L’application de lecture desktop a été plutôt bonne d’après mon expérience
      https://wiki.openzim.org/wiki/Build_your_ZIM_file
      EDIT: https://get.kiwix.org/en/solutions/applications/kiwix-reader...
    • https://github.com/archiveteam/grab-site ou browsertrix peuvent être plus faciles à utiliser pour certaines personnes. Ce sont des outils qui ont été utilisés pour sauvegarder en masse des contenus de data.gov avant leur disparition

  • J’ai accumulé pas mal d’archives de vieux sites web au fil des années. Ce qui est intéressant, c’est que des dumps HTML moches se sont révélés plus utiles que des archives « parfaites »
    C’est aussi l’une des raisons pour lesquelles j’aime de plus en plus les flux RSS. Des flux vieux d’une dizaine d’années sont souvent plus faciles à utiliser aujourd’hui que des sites web conçus comme des applications et soigneusement préservés

    • Je travaille sur un projet qui génère des flux RSS et les archive. Il conserve l’historique complet à partir du moment où le crawler a démarré
      Je vais encore un peu nettoyer tout ça puis le publier bientôt en open source

  • Ça semble pouvoir mettre une charge assez importante sur le site. Y a-t-il un réglage pour limiter la vitesse de duplication ou éviter les images/vidéos ?
    Je me demande aussi s’il existe un moyen de ne récupérer qu’une partie du site

    • Peux-tu créer ça comme un nouvel issue ? Je m’en occuperai plus tard. Il est 1 h du matin dans mon fuseau horaire, mais je suis content que ça intéresse quelqu’un
    • Il suffit de prétendre que c’est un crawler IA et le problème est réglé

  • Projet propre, et j’aime bien l’idée
    En le parcourant rapidement, j’ai vu que Chrome était lancé avec --no-sandbox ; y a-t-il une raison particulière ? Du point de vue sécurité, ce n’est probablement pas une bonne idée. S’il n’y a pas de raison, je recommanderais de laisser le sandbox activé
    En tout cas, beau travail

    • --no-sandbox est nécessaire dans Docker. C’est peut-être simplement parce qu’il part du principe que ça sera exécuté surtout dans Docker ?