Exporter du HTML Autonome depuis Chrome pour l'Importer

Les trois options Enregistrer sous de Chrome, et pourquoi une seule s'en approche

Appuie sur Ctrl+S (Cmd+S sur un Mac) sur n'importe quelle page dans Chrome, et tu obtiens trois choix : Page web, complète ; Page web, HTML uniquement ; et MHTML, fichier unique. Si ton objectif est d'exporter du HTML depuis Chrome comme un seul fichier portable pour un outil d'import, un seul de ces trois noms est honnête sur ce qu'il produit réellement, et ce n'est probablement pas celui que tu devinerais.

Page web, complète écrit le balisage dans un fichier .html et dépose chaque image, feuille de style et script de la page dans un dossier _files juxtaposé. Les deux éléments doivent voyager ensemble. Déplace le fichier .html seul, et chaque référence relative au dossier se casse. Cela l'exclut comme fichier unique autonome. C'est aussi le mode que la plupart choisissent par défaut, puisqu'il arrive en premier dans le menu déroulant.

Page web, HTML uniquement écrit seulement le balisage, sans dossier _files du tout. C'est la plus petite des trois options, et la moins utile ici : chaque référence à une ressource externe reste dans le fichier, pointant vers des images et des feuilles de style qui ne sont plus rattachées. Ouvre-le plus tard, et tu obtiens du texte nu là où se trouvait la page.

Le MHTML paraît autonome. Ce n'est pas du HTML pur

MHTML, fichier unique produit un seul fichier avec tout intégré, ce qui le rend tentant à traiter comme la réponse. En dessous, ce n'est pourtant pas du HTML pur. Le MHTML enveloppe la page dans un encodage MIME multipart/related, la même technique que les navigateurs utilisent pour les pièces jointes des e-mails HTML : un en-tête de style e-mail portant le titre, l'URL source et l'horodatage, suivi du HTML puis de chaque ressource, encodée en base64 et séparée par des chaînes de délimitation. Chrome 86 et les versions ultérieures écrivent ce format via Enregistrer sous. La même sortie est aussi disponible par programmation via la méthode saveAsMHTML de l'API d'extension pageCapture, que la plupart des extensions de capture automatique appellent plutôt que de réimplémenter le format elles-mêmes. Une restriction à connaître : le fichier obtenu ne peut être rouvert que depuis le système de fichiers local, et seulement dans le cadre principal d'un navigateur, jamais dans une iframe.

Pourquoi le MHTML n'est pas le HTML autonome qu'attend un outil d'import

Un outil conçu pour analyser du HTML pur, y compris la zone de dépôt d'UnHTML, lit un fichier .html comme du HTML : des balises, des attributs, un DOM. Un fichier .mhtml n'est pas cela. C'est un conteneur MIME avec une partie HTML enfouie dans des limites encodées en base64, et un analyseur HTML pur ne le décompressera pas correctement. Dépose un fichier .mhtml dans un outil d'import qui attend du HTML autonome, et tu obtiens au mieux rien de lisible.

Il existe un second écart à connaître, même si tu ne rencontres jamais le problème de format. Le JavaScript intégré ne s'exécute pas quand un fichier MHTML est rouvert ; seul le HTML déjà rendu au moment de la capture survit. Pour une page majoritairement statique, cela compte rarement. Pour tout ce qui construit une partie de sa mise en page après le chargement, la capture manque de tout ce qui s'est exécuté après l'instantané.

Si tu as déjà un fichier .mhtml et as besoin de HTML pur à partir de lui, rouvre-le dans Chrome et réenregistre-le avec une vraie extension de fichier unique. N'essaie pas de modifier le conteneur MIME à la main. Firefox ne lit pas du tout le MHTML nativement, donc un fichier .mhtml enregistré sur une machine n'est pas quelque chose que tu peux transmettre en toute sécurité à un collègue utilisant un autre navigateur.

Construire un vrai fichier HTML unique avec tout intégré

Un fichier HTML vraiment autonome intègre son CSS et ses images directement dans le balisage, généralement comme des URI de données en base64, de sorte que le fichier unique ne laisse aucune référence externe susceptible de se casser. Chrome ne fait pas cela nativement. Il n'existe aucun panneau DevTools ni option Enregistrer sous qui parcourt une page et réécrit chaque <img src> et <link rel="stylesheet"> en une URI de données intégrée ; cette étape de conversion appartient à une extension de capture tierce.

Les étapes, dans l'ordre :

1. Charge la page entièrement dans Chrome et fais défiler une fois, afin que toute image ou section à chargement différé se rende dans le DOM avant la capture. Saute cette étape, et ta capture manquera de ce qui n'était pas encore chargé.
2. Lance une extension de capture de fichier unique qui intègre le CSS et les images comme des URI de données, plutôt que l'Enregistrer sous natif de Chrome. La plupart de ces extensions ajoutent un bouton dans la barre d'outils qui déclenche la capture sur l'onglet actif, sans application séparée.
3. Enregistre le résultat comme un seul fichier .html, avec un nom qui aura encore du sens une fois posé dans un dossier de téléchargements à côté d'une douzaine d'autres.
4. Ouvre ce fichier directement depuis le disque, pas via un serveur local, et vérifie que chaque image et style se rend sans référence cassée, sans activité dans l'onglet réseau, et sans rien qui pointe vers le domaine d'origine. Une capture qui contacte encore le site en direct n'est pas vraiment autonome.

