我现在需要用文档解析器来解析扫描版的pdf，所以我是不是得额外部署Unstructured 服务啊，这个是绝对常用的一个功能，官方文档上没找到说明！
我已粘贴了该页面英文版的 URL。似乎由于您那边的翻译工具，URL 可能已发生变化。
以下是中文页面：
由于该 PDF 是扫描件，我推测其中包含的是图像而非实际文本数据。
在这种情况下，需要某种 OCR 技术来提取文本。据我所知，Unstructured 默认也不执行 OCR。我认为您需要在 OSS 版本中配置 OCR Agent 以启用 OCR：
谢谢，我再好好研究下，非常感谢，我上传的文件确实是扫描版的pdf，里面是没有文本的，只有图像。
按你这个文章试了下，最终还是没成功。 dify平台docker-compose.yml：
按文章已经配了环境参数，且重启过unstructured容器了(我用docker compose down 和 up -d)，
最终测试结果还是一样：
docker-unstructured-1容器中的python环境也看了下，感觉没啥问题：
~ $ python -V
Python 3.12.12
~ $ pip list
Package Version
accelerate 1.12.0
aiofiles 25.1.0
annotated-doc 0.0.4
annotated-types 0.7.0
antlr4-python3-runtime 4.9.3
anyio 4.12.0
backoff 2.2.1
beautifulsoup4 4.14.3
cachetools 6.2.4
certifi 2025.11.12
cffi 2.0.0
charset-normalizer 3.4.4
click 8.3.1
coloredlogs 15.0.1
contourpy 1.3.3
cryptography 46.0.3
cycler 0.12.1
dataclasses-json 0.6.7
Deprecated 1.3.1
effdet 0.4.1
emoji 2.15.0
et_xmlfile 2.0.0
fastapi 0.128.0
filelock 3.20.1
filetype 1.2.0
flatbuffers 25.12.19
fonttools 4.61.1
fsspec 2025.12.0
google-api-core 2.28.1
google-auth 2.45.0
google-cloud-vision 3.11.0
googleapis-common-protos 1.72.0
gpg 1.24.3
grpcio 1.76.0
grpcio-status 1.76.0
h11 0.16.0
hf-xet 1.2.0
html5lib 1.1
httpcore 1.0.9
httpx 0.28.1
huggingface-hub 0.36.0
humanfriendly 10.0
idna 3.11
Jinja2 3.1.6
joblib 1.5.3
kiwisolver 1.4.9
langdetect 1.0.9
lxml 6.0.2
Markdown 3.10
MarkupSafe 3.0.3
marshmallow 3.26.2
matplotlib 3.10.8
ml_dtypes 0.5.4
mpmath 1.3.0
msoffcrypto-tool 5.4.2
mypy_extensions 1.1.0
networkx 3.6.1
nltk 3.9.2
numpy 1.26.4
nvidia-cublas-cu12 12.8.4.1
nvidia-cuda-cupti-cu12 12.8.90
nvidia-cuda-nvrtc-cu12 12.8.93
nvidia-cuda-runtime-cu12 12.8.90
nvidia-cudnn-cu12 9.10.2.21
nvidia-cufft-cu12 11.3.3.83
nvidia-cufile-cu12 1.13.1.3
nvidia-curand-cu12 10.3.9.90
nvidia-cusolver-cu12 11.7.3.90
nvidia-cusparse-cu12 12.5.8.93
nvidia-cusparselt-cu12 0.7.1
nvidia-nccl-cu12 2.27.5
nvidia-nvjitlink-cu12 12.8.93
nvidia-nvshmem-cu12 3.3.20
nvidia-nvtx-cu12 12.8.90
olefile 0.47
omegaconf 2.3.0
onnx 1.20.0
onnxruntime 1.23.2
opencv-python 4.11.0.86
openpyxl 3.1.5
packaging 25.0
pandas 2.3.3
pdf2image 1.17.0
pdfminer.six 20260107
pi_heif 1.1.1
pikepdf 10.1.0
pillow 12.0.0
pip 25.1.1
proto-plus 1.27.0
protobuf 6.33.2
psutil 7.2.1
pyasn1 0.6.1
pyasn1_modules 0.4.2
pycocotools 2.0.11
pycparser 2.23
pycryptodome 3.23.0
pydantic 2.12.5
pydantic_core 2.41.5
pypandoc 1.16.2
pyparsing 3.3.1
pypdf 6.5.0
pypdfium2 5.2.0
python-dateutil 2.9.0.post0
python-docx 1.2.0
python-iso639 2025.11.16
python-magic 0.4.27
python-multipart 0.0.21
python-oxmsg 0.0.2
python-pptx 1.0.2
pytz 2025.2
PyYAML 6.0.3
RapidFuzz 3.14.3
ratelimit 2.2.1
regex 2025.11.3
requests 2.32.5
requests-toolbelt 1.0.0
rsa 4.9.1
safetensors 0.7.0
scipy 1.16.3
setuptools 80.9.0.post20251111
six 1.17.0
soupsieve 2.8.1
starlette 0.41.2
sympy 1.14.0
timm 1.0.22
tokenizers 0.22.1
torch 2.9.1
torchvision 0.24.1
tqdm 4.67.1
transformers 4.57.3
triton 3.5.1
typing_extensions 4.15.0
typing-inspect 0.9.0
typing-inspection 0.4.2
tzdata 2025.3
unstructured 0.18.24
unstructured-client 0.42.6
unstructured_inference 1.1.1
unstructured.pytesseract 0.3.15
urllib3 2.6.2
uvicorn 0.40.0
webencodings 0.5.1
wrapt 2.0.1
xlrd 2.0.2
xlsxwriter 3.2.9
感谢您的更新。
我需要与您分享一些事实：
- 基本上，除非您在
.env文件中将ETL_TYPE设置为Unstructured，否则不会使用 Unstructured。 - 然而，
ETL_TYPE设置的目的专门用于处理您上传到知识库的文档，而不是用于工作流中的文本提取节点。 - 因此，Unstructured 不能在工作流中的文本提取节点中使用。
- 此外，即使您将文件上传到知识库——如果该文件是 PDF——无论
ETL_TYPE设置如何，都将使用pypdfium2进行文本提取。Unstructured 不会被使用。
作为一种变通方案，既然您已经费心部署了 Unstructured，您可能希望考虑使用以下工具替代文本提取节点。由于您还可以在该工具中配置 strategy，我认为它也可以处理 OCR。不过，我本人从未尝试过，因此我的帮助能力有限。
此外，如果您在市场中使用 OCR 或 PDF 等关键词进行搜索，应该能够找到一些由社区创建的 OCR 工具。
希望这能对您有所帮助。
非常感谢您的回复。
根据这个图我一直以为我当前这样的配置是能起作用的，可是仔细一读，存在2个疑点：
- 这个unstructured 是可以用于 document extractor node（文档提取器的），跟你说的不能用于工作流中有冲突！
- 是只能用于文档提取器(当上传的是pptx时？）
@Dify_Forum_Helper Summarize the Q&A.
以下是问答环节的总结：
问题
用户 zhouciming 无法在 Dify 工作流中使用文档提取器节点从扫描版PDF中提取文本。尽管部署了本地 Unstructured 服务并在 .env 和 docker-compose.yaml 中配置了 ETL_TYPE=Unstructured（以及 OCR 环境变量），但输出仍然为空。
诊断
社区成员 kurokobo 阐明了原生配置的局限性：
- 设置范围：
.env中的ETL_TYPE=Unstructured设置主要用于知识库索引（数据集上传），而不是工作流中的运行时“文档提取器”节点。 - PDF处理： 即使在知识库中，Dify 也经常默认使用
pypdfium2处理 PDF，无论ETL_TYPE设置如何，这意味着 Unstructured 服务（及其 OCR）未被调用。 - 文档与实际情况： 用户指出
.env注释中提到了 Unstructured 对“针对 pptx 的文档提取器节点”的支持，这证实了其在工作流节点中对其他文件类型（如 PDF）的应用默认不受支持。
解决方案 / 变通方法
若要在工作流中对扫描版PDF执行OCR：
- 建议： 不要使用原生文档提取器节点，而应使用 Unstructured 插件（可在 Dify 应用市场中获取）或其他社区创建的 OCR 工具。
- 原因： 插件允许明确配置处理策略（例如，启用 OCR），而原生节点不通过全局环境变量暴露或遵守这些策略。
我的解释有点不足。更准确地说，Unstructured 是否可以在文本提取节点中使用取决于文件类型。
这次的问题是关于 PDF 的，所以我假设是 PDF 文件，并回答“它不能在文本提取节点中使用”。然而，正如 .env.example 的注释中所述，对于 ppt 和 pptx，以及 doc 和 epub 文件，文本提取是使用 UNSTRUCTURED_API_URL 和 UNSTRUCTURED_API_KEY 进行的。