Converter arquivos .docx em texto sem formatação e preservar quebras de linha para manter referências de números de linha ao documento de origem: como e implicações?

Question

Estou exportando o conteúdo do MS Word para texto simples para uso com utilitários de texto e arquivo. Eu tenho uma restrição onde o recurso numeração de linha foi habilitado no software MS, e qualquer referência a números de linha na saída final deve corresponder a essa numeração. Então, digite "linhas de numeração":

(Poe,E.A.)

Obviamente,paraWord,essetipodenumeraçãonãoquebralinhasemnovalinha,quebra"linhas" após a margem direita ( ou alguma coisa). Um script como docx2txt , não considera isso por padrão e quebra as linhas na nova linha. Portanto, se eu usar grep -n com numeração, as linhas não corresponderão ao recurso de números de linha de origem, conforme ilustrado acima. Não é exatamente claro na documentação como eu precisaria editar o script Perl para converter os arquivos da maneira que eu preciso neste caso:

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

Eu tentei substituir \n por \r\n , mas isso não parece funcionar para mim. Então eu recorri a exportar os documentos diretamente do Word com as seguintes configurações (salve como texto simples , em v.2013,64pc):

• Unicode (UTF-8)
• Inserir quebras de linha + linhas finais com (CR / LF)
• Permitir substituição de caracteres

E agora, de fato, quando eu uso os arquivos .txt , há uma correspondência perfeita entre os números de linha no recurso de numeração de origem e a grep -n output.

• Existe alguma configuração / processo específico que eu deveria saber sobre docx2txt ou um utilitário de linha de comando semelhante que me permitiria converter meus arquivos docx em texto sem formatação, preservando as quebras de linha, sem Recorrendo a Word como eu fiz?
• Quais são as melhores práticas , se houver, para exportar documentos MS Word (que podem conter caracteres acentuados) para texto simples para uso com utilitários de arquivo / texto, com em relação a quebras de linha e formatação; e há alguma implicação negativa com as configurações que escolhi para exportar, ou seja, inserir CR / LF?

Amostra

Como sugerido, forneço uma amostra. Neste arquivo , anexei um arquivo .docx com parágrafos simples e exportado .txt arquivo usando o Word com as opções acima mencionadas. O último pode ser comparado com uma execução padrão de docx2txt no arquivo de origem.

    

Answer 1

docx2txt funciona nas informações do arquivo docx , que é um conjunto compactado de arquivos XML.

No que diz respeito à quebra de linha, os dados .docx XML incluem apenas informações sobre parágrafos e hard-breaks, não sobre pausas soft-breaks. Os soft-breaks são um resultado da renderização do texto em uma fonte específica, tamanho da fonte e largura da página. docx2txt normalmente apenas tenta ajustar o texto em 80 colunas (80 colunas são configuráveis), sem qualquer consideração por fonte e tamanho de fonte. Se o seu .docx contiver informações de fonte de um sistema Windows que não está disponível no Unix / Linux, fazer a exportação para .txt via Open / LibreOffice também resultaria no mesmo layout, embora tente fazer um bom trabalho¹ .

Portanto, docx2txt ou qualquer outro utilitário de linha de comando, incluindo processamento Open / LibreOffice orientado por linha de comando, não garante a conversão do texto para o mesmo layout da exportação do Word².

Se você quiser (ou for forçado pelos requisitos do cliente) a processar exatamente como o Word, existe em minha experiência apenas uma maneira: deixar o Word fazer a renderização. Quando confrontado com um problema semelhante ao seu³, e tendo resultados incompatíveis usando outras ferramentas, incluindo o OpenOffice, eu reverti para a instalação de uma VM do Windows no servidor Linux host. Na VM cliente, um programa observa os arquivos recebidos a serem convertidos no host, o que iniciaria e direcionaria o Word para fazer a conversão e depois copiaria o resultado⁴.

As decisões sobre o uso somente de CR / LF ou LF, ou UTF-8 ou alguma outra codificação para o .txt , dependem em grande parte de como os arquivos resultantes são usados. Se os arquivos resultantes forem usados no Windows, eu definitivamente irei com CR / LF, UTF-8 e um BOM UTF-8 . Os programas modernos no Linux são capazes de deduzir que um arquivo é UTF-8, mas não irá invadir a BOM e / ou usar essa informação. Você deve testar todos os seus aplicativos de destino para compatibilidade se eles forem conhecidos na frente.

¹ _{Este tipo de incompatibilidade é a principal razão pela qual alguns dos meus amigos não podem mudar para o Linux a partir do Windows, embora eles gostariam de fazê-lo. Eles têm que usar o MicroSoft Word, pois o Open / LibreOffice de vez em quando lida com os textos que eles trocam com os clientes.} ² _{Você pode instalar todas as fontes usadas nos arquivos do Word e pode ter sorte para alguns textos, algumas vezes.}
³ _{Renderizando PDFs de .doc/.docx}
⁴ _{O programa usa a automação da GUI - como se alguém estivesse clicando em seus menus - e não tenta conduzir o Word por meio de uma API. Tenho certeza que o último pode ser feito também e teria a vantagem de não quebrar coisas se o Word fosse atualizado}