Python代码写入Word：纯文本与Pygments RTF高亮

脚本专家

在技术文档、代码审查记录或内部报告整理中，常需要把 Python 脚本嵌入 Word 文档。少量代码可以手动复制，但脚本较长或文件较多时，自动化方式在一致性和效率上更合适。本文围绕 Spire.Doc for Python 和 Pygments，给出两种可落地的实现：纯文本嵌入与 RTF 语法高亮嵌入，并说明关键代码、参数含义、局限和选择建议。

环境准备

实现上述功能需要两个库：Spire.Doc 负责创建和操作 Word 文档，Pygments 负责生成带语法高亮的代码格式。安装命令如下：

2. pip install spire.doc pygments

复制代码

两个方案都会从 spire.doc 导入 Document、ParagraphStyle、FileFormat 等类与枚举，Pygments 相关模块只在第二个方案中使用。

方案一：纯文本嵌入

纯文本方式先读取 .py 文件内容，再插入 Word 段落，并用等宽字体保持代码缩进和可读性。它实现简单，生成的代码在 Word 中完全可编辑。

2. from pathlib import Path
3. from spire.doc import *
5. # 读取 Python 文件
6. code_string = Path("demo.py").read_text(encoding="utf-8")
8. # 创建一个 Word 文档
9. doc = Document()
11. # 添加一个节
12. section = doc.AddSection()
13. section.PageSetup.Margins.All = 60
15. # 添加一个段落
16. paragraph = section.AddParagraph()
18. # 将代码字符串插入段落
19. paragraph.AppendText(code_string)
21. # 创建一个段落样式
22. style = ParagraphStyle(doc)
23. style.Name = "code"
24. style.CharacterFormat.FontName = "Consolas"
25. style.CharacterFormat.FontSize = 12
26. style.ParagraphFormat.LineSpacing = 12
27. doc.Styles.Add(style)
29. # 将样式应用于段落
30. paragraph.ApplyStyle("code")
32. # 保存文档
33. doc.SaveToFile("Output.docx", FileFormat.Docx2019)
34. doc.Dispose()

复制代码

这段代码的关键在于 ParagraphStyle 的创建与应用。等宽字体如 Consolas 是保持代码对齐的基础；固定行距，例如 LineSpacing 设为 12，可让多行代码的纵向间距一致。Path.read_text() 会原样读取文件内容，缩进、空行和换行符都会被保留。文档使用完毕后调用 Dispose() 释放资源。

需要注意，AppendText 插入的是纯文本，换行符在 Word 中表现为软换行，段落样式统一应用于整个代码块。如果代码中含有制表符，其显示宽度取决于 Word 的制表位设置，必要时可先用 expandtabs() 将制表符转为空格。

纯文本方式适合代码需要保持可编辑状态的场景，例如技术文档中读者可能要复制代码片段进行测试。它的局限也很明显：Word 中不会呈现语法着色，关键字、字符串和注释没有视觉区分，较长代码块的阅读体验一般。

方案二：Pygments 语法高亮 + RTF 嵌入

如果希望代码在 Word 中呈现类似 IDE 的着色效果，可以借助 Pygments 将代码转换为带格式的 RTF 字符串，再通过 AppendRTF 方法插入 Word。RTF 方案的一个特点是：嵌入后的代码在 Word 中仍然是可选中、可编辑的文本，而不是图片。

2. from pathlib import Path
3. from pygments import highlight
4. from pygments.lexers import PythonLexer
5. from pygments.formatters import RtfFormatter
6. from spire.doc import *
8. # 读取 Python 文件
9. code = Path("demo.py").read_text(encoding="utf-8")
11. # 设置字体
12. formatter = RtfFormatter(fontface="Consolas")
14. # 指定词法分析器，生成带高亮的 RTF
15. rtf_text = highlight(code, PythonLexer(), formatter)
16. rtf_text = rtf_text.replace(r"\f0", r"\f0\fs24") # 字体大小（24 对应 12 磅字体）
18. # 创建一个 Word 文档
19. doc = Document()
21. # 添加一个节
22. section = doc.AddSection()
23. section.PageSetup.Margins.All = 60
25. # 添加一个段落
26. paragraph = section.AddParagraph()
28. # 将语法高亮的代码作为 RTF 插入
29. paragraph.AppendRTF(rtf_text)
31. # 保存文档
32. doc.SaveToFile("Output.docx", FileFormat.Docx2019)
33. doc.Dispose()

复制代码

这里有几个细节值得说明。RtfFormatter(fontface="Consolas") 指定输出 RTF 使用的字体，与纯文本方案保持一致，避免 Word 中显示为默认替代字体。Pygments 生成的 RTF 默认字号较小，通过 replace(r"\f0", r"\f0\fs24") 在字体控制字后追加字号指令，将其调整为约 12 磅。这是一种直接操作 RTF 控制字的做法，简单有效，但该替换是全局字符串替换，若 RTF 中其他位置也出现 \f0 序列，会一并被修改；在固定字体配置下通常无碍，更换格式时需留意。PythonLexer() 负责解析 Python 语法元素，RtfFormatter 将其映射为 RTF 的颜色控制字，关键字、字符串、注释等会呈现不同颜色。

RTF 方案的格式精细程度受限于 RTF 的表达能力。如果对布局有更细致的要求，例如自定义背景色、行号显示，RTF 并非最佳载体，可考虑 HTML 嵌入或图片方案。此外，Pygments 支持通过 style 参数更换配色方案，默认样式在 Word 中的对比度通常够用，若需调整可查阅 Pygments 文档。

两种方案的对比与选择

从对比维度看，纯文本方案没有语法着色，实现复杂度低，格式控制集中在基础字体和行距；RTF 语法高亮方案有语法着色，实现复杂度中等，需要引入 Pygments，格式精细控制受限于 RTF 表达能力。

选择建议是：如果 Word 文档主要用于存档或内部传阅，且读者不需要在 Word 中直接修改代码，语法高亮方案的可读性更好；如果代码需要被频繁复制粘贴到其他环境，或者文档对文件体积敏感，纯文本方案更轻量。两者均不需要安装 Microsoft Word，可在纯 Python 环境中运行。

结语

将 Python 代码转换为 Word 文档的核心操作集中在文本读取、格式生成与文档写入三个环节。纯文本方案依靠等宽字体保证基础可读性，RTF 方案则借助 Pygments 在保持文本可编辑的前提下补足语法着色能力。实际使用时，可以根据文档目标读者和后续用途在两者之间选择。对于批量处理多个脚本文件的场景，上述逻辑同样可以封装为函数，配合目录遍历实现自动化输出。

热心网友2

感谢分享，两种方案对比得很清楚。纯文本方案胜在简单，代码完全可编辑，适合读者需要复制代码去运行的场景；RTF 方案借助 Pygments 做语法着色后，阅读长脚本确实轻松很多，而且插入的仍是可选中、可编辑的文本，没有变成图片，这一点比很多人常用的截图法要好。 几个细节提醒得很到位，特别是用 expandtabs() 预处理制表符、以及 LineSpacing 固定行距保持纵向一致，这些都是实际排版时容易忽略的地方。对 replace(r"\f0", r"\f0\fs24") 这种全局替换可能误伤其他位置的说明也很中肯，在字体配置固定时问题不大，但换主题或调格式时要多检查一下输出。 另外想请教一下：如果一段代码比较长、跨了好几页，RTF 方式在分页处有没有断行或颜色丢失的情况？还有在目标机器上没装 Consolas 时，Word 的回退字体是否会破坏对齐效果，是否需要在样式里再指定一个备选等宽字体？ 总体来说这份教程很实用，代码可以直接跑起来，参数也都有解释，收藏了。

热心网友2

感谢分享，这两种思路都很实用，而且把关键参数和局限讲得比较清楚。纯文本方案实现简单，代码在 Word 里保持可编辑，适合技术文档里读者需要复制片段的场景；RTF 方案借助 Pygments 做语法着色，同时嵌入后仍是可选中、可编辑的文本，阅读体验会更好，这一点挺有价值。 实际使用时我会特别注意几个地方：纯文本方案里先用 expandtabs() 处理制表符，避免 Word 制表位导致缩进不一致；RTF 方案里通过替换 \f0 调整字号确实简单，但更换字体或格式配置时要留意全局替换的影响。另外两种方案都记得在保存后调用 Dispose() 释放资源。选择上，如果更看重简单和可复制编辑，纯文本就够了；如果希望接近 IDE 的着色效果，RTF 方案更合适，但遇到背景色、行号等更细布局要求时，确实要评估 RTF 的表达能力。整体思路很清晰，感谢整理。

热心网友2

感谢分享，两种方案对比得很清楚，选择建议也很实用。纯文本方案里用 Consolas 加固定行距这个细节抓得准，代码对齐基本就靠这两点；RTF 方案里那个 `\f0` 全局替换的提醒也很到位，确实换字体或换配色时容易踩坑。 补充两个自己踩过的点：一是 Spire.Doc 免费版对页数有限制，如果脚本很长、生成文档超过限额，保存时可能会被截断或加水印，长文档场景最好提前确认一下授权情况；二是 Pygments 的 RtfFormatter 其实可以直接通过 `style` 参数指定配色主题，比如 `RtfFormatter(fontface="Consolas", style="monokai")`，比默认配色更适合深色阅读习惯，不过 Word 页面背景是白的，深色主题反而可能对比度不够，这点要看具体使用场景。 另外帖子结尾“此外，Pygme”这里好像被截断了，关于 Pygments RTF 的局限性部分没显示完，方便的话可以补一下，正好想看看你对和 HTML 嵌入方案对比的看法。