.docxファイルをプレーンテキストに変換し、改行を保持してソースドキュメントへの行番号参照を維持する：ハウツーと影響？

MS Wordのコンテンツをプレーンテキストにエクスポートして、text＆fileユーティリティで使用します。MSソフトウェアで行番号付け機能が有効になっているという制約があり、最終出力の行番号への参照はすべてその番号付けと一致する必要があります。したがって、「番号付け行」を入力します。

（ポー、EA）

明らかにWordの場合、この種の番号付けは改行で改行せず、右マージン（または何か）の後の「行」を改行します。のようなスクリプトはdocx2txt、デフォルトではこれを考慮に入れていないようで、改行で改行します。したがってgrep -n、番号付けを使用すると、上記のように、行はソース行番号機能と一致しません。この場合、Perlスクリプトを編集してファイルを変換する方法をドキュメントから明確に明確にすることはできません。

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

代用\nしてみました\r\nが、うまくいきません。そこで、次の設定でWordから直接ドキュメントをエクスポートすることにしました（v.2013,64pcでプレーンテキストとして保存）。

• Unicode（UTF-8）
• （CR / LF）で改行と行末を挿入
• 文字の置換を許可する

そして実際に、ファイルを使用する.txtと、ソース番号付け機能の行番号とgrep -n出力が完全に一致します。

• 私が知っている必要がある特定の構成/プロセス、docx2txtまたは私がしたようにWordに頼ることなく改行を維持しながら.docxファイルをプレーンテキストに変換できる同様のコマンドラインユーティリティはありますか？
• 改行やフォーマットに関して、MS Wordドキュメント（アクセント付き文字が含まれている場合があります）をプレーンテキストにエクスポートしてファイル/テキストユーティリティで使用する場合のベストプラクティスはどれですか。また、エクスポート用に選択した設定、つまりCR / LFの挿入に否定的な影響はありますか？

サンプル

提案されているように、サンプルを提供します。このrar アーカイブでは、単純な段落を含む.docxファイルと、前述のオプションを使用してWordを使用してエクスポートされた.txtファイルをバンドルしました。後者はdocx2txt、ソースファイルのデフォルトの実行と比較できます。

docx2txtdocxXMLファイルの圧縮されたセットであるファイル内の情報を処理します。

行の折り返しに関しては、.docxXMLデータには段落とハードブレークに関する情報のみが含まれ、ソフトブレークに関する情報は含まれません。ソフトブレークは、テキストを特定のフォント、フォントサイズ、ページ幅でレンダリングした結果です。docx2txt通常は、フォントとフォントサイズに関係なく、テキストを80カラム（80カラムは設定可能）に収めようとします。.docxUnix / Linuxでは利用できないWindowsシステムからのフォント情報がに含まれている場合、.txtOpen / LibreOffice を介してにエクスポートすると、同じレイアウトになる可能性は低くなりますが、うまくいきます¹。

したがってdocx2txt、コマンドライン駆動のOpen / LibreOffice処理を含む他のコマンドラインユーティリティは、Wordからのエクスポートと同じレイアウトへのテキスト変換を保証しません²。

Wordとまったく同じようにレンダリングしたい（またはクライアントの要件によって強制された）場合、私の経験では1つの方法しかありません：Wordにレンダリングを行わせます。あなたと同じような問題に直面し、OpenOfficeを含む他のツールを使用して互換性のない結果が出たとき、私はホストLinuxサーバーにWindows VMをインストールすることに戻しました。プログラムは、クライアントVMでホスト上で変換される着信ファイルを監視します。これにより、Wordが起動および駆動されて変換が行われ、結果がコピーされます。

CR / LFまたはLFのみを使用するか、UTF-8またはその他のエンコーディングを.txt使用するかについての決定は、結果として得られるファイルの使用方法に大きく依存します。結果のファイルがWindowsで使用される場合、私は間違いなくCR / LF、UTF-8、およびUTF-8 BOMを使用します。Linux上の最新のプログラムは、ファイルがUTF-8であると推定できますが、BOMでバーフしたり、その情報を使用したりすることはありません。ターゲットアプリケーションが事前にわかっている場合は、互換性についてすべてのターゲットアプリケーションをテストする必要があります。

¹ _{この種の非互換性が、私の友人の一部がWindowsからLinuxに変更することを望んでも変更できない主な理由です。Open / LibreOfficeがクライアントと交換するテキストをときどき壊すので、彼らはMicroSoft Wordを使用する必要があります。}
²Word _{ファイルで使用されているすべてのフォントをインストールできます。一部のテキストでは、場合によってはラッキーになることがあります。}
³ _{からPDFをレンダリング.doc/.docx}
⁴ _{誰かがそのメニューを-し、クリックされたAPIを経由してWordを推進しようとしないかのプログラムはGUIとして自動化を、使用しています。後者も同様に実行でき、Wordがアップグレードされても問題が発生しないという利点があると確信しています。}