HTML转Word的实现方案主要有四类:python-docx需搭配BeautifulSoup解析HTML标签后再逐项映射、html-to-docx默认配置易导致样式丢失与表格错乱、无头浏览器结合pdf2docx可实现高保真生产级转换、LibreOffice命令行适用于静态HTML的批量处理。以下逐一剖析各方案的核心原理与潜在陷阱。
直接用 python-docx 写入 HTML 字符串会失败——Word 里真出现 <p>Hello</p>,不是段落,是纯文本。
document.add_paragraph('<h2>标题</h2>') → Word 中显示“<h2>标题</h2>”字面量python-docx 是对象模型驱动,二者语义不互通BeautifulSoup),再按标签名映射到 Document 方法(add_heading()、add_paragraph()、add_table())parseHtmlStyles: false 是默认值,必须显式设为 true
table.styleMappings: true,rowspan/colspan 和 <th> 语义全丢html-to-docx 不走浏览器上下文,不支持 src="https://...",只认 data:image/... 或本地可读路径<table> 直接消失?该库对深度嵌套无处理逻辑,需前端预扁平化用 Chrome/Edge 渲染 HTML → PDF → 转 DOCX,保真度远高于纯 Python 解析,尤其对 CSS 布局、字体、边框、分页有效。
playwright(Python/JS)启动无头浏览器,调用 page.pdf();再用 pdf2docx 转换selenium + chromedriver:PDF 生成接口不稳定,常卡在 JS 加载完成判断上pdf2docx 加 multi_processing=True 可提速,但若 HTML 含 float: left,需提前加 @media print { float: none } 重置布局libreoffice --headless --convert-to docx --outdir ./output ./input.html
images/a.png 被当成本地文件系统路径,需提前复制资源目录,或改用绝对路径 / base64document.createElement)不会出现在结果中四种转换方案各有明确短板——python-docx不解析HTML标签、html-to-docx需手动配置关键选项、无头浏览器方案存在PDF转DOCX固有损耗、LibreOffice不执行JavaScript且图片路径受限。建议用真实HTML样本预先验证各方案转换效果,避免陷入'能转但不保真'的困境。