Un compromis honnête : l'encodage base64 ajoute environ 33 pour cent à la taille de ce qu'il enveloppe, de sorte qu'un export en fichier unique intégré finit de façon fiable plus volumineux que la somme des ressources séparées d'origine de la page. Une image principale de 200 Ko devient près de 266 Ko une fois transformée en texte base64 dans le HTML. Une poignée de grandes photos peut transformer une page en un fichier de plusieurs mégaoctets de cette façon. C'est le coût de la vraie portabilité, pas un défaut du processus, et il vaut mieux le savoir avant qu'une taille de fichier te surprenne en entrant dans un outil d'import.

Ce qu'une capture statique garde, et ce qu'elle perd

Un export en fichier unique, MHTML ou HTML intégré, fige le DOM au moment de la capture. Tout ce qui est déjà rendu est conservé : texte, mise en page, images déjà chargées, styles déjà appliqués. Tout ce qui se passe après ce moment ne l'est pas, parce qu'aucun script de la page ne s'exécute à nouveau quand le fichier est rouvert hors ligne.

Cette distinction compte surtout sur les pages construites autour d'un comportement côté client : du contenu qui se charge au défilement, des données qui arrivent via une requête différée, ou des vues qui changent avec un routage côté client. Prends un fil à défilement infini comme exemple. Une capture statique n'a que la poignée d'éléments déjà chargés au moment où tu as enregistré, pas le reste du fil qu'un visiteur atteindrait en continuant à faire défiler. Une page marketing majoritairement statique ou un article de documentation s'en sort bien avec un simple Enregistrer sous ; il capture tout ce qui compte. Une application monopage chargée de JavaScript est une autre histoire, et un outil de capture qui pilote une vraie session de navigateur, en attendant que l'activité réseau se stabilise avant de prendre l'instantané, est le meilleur choix ici.

Quand Enregistrer sous ne suffit pas

Deux voies existent en dehors du menu d'export propre à Chrome, et toutes deux méritent d'être connues avant de supposer qu'un Enregistrer sous du navigateur est la seule entrée possible.

Les utilisateurs de Safari ont une quatrième option que Chrome n'a pas : le format .webarchive. Il regroupe le HTML avec son CSS, ses images et son JavaScript liés dans l'un des fichiers de liste de propriétés binaire d'Apple, lisible nativement seulement dans Safari et construit avec un encodage différent de celui du conteneur MIME de MHTML. UnHTML accepte les fichiers .webarchive directement comme alternative au HTML autonome, la voie la plus pratique si tu es déjà sur un Mac et préfères ne pas installer d'extension de capture. Voir enregistrer une page comme archive web Safari pour le guide complet, y compris où macOS place le fichier par défaut.

Pour un site en direct, ou tout ce qui rend sa mise en page avec du JavaScript après le chargement, saute entièrement la boîte de dialogue Enregistrer sous du navigateur. Utilise plutôt la CLI de capture open source ou le bookmarklet. Elle pilote la page comme le ferait une vraie visite, attend que la mise en page se stabilise, puis écrit le résultat sous forme de scene.json plutôt que de fichier HTML, contournant entièrement le problème d'analyse du HTML pur. Le processus pour un site React ou Vue, y compris la façon dont la CLI gère le routage côté client, est couvert dans importer un site React ou Vue dans Figma.

En résumé

Sur les trois options Enregistrer sous de Chrome, aucune ne te fournit un fichier unique prêt à l'emploi comme l'attend un outil d'import de HTML autonome, pas sans étape supplémentaire. Page web, complète se divise en deux éléments qui doivent rester ensemble. Page web, HTML uniquement abandonne les ressources entièrement. MHTML regroupe tout, mais dans un conteneur MIME, pas en HTML pur, et tout JavaScript exécuté après le chargement disparaît de toute façon, peu importe lequel des trois modes a produit le fichier. Pour une page majoritairement statique, la voie fiable est une extension de capture qui intègre le CSS et les images comme des URI de données dans un vrai fichier .html, en acceptant la surcharge base64 d'environ 33 pour cent comme coût de la portabilité. L'archive web Safari et la CLI de capture en direct sont les bons recours quand Enregistrer sous ne peut pas faire le travail : l'archive web si tu es déjà sur un Mac, la CLI si la page rend son contenu avec du JavaScript après le chargement initial. Une fois qu'un import arrive sous forme de calques, voir transformer un import en composants réutilisables pour l'étape suivante. Et si une capture s'avère plus volumineuse que ce que permet le palier gratuit, le palier Pro supprime la limite de 500 calques sur la page des tarifs.