將 .docx 文件轉換為純文字並保留換行符以維護對源文件的行號引用：howto 和影響？
我正在將 MS Word內容導出為純文字，以便與文本和文件實用程序一起使用。我有一個約束，即在 MS 軟體中啟用了行號功能，並且最終輸出中對行號的任何引用都必須與該編號匹配。所以輸入“編號行”：
（坡，EA）
顯然對於Word，這種編號不會在newline處換行，它會在**右邊距（或其他東西）之後斷開“行” 。預設情況下，像 , 這樣的腳本似乎
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 上）：
- 統一碼（UTF-8）
- 使用 (CR/LF) 插入換行符 + 結束行
- 允許字元替換
現在確實，當我使用這些
.txt文件時，源編號功能中的行號與輸出之間存在完美匹配grep -n。
- 是否有任何我應該知道的特定配置/過程
docx2txt或類似的命令行實用程序，它允許我將我的*.docx文件轉換為純文字，同時保留換行符，而不像我一樣求助於Word ？*- 在換行和格式方面，將 MS Word文件（可能包含重音字元）導出為純文字以與文件/文本實用程序一起使用的**最佳做法是什麼（如果有）；我為導出選擇的設置（即插入 CR/LF）是否有任何負面影響？
樣本
正如建議的那樣，我提供了一個樣本。在這個 rar存檔中，我捆綁了一個帶有簡單段落的*.docx文件，以及使用 Word 和上述選項導出的.txt文件。*後者可以與
docx2txt源文件上的預設執行進行比較。
docx2txt處理文件中的資訊，該docx文件是一組壓縮的 XML 文件。關於換行，
.docxXML 數據僅包含有關段落和硬中斷的資訊，而不是關於軟中斷的資訊。軟中斷是以特定字型、字型大小和頁面寬度呈現文本的結果。docx2txt通常只是嘗試將文本放入 80 列（80 列是可配置的），而不考慮字型和字型大小。如果您.docx包含來自 Unix/Linux 上不可用的 Windows 系統的字型資訊，那麼.txt通過 Open/LibreOffice 導出也不太可能導致相同的佈局，儘管它試圖做得很好¹。因此
docx2txt，或任何其他命令行實用程序，包括命令行驅動的 Open/LibreOffice 處理，都不能保證將文本轉換為與從 Word 導出時相同的佈局²。如果您想（或被客戶要求）完全按照 Word 的方式進行渲染，根據我的經驗，只有一種方法：讓 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 的主要原因，儘管他們願意。他們必須使用 Microsoft Word，因為 Open/LibreOffice 每隔一段時間就會破壞他們與客戶交換的文本。
²您可以安裝 Word 文件中使用的所有字型，並且有時可能會幸運地獲得某些文本。
³從 ⁴渲染 PDF
.doc/.docx程序使用 GUI 自動化——就像有人在點擊它的菜單一樣——並且不會嘗試通過 API 驅動 Word。我很確定後者也可以完成，並且如果 Word 得到升級，將具有不破壞事物的優勢