Convertisseur EPUB en TXT

La conversion est assurée par l'outil en ligne de commande ebook-convert de Calibre, invoqué côté serveur sous la forme ebook-convert <entrée.epub> <sortie.txt> avec --txt-output-encoding utf-8 : la sortie est donc toujours en UTF-8, quelle que soit l'encodage déclaré par le fichier d'origine. Le traitement comporte trois étapes.

La première est l'analyse de l'EPUB. Une EPUB est une archive ZIP dont la première entrée est un fichier mimetype non compressé contenant application/epub+zip, suivi de META-INF/container.xml qui pointe vers le fichier .opf à la racine du paquet. Ce fichier .opf comprend trois sections : metadata (titre, auteur, langue et identifiant unique décrits par des éléments Dublin Core), manifest (liste de toutes les ressources du paquet) et spine (définition de l'ordre de lecture). L'analyseur parcourt le spine et charge chaque document XHTML dans l'ordre. C'est pourquoi le texte ressort dans l'ordre de lecture et non dans l'ordre de l'archive : c'est le spine qui définit la séquence, pas le nom des fichiers.

La deuxième étape réduit le XHTML en texte. Le DOM de chaque document est parcouru et seuls les nœuds de texte sont conservés : de chaque élément — <p>, <h1>, <em>, <span>, <div> — il ne reste que son texte, le reste est écarté. Les éléments de bloc sont convertis en sauts de paragraphe, ce qui produit les lignes vides entre les paragraphes dans la sortie ; les styles en ligne sont simplement abandonnés. Les éléments sans contenu textuel, comme <img> et <hr>, disparaissent entièrement. Les liens perdent leur cible mais leur texte d'ancre reste en place : une URL écrite en clair survit, tandis qu'un mot hyperlié perd l'adresse qui le sous-tendait.

La troisième étape sérialise le résultat : les espaces sont normalisés, le texte est écrit dans l'encodage cible, et c'est terminé. Deux conséquences méritent d'être signalées. D'abord, tout contenu qui n'existe que sous forme d'image est perdu : un livre numérisé, une bande dessinée en EPUB à mise en page fixe (rendition:layout=pre-paginated) ou un album illustré n'ont pratiquement aucun nœud de texte, la sortie est donc vide ou presque. Ensuite, sans balisage il n'y a pas de structure : les règles CSS de saut de page, que la chaîne PDF utilise pour paginer, n'ont ici aucun sens, et les limites de chapitre ne survivent que sous la forme du texte de titre lui-même.

• Moteur : ebook-convert de Calibre, exécuté côté serveur sous la forme ebook-convert <entrée.epub> <sortie.txt> --txt-output-encoding utf-8
• Conteneur EPUB : une archive ZIP avec un mimetype non compressé (application/epub+zip), META-INF/container.xml pointant vers le .opf racine, et le .opf portant metadata / manifest / spine
• L'ordre de lecture est défini par le spine, non par les noms de fichiers ni l'ordre du ZIP : c'est pourquoi les chapitres extraits ressortent dans la séquence prévue
• L'extraction ne conserve que les nœuds de texte : les éléments de bloc deviennent des sauts de paragraphe, les styles en ligne sont écartés et les éléments sans données de caractères (img, hr) disparaissent
• Avec pertes par conception : images, couverture, tableaux (cellules sérialisées en texte courant), polices, couleurs et hiérarchie du sommaire ne survivent pas ; les liens ne gardent que leur texte d'ancre
• Les sources uniquement composées d'images échouent : un EPUB numérisé ou une BD à mise en page fixe n'ont aucun nœud de texte, la sortie est donc vide — le service détecte ce résultat vide et signale un échec au lieu de livrer un fichier blanc
• La sortie est du texte brut UTF-8 à espaces normalisés ; il n'y a pas de notion de page, donc les numéros de page et les réglages de pagination n'ont aucun effet