我正在导出 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 文件。
对于换行,.docx
XML 数据仅包含有关段落和硬中断的信息,而不包含有关软中断的信息。软中断是以特定字体、字体大小和页面宽度呈现文本的结果。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 升级的话,它的优点是不会破坏东西