Conversione di file .docx in testo semplice e conservazione delle interruzioni di riga per mantenere i riferimenti al numero di riga nel documento di origine: howto e implicazioni?

Sto esportando il contenuto di MS Word in testo normale da utilizzare con utilità di testo e file. Ho un vincolo in cui la funzione di numerazione delle righe è stata abilitata nel software MS e qualsiasi riferimento ai numeri di riga nell'output finale deve corrispondere a tale numerazione. Quindi inserisci "linee di numerazione":

( Poe, EA )

Ovviamente per Word , quel tipo di numerazione non interrompe le righe alla riga successiva , interrompe le "righe" dopo il margine giusto (o qualcosa del genere). Uno script simile docx2txt, per impostazione predefinita, non tiene conto di ciò e interrompe le righe a newline. Quindi, se uso grep -ncon la numerazione, le righe non corrisponderanno alla funzione dei numeri di riga di origine, come illustrato sopra. Dalla documentazione non è esattamente chiaro come avrei bisogno di modificare lo script Perl per convertire i file come devo fare in questo caso:

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

Ho provato a sostituire \nper \r\n, ma che non sembra funzionare per me. Quindi ho fatto ricorso all'esportazione dei documenti direttamente da Word con le seguenti impostazioni (salva come testo normale , su v.2013,64pc):

• Unicode (UTF-8)
• Inserisci interruzioni di riga + fine con (CR / LF)
• Consenti la sostituzione del personaggio

E ora in effetti quando uso i .txtfile c'è una corrispondenza perfetta tra i numeri di riga nella funzione di numerazione sorgente e l' grep -noutput.

• Esiste qualche configurazione / processo specifico che dovrei conoscere docx2txto un'utilità della riga di comando simile che mi avrebbe permesso di convertire i miei file .docx in testo normale preservando le interruzioni di riga, senza ricorrere a Word come ho fatto io?
• Quali sono le migliori pratiche , se presenti, per esportare documenti MS Word (che possono contenere caratteri accentati) in testo normale da utilizzare con utilità di file / testo, rispetto alle interruzioni di riga e alla formattazione; e ci sono implicazioni negative con le impostazioni che ho scelto per l'esportazione, ad esempio l'inserimento di CR / LF?

Campione

Come suggerito, fornisco un campione. In questo raro archivio , ho raggruppato un file .docx con semplici paragrafi e il suo file .txt esportato usando Word con le opzioni di cui sopra. Quest'ultimo può essere confrontato con un'esecuzione predefinita del docx2txtfile di origine.

docx2txtfunziona sulle informazioni nel docxfile che è un insieme compresso di file XML.

Per quanto riguarda il ritorno a capo, i .docxdati XML includono solo informazioni su paragrafi e interruzioni di attività, non su interruzioni di attività. Le interruzioni automatiche sono il risultato del rendering del testo in un carattere specifico, dimensione del carattere e larghezza della pagina. docx2txtnormalmente cerca solo di adattare il testo in 80 colonne (80 colonne sono configurabili), senza alcun riguardo per il carattere e la dimensione del carattere. Se il tuo .docxcontiene informazioni sui caratteri da un sistema Windows che non è disponibile su Unix / Linux, .txtè improbabile che anche l'esportazione in via Open / LibreOffice porti allo stesso layout, sebbene cerchi di fare un buon lavoro¹.

Quindi docx2txto qualsiasi altra utility a riga di comando, inclusa l'elaborazione Open / LibreOffice basata sulla riga di comando, non garantirà la conversione del testo nello stesso layout dell'esportazione da Word2.

Se vuoi (o sei obbligato dai requisiti del cliente) a eseguire il rendering esattamente come fa Word, nella mia esperienza c'è un solo modo: lascia che Word esegua il rendering. Di fronte a un problema simile al tuo³ e con risultati incompatibili con altri strumenti, incluso OpenOffice, sono tornato a installare una VM Windows sul server Linux host. Sulla VM client un programma osserva che i file in arrivo devono essere convertiti sull'host, il che avvia e spinge Word a fare la conversione, quindi copia il risultato⁴.

Le decisioni sull'utilizzo solo di CR / LF o LF, o UTF-8 o qualche altra codifica per la .txtmaggior parte dipendono da come vengono utilizzati i file risultanti. Se i file risultanti vengono utilizzati su Windows, andrei sicuramente con CR / LF, UTF-8 e una distinta base UTF-8 . I moderni programmi su Linux sono in grado di dedurre che un file è UTF-8, ma non entreranno nella distinta base e / o utilizzeranno tali informazioni. È necessario verificare la compatibilità di tutte le applicazioni target se sono note in anticipo.

¹ _{Questo tipo di incompatibilità è il motivo principale per cui alcuni miei amici non possono passare a Linux da Windows, anche se vorrebbero. Devono usare MicroSoft Word, come Open / LibreOffice di tanto in tanto i testi mangles che scambiano con i clienti.}
² _{È possibile installare tutti i caratteri utilizzati nei file di Word e potrebbe essere fortunato per alcuni testi, a volte.}
³ _{Rendering di PDF da.doc/.docx}
⁴ _{Il programma utilizza l'automazione della GUI, come se qualcuno stesse facendo clic sui suoi menu e non tenta di guidare Word tramite un'API. Sono abbastanza sicuro che anche quest'ultimo possa essere fatto e avrebbe il vantaggio di non rompere le cose se Word venisse aggiornato}