[dify]Dify 接入 doc文档处理:一次旧版 Word 文档实践

最近在做 Dify 工作流时，我碰到一个问题：Dify 的文档提取器不支持旧版 .doc 文件。

这个问题平时不一定明显，但一接实际材料就会碰到。因为不少历史材料、公文附件、老合同，仍然是 .doc 格式。不能直接读取，就只能先手动转成 .docx 再上传。文件少的时候还好，文件一多就很影响效率，也不适合放进自动化流程里。

我查了一下 Dify 插件市场，当时也没有找到现成能直接处理这类文件的插件。于是就想着，干脆自己补上这一步：让 .doc 文件也能顺利接进 Dify 的后续流程。

一、问题背景

Dify 自带的文档提取器，平时其实很好用。像 PDF、.docx、.txt 这些常见格式，基本都能正常处理。

真正碰到问题，是在接一些历史文档的时候。很多资料并不是现在常见的 .docx，而是早些年留下来的 .doc。这种文件平时不觉得多，一旦开始接实际材料，就会频繁碰到。

如果只是偶尔处理几份文件，手动另存一下也能解决。 但只要想把文件上传、内容提取、后续分析尽量串成一条流程，这一步就会变得很别扭。中间多一次人工操作，流程就不够顺，批量处理时也很难持续。

二、解决思路

思路其实很直接：先把 .doc 转成 .docx，再交给 Dify 的文档提取器继续处理。

整个链路就是：

开始 → .doc 转换 → 文档提取器 → 结束

单纯做格式转换，其实办法不少。手工另存是一种，影刀 RPA 这类工具也可以做批量转换。 但如果希望这一步也接进 Dify 工作流里，重点就不只是“能转”，而是“转完以后能不能继续往后走”。

也就是说，转换后的文件不仅要生成出来，还要能被后面的文档提取器正常接住。

三、插件开发

整个过程中，我基本都是借助豆包和 DeepSeek 一起推进的。从思路梳理、方案比较，到代码生成、报错排查和细节调整，基本都是在它们的辅助下完成的。

所以这篇文章就不展开写代码了。 这次真正花时间的，除了和大模型反复沟通插件开发细节外，还有环境安装、插件上传、依赖补齐和工作流验证这些环节。

打包好的插件我也已经整理好了，感兴趣的话可以关注我，进群下载安装。

四、插件安装

1. 在 plugin_daemon 容器里安装 LibreOffice

这个地方一开始比较容易忽略。因为转换这一步不是在本机环境里跑，而是在 Dify 的 plugin_daemon 容器中执行，所以 LibreOffice 也要装在对应容器里。

先确认容器系统版本：

docker exec -it docker-plugin_daemon-1 cat /etc/os-release

我这里返回的是 Ubuntu 24.04。

然后进入容器：

docker exec -it docker-plugin_daemon-1 /bin/bash

安装 LibreOffice 和中文字体：

apt-get updateapt-get install -y libreoffice-writer libreoffice-coreapt-get install -y fonts-wqy-zenhei

安装完成后，可以执行下面的命令验证：

libreoffice --version

如果能正常输出版本号，就说明安装成功了。

2. 修改 Dify 的插件签名校验配置

如果直接上传本地插件，比较容易碰到签名校验问题。开发测试阶段，我这里是直接把校验先关掉了。

在 docker/.env 里，把下面两个配置改成 false：

FORCE_VERIFYING_SIGNATURE=falseENFORCE_LANGGENIUS_PLUGIN_SIGNATURES=false

改完之后，重启 Dify。

3. 上传本地插件

插件打包完成后，通过 Dify 控制台上传：

插件 → 安装插件 → 本地插件上传

上传的是本地打包好的 .difypkg 文件。

如果上传完成后，点击插件能看到参数说明，基本就说明插件已经安装成功了。

五、实际踩到的几个坑

1. 插件签名验证失败

最开始上传插件时，我先碰到的是签名报错：

PluginDaemonBadRequestError: plugin verification has been enabled, and the plugin you want to install has a bad signature

这个问题本身不复杂，就是 Dify 默认启用了插件签名校验。开发测试阶段，如果没有做正式签名，就会被拦下来。

处理方式就是前面提到的，先在 docker/.env 里把相关配置改掉，再重启容器。

2. 容器里缺少 LibreOffice

插件安装成功后，运行时又遇到了另一个问题：提示找不到 LibreOffice。

这个坑一开始很容易绕，因为直觉上会先去看自己本机有没有装。 但真正关键的是：执行这一步的容器里有没有装。

把 LibreOffice 补到 plugin_daemon 容器里之后，这一步才真正跑起来。

3. 中文乱码和方框

后面测试时，还碰到过中文乱码和方框的问题。 这个问题最后看下来，主要还是字体不完整。把中文字体装上之后，结果就正常了。

如果处理的是中文文档，这一步最好一开始就补齐，不然后面很容易在这里卡一下。

4. 容器重建后依赖会丢

还有一个实际问题是：如果你是直接进容器手动安装的 LibreOffice 和字体，那容器重建或重新部署后，这些安装内容会丢失。

所以这种方式更适合先验证流程。 如果后面准备长期使用，还是建议做成自定义镜像，省得后面重复装环境。

六、工作流验证

插件装好以后，我直接搭了一个简单工作流来测整条链路。

流程很简单：

开始节点上传文件 → doc 转换节点 → 文档提取器节点 → 输出文档内容

重点看两件事：

一是 .doc 文件能不能顺利转成 .docx； 二是转换后的文件能不能被文档提取器正常读取。

实际跑下来，这条链路是可以走通的。也就是说，.doc 文件经过转换之后，已经能够继续进入 Dify 的文档处理流程，而不再卡在上传这一步。

七、总结

如果只是偶尔处理少量 .doc 文件，手工另存或者借助 RPA 工具都能解决。

但如果文档后面还要进入 Dify 工作流，接文档提取、知识库、问答或者其他处理节点，那把这一步接进现有链路，整体会更顺，也更适合自动化处理。

这次实践做的事情其实不复杂，本质上就是：

把 Dify 原本读不了的 .doc 文件，补成了可以继续往后处理的一环。

📢 如果这篇文章对你有帮助

你的支持是我持续分享的最大动力！

• 点个 👍 —— 让更多开发者看到这篇内容

• 转发给需要的朋友 —— 也许他正被同样的问题困扰

• 关注我 —— 进群获取插件安装包，第一时间收到更多 Dify 实践干货