我正在导出 MS单词内容转换为纯文本，以便与文本和文件实用程序一起使用。我有一个约束条件行编号MS 软件中已启用该功能，并且最终输出中对行号的任何引用必须匹配该编号。因此输入“编号行”：
（爱伦·坡）
显然是为了单词，这种编号不会在以下位置换行新队，它在之后打破了“线”右边距（或者其他的东西）。像这样的脚本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但这似乎对我不起作用。所以我直接从单词具有以下设置（另存为纯文本，关于 v.2013,64pc）：
- 统一码(UTF-8)
- 使用 (CR/LF) 插入换行符 + 结束行
- 允许字符替换
现在确实当我使用文件.txt中源编号功能中的行号与输出之间存在完美匹配grep -n。
- 是否有任何我应该了解的特定配置/过程
docx2txt或类似的命令行实用程序可以让我转换我的.docx将文件转换为纯文本，同时保留换行符，而无需求助于单词就像我一样？ - 什么是最佳实践，如果有的话，用于导出 MS单词文档（可能包含重音字符）转换为纯文本，以便与文件/文本实用程序一起使用，涉及换行符和格式；我选择的导出设置（即插入 CR/LF）是否有任何负面影响？
样本
按照建议，我提供了一个样本。在这个rar中档案，我捆绑了一个.docx包含简单段落的文件及其导出。TXT使用带有上述选项的 Word 文件。后者可以与docx2txt源文件上的默认运行进行比较。
答案1
docx2txt处理文件中的信息docx，该文件是一组压缩的 XML 文件。
对于换行，.docxXML 数据仅包含有关段落和硬中断的信息，而不包含有关软中断的信息。软中断是以特定字体、字体大小和页面宽度呈现文本的结果。docx2txt通常只是尝试将文本放入 80 列（80 列是可配置的），而不考虑字体和字体大小。如果您.docx包含来自 Windows 系统的字体信息，而该信息在 Unix/Linux 上不可用，那么通过 Open/LibreOffice 导出.txt也不太可能得到相同的布局，尽管它试图做得很好。
Sodocx2txt或任何其他命令行实用程序，包括命令行驱动的 Open/LibreOffice 处理，将不是保证将文本转换为与从 Word 导出时相同的布局²。
如果您想要（或迫于客户要求）完全按照 Word 的方式进行渲染，根据我的经验，只有一种方法：让 Word 进行渲染。当遇到与您类似的问题时，并且使用其他工具（包括 OpenOffice）得到不兼容的结果时，我恢复在主机 Linux 服务器上安装 Windows VM。在客户端虚拟机上，程序会观察主机上要转换的传入文件，主机将启动并驱动 Word 进行转换，然后将结果复制回⁴。
决定使用 CR/LF 还是仅使用 LF，或者使用 UTF-8 或其他某种编码，很大程度上.txt取决于结果文件的使用方式。如果生成的文件在 Windows 上使用，我肯定会使用 CR/LF、UTF-8 和UTF-8 BOM。 Linux 上的现代程序能够推断出文件是 UTF-8，但不会拒绝 BOM 和/或使用该信息。如果事先已知的话，您应该测试所有目标应用程序的兼容性。
1这种不兼容性是我的一些朋友无法从 Windows 切换到 Linux 的主要原因，尽管他们很想这样做。他们必须使用 MicroSoft Word，因为 Open/LibreOffice 时不时地会破坏他们与客户交换的文本。
²您可以安装 Word 文件中使用的所有字体，并且有时可能会对某些文本感到幸运。
3从 ⁴渲染 PDF.doc/.docx该程序使用 GUI 自动化，就像有人单击其菜单一样，并且不会尝试通过 API 驱动 Word。我很确定后者也可以完成，并且如果 Word 升级的话，它的优点是不会破坏东西