Conversion de fichiers .docx en texte brut et conservation des sauts de ligne pour conserver les références des numéros de ligne au document source: comment et implications?

J'exporte du contenu MS Word en texte brut pour une utilisation avec les utilitaires de texte et de fichier. J'ai une contrainte où la fonction de numérotation des lignes a été activée dans le logiciel MS, et toute référence aux numéros de ligne dans la sortie finale doit correspondre à cette numérotation. Entrez donc "lignes de numérotation":

entrez la description de l'image ici ( Poe, EA )

Évidemment, pour Word , ce type de numérotation ne rompt pas les lignes à la nouvelle ligne , il casse les "lignes" après la marge de droite (ou quelque chose). Un script comme docx2txt, ne tient pas compte de cela par défaut, semble-t-il et rompt les lignes à la nouvelle ligne. Donc, si j'utilise grep -navec la numérotation, les lignes ne correspondront pas à la fonction de numéros de ligne source, comme illustré ci-dessus. La documentation ne précise pas exactement comment je devrais modifier le script Perl pour convertir les fichiers comme je le dois dans ce cas:

our $config_newLine = "\n"; # Alternative is "\r\n".
our $config_lineWidth = 80; # Line width, used for short line justification.

J'ai essayé substituer \nà , \r\nmais cela ne semble pas fonctionner pour moi. J'ai donc eu recours à l'exportation des documents directement à partir de Word avec les paramètres suivants (enregistrer en texte brut , sur v.2013,64pc):

Unicode (UTF-8)
Insérer des sauts de ligne + lignes de fin avec (CR / LF)
Autoriser la substitution de caractères

Et maintenant, en effet, lorsque j'utilise les .txtfichiers, il y a une correspondance parfaite entre les numéros de ligne dans la fonction de numérotation source et la grep -nsortie.

Existe-t-il une configuration / un processus spécifique que je devrais connaître docx2txtou un utilitaire de ligne de commande similaire qui m'aurait permis de convertir mes fichiers .docx en texte brut tout en préservant les sauts de ligne, sans recourir à Word comme je l'ai fait?
Quelles sont les meilleures pratiques , le cas échéant, pour exporter des documents MS Word (qui peuvent contenir des caractères accentués) en texte brut à utiliser avec les utilitaires de fichier / texte, en ce qui concerne les sauts de ligne et la mise en forme; et y a-t-il des implications négatives avec les paramètres que j'ai choisis pour l'exportation, c'est-à-dire l'insertion de CR / LF?

Échantillon

Comme suggéré, je fournis un échantillon. Dans cette archive rar , j'ai regroupé un fichier .docx avec des paragraphes simples et son fichier .txt exporté en utilisant Word avec les options susmentionnées. Ce dernier peut être comparé à une exécution par défaut de docx2txtsur le fichier source.

— Communauté
source

Pouvez-vous nous donner un exemple de fichier?

— cuonglm

Ne pouvez-vous pas l'enregistrer en tant que fichier txt à partir de Word? Si cela vous donne un mauvais formatage, je suggérerais d'utiliser vim ou emacs pour résoudre le problème (car je suis sûr qu'il est modelé).

— Steven Walton

@Steven Walton Merci, oui ça marche quand j'exporte en txt depuis Word. Mais je ne veux pas avoir à utiliser Word est mon point. J'aimerais pouvoir compter uniquement sur le script pour le faire. Je veux un processus pour le batch.

@Gnouc L'échantillon a été fourni. Je vous remercie!

docx2txttravaille sur les informations du docxfichier qui est un ensemble compressé de fichiers XML.

En ce qui concerne le retour à la ligne, les .docxdonnées XML ne comprennent que des informations sur les paragraphes et les coupures, et non sur les coupures progressives. Les sauts mous sont le résultat du rendu du texte dans une police, une taille de police et une largeur de page spécifiques. docx2txtessaie normalement d'ajuster le texte dans 80 colonnes (80 colonnes sont configurables), sans aucun égard pour la police et la taille de la police. Si votre .docxcontient des informations sur les polices d'un système Windows qui n'est pas disponible sur Unix / Linux, alors l'exportation vers .txtvia Open / LibreOffice entraînerait également peu de résultats dans la même mise en page, bien qu'il essaie de faire du bon travail¹.

Ainsi, docx2txttout autre utilitaire de ligne de commande, y compris le traitement Open / LibreOffice piloté par ligne de commande, ne garantira pas la conversion du texte dans la même mise en page que l'exportation à partir de Word.

Si vous voulez (ou êtes obligé par les exigences du client) de rendre exactement comme Word, il n'y a dans mon expérience qu'une seule façon: laissez Word faire le rendu. Face à un problème similaire au vôtre³, et ayant des résultats incompatibles avec d'autres outils, dont OpenOffice, je suis revenu à l'installation d'une machine virtuelle Windows sur le serveur Linux hôte. Sur la machine virtuelle cliente, un programme observe les fichiers entrants à convertir sur l'hôte, ce qui démarre et pousse Word à effectuer la conversion, puis recopie le résultat⁴.

Les décisions concernant l'utilisation de CR / LF ou LF uniquement, ou UTF-8 ou un autre encodage pour le .txtdépend en grande partie de la façon dont les fichiers résultants sont utilisés. Si les fichiers résultants sont utilisés sur Windows, j'irais certainement avec CR / LF, UTF-8 et une nomenclature UTF-8 . Les programmes modernes sous Linux sont capables de déduire qu'un fichier est UTF-8, mais n'écorcheront pas sur la nomenclature et / ou n'utiliseront pas ces informations. Vous devez tester la compatibilité de toutes vos applications cibles si elles sont connues à l'avance.

¹ _{Ce type d'incompatibilité est la principale raison pour laquelle certains de mes amis ne peuvent pas passer à Linux à partir de Windows, bien qu'ils le souhaitent. Ils doivent utiliser MicroSoft Word, car Open / LibreOffice modifie de temps en temps les textes qu'ils échangent avec les clients.}
² _{Vous pouvez installer toutes les polices utilisées dans les fichiers Word et avoir de la chance pour certains textes, parfois.}
³ _{Rendu de PDF à partir de.doc/.docx}
⁴ _{Le programme utilise l'automatisation GUI - comme si quelqu'un clique sur ses menus - et n'essaie pas de piloter Word via une API. Je suis à peu près sûr que ce dernier peut également être fait et aurait l'avantage de ne pas casser les choses si Word était mis à niveau}

— Anthon
source

Merci, c'est vraiment perspicace! Je n'étais pas familier avec le format mais j'ai appelé le script à partir de vimet je pouvais voir qu'il s'agissait bien de xml - je devrais y aller plus loin. Je n'avais pas pensé aux polices, ni même à la césure. Pendant une opération, j'ai également reçu un message d'un éditeur de texte se plaignant de la nomenclature, je vais donc lire le lien (car je n'avais aucune idée de ce que c'était). J'ai été surpris par votre solution VM! Je connais un peu l'automatisation de l'interface graphique - je l'ai vue utilisée pour construire une station de travail après la réplication d'une image de base; n'y a pas pensé ...

En fin de compte, cela signifie que quelqu'un qui va soho avec ces tâches peuvent avoir besoin d'internaliser le coût de quelques licences. Peut-être qu'un jour, ils feront un niveau avec une API par utilisation. La rupture des lignes sur les coupures progressives change complètement la dynamique de l'utilisation d'un outil comme grep; si les lignes sont longues, cela diminue la "précision" de la sortie. Je suppose que les contraintes varient selon la nature du contenu et la façon dont il est utilisé. D'un autre côté, de telles questions ne se poseraient pas si les documents n'avaient pas utilisé la fonction de numérotation Word ici. Construire un cadre documentaire pour englober le matériel hérité est une affaire sérieuse. À votre santé!