feat: optionally reject binary files instead of indexing them as latin-1 text

问题场景

用户在 Open WebUI 中把成批文档加入知识库，使用默认加载器加载。当上传的是扩展名未知的二进制文件，或者文件名被命名为 .txt 但内容其实是二进制的文件时，这些文件没有被拒绝，而是被当作文本处理。

典型复现方式：把 20,000 个随机字节分别保存为 random_binary.txt 和 random_sample.qzx 后上传到知识库，两个文件都被标记为 completed，并产生了约 17,300 个字符的解码文本以及 13 到 14 个向量。讨论 #30349 中同样的现象也出现在白名单扩展名 .xlsb 上。

报错原文

Falling back to latin-1 encoding for ...
feat: optionally reject binary files instead of indexing them as latin-1 text

该 Issue 没有传统意义上的异常堆栈，用户可见的表现是文件状态为 completed，但知识库中出现不可读的乱码分块。

原因分析

最可能的原因是 Open WebUI 默认加载器的编码检测流程在无法识别编码时，会回退到 latin-1 解码，并且没有对“内容明显不是文本”的情况做拒绝处理。Issue 中给出的关键位置包括：

• backend/open_webui/retrieval/loaders/main.py:820-823：回退到 TextLoader。
• backend/open_webui/retrieval/loaders/main.py:381-483：检测编码，最终落到 latin-1。
• backend/open_webui/routers/files.py:66-94：已有 NUL 字节检查，但只用于重新分类 media type，不用于拒绝二进制内容。

因此扩展名白名单在这里不起作用，因为像 .txt 这样的扩展名本身是被允许的，问题出在内容而非扩展名。

环境排查

• 确认 Open WebUI 版本：Issue 中确认受影响的是 v0.11.4 和 dev 分支（35b0db7）。
• 确认触发路径是否为默认加载器，而不是自定义外部提取引擎或浏览器端提取。
• 检查出问题的文件是否为二进制内容但使用了允许上传的扩展名（例如 .txt）。
• 检查后端日志中是否出现 Falling back to latin-1 encoding for ...。
• Issue 未提供 Python、CUDA、PyTorch、显卡等信息，无需也无法据此排查。

解决步骤

1. 先确认现象：把疑似二进制文件上传到知识库，观察其状态是否为 completed，同时在日志中查找是否出现 Falling back to latin-1 encoding for ...。如果两者同时出现，基本可以确认走了 latin-1 文本回退路径。
2. 在默认加载器层面，Issue 请求的“可选的二进制拒绝检查”尚未作为现成配置项提供，因此无法通过一个开关直接解决，暂无确认的一步修复方案。
3. 可优先尝试的规避方式：改用自定义外部文档提取引擎处理文件，这是 Issue 评论中给出的替代思路。
4. 可优先尝试的其他规避方式（Issue 中列为 alternatives，但明确指出对默认加载器无效或有限）：RAG_ALLOWED_FILE_EXTENSIONS 只按扩展名过滤、不检查内容，因此对 .txt 二进制无效；上传前自行过滤文件；或使用外部提取服务。
5. 如果你希望推动功能落地，可以关注该 Issue 的后续状态或相关实现，而不是依赖当前版本的默认行为。

验证方法

对同一批文件重复上传，观察其是否仍被标记为 completed 并产生乱码分块。

• 如果改用自定义外部提取引擎后，二进制文件不再被成功索引，或返回明确的失败/错误信息，说明规避方式生效。
• 如果默认加载器行为未变，日志中仍出现 Falling back to latin-1 encoding for ...，且知识库中仍出现乱码 chunk，则说明该版本尚未包含所请求的拒绝机制。

参考来源

open-webui/open-webui #31941

AI 工具推荐

想把多个 AI 模型放在一个入口？

GamsGo AI 集成 ChatGPT、DeepSeek、Gemini、Claude、Midjourney、Veo 等常用模型，适合写作、绘图、视频和日常 AI 工作流。

了解 GamsGo AI

推广链接：通过此链接购买，我可能获得佣金，不影响你的价格。