后端AI 应用NLP【免费下载链接】xbergPolyglot document intelligence with a Rust core: extract text, metadata, images, tables, and structured data from 106 formats across 140 file extensions, plus code intelligence for 371 languages. Fifteen bindings, with CLI, REST API, and MCP server.项目地址https://gitcode.com/gh_mirrors/kr/xberg点击查看免费下载xberg 以 Rust 为核心实现了全局 OCR 后端注册表Elixir 绑定通过Xberg.list_ocr_backends/0一行即可拿到当前进程中所有已注册 OCR 后端的名称列表用于能力协商、诊断与动态路由。本文以仓库中的官方 Elixir 示例片段为骨架结合 Rust 核心源码与端到端测试完整讲解该 API 的用法、返回契约、底层调用链以及与之配套的能力枚举、注册注销与语言探测接口读完即可在真实 Elixir 项目中安全地查询和管理 OCR 后端。一、这个 API 解决什么问题xberg 的 OCR 能力由后端backend组成内置的 Tesseract、Paddle、sceptre、VLM 等后端以及通过插件机制注册的第三方后端统一存放在一个全局注册表中。应用在运行期经常需要回答一个简单但关键的问题当前环境里到底有哪些 OCR 后端可用list_ocr_backends就是回答这个问题的入口。它返回所有已注册 OCR 后端的名称列表典型使用场景包括诊断与排障确认某个后端是否真的注册成功尤其是插件式注册之后能力协商在提交 OCR 任务前先确认目标后端存在避免后端未注册的运行时错误动态路由在同一进程内注册多个后端时根据名称选择要使用的后端自动化验收作为 CI/端到端测试中的断言目标验证注册表状态符合预期。该 API 属于registry分类在仓库中被标注为side_effect: safe无副作用意味着可以安全地反复调用而不改变任何状态详见 fixtures/registry/list_ocr_backends.json。二、Elixir 中的最小可用示例仓库中的官方 Elixir 示例片段docs-site/src/snippets-generated/elixir/registry/list_ocr_backends.md给出了完整调用方式result Xberg.list_ocr_backends() IO.inspect(result)把这段代码放进iex会话或 Mix 项目脚本中即可打印当前注册的所有 OCR 后端名称iex(1) result Xberg.list_ocr_backends() {:ok, [paddle, sceptre, tesseract]} iex(2) IO.inspect(result) {:ok, [paddle, sceptre, tesseract]}从绑定声明packages/elixir/lib/xberg.ex#L171-L175可以确认其返回契约doc List all registered OCR backends. spec list_ocr_backends() :: {:ok, [String.t()]} | {:error, atom, String.t()} def list_ocr_backends do Xberg.Native.list_ocr_backends() end成功返回{:ok, [String.t()]}列表元素是各后端的注册名如tesseract失败返回{:error, atom, String.t()}例如注册表锁无法获取锁中毒等内部错误若绑定未正确加载本地 NIFXberg.Native.list_ocr_backends/0会抛出:erlang.nif_error(:nif_not_loaded)见 packages/elixir/lib/xberg/native.ex#L235-L255这通常意味着 Elixir 包没有编译出 Rust NIF 动态库需要重新编译或检查运行环境。三、完整调用链从 Elixir 到 Rust 核心list_ocr_backends/0的调用并不止于 Elixir 层它一路穿透到 Rust 核心的全局注册表。完整链路如下Xberg.list_ocr_backends/0 → Xberg.Native.list_ocr_backends() NIF 存根native.ex → xberg_nif 的 NIF 导出函数 packages/elixir/native/xberg_nif/src/lib.rs → xberg::plugins::list_ocr_backends() Rust 核心crates/xberg/src/plugins/ocr.rs → OCR_BACKEND_REGISTRY 单例 全局 RwLock 注册表 → OcrBackendRegistry::list() crates/xberg/src/plugins/registry/ocr.rs各环节的实现要点如下。1. NIF 导出层。packages/elixir/native/xberg_nif/src/lib.rs中对应的导出函数对核心函数做了错误字符串化与包装pub fn list_ocr_backends() - ResultVecString, String { let result xberg::list_ocr_backends().map_err(|e| e.to_string())?; // ... 转换为 Elixir 术语 }2. Rust 核心入口。crates/xberg/src/plugins/ocr.rs#L609-L616 的实现非常直白——获取全局注册表加读锁返回registry.list()pub fn list_ocr_backends() - crate::ResultVecString { use crate::plugins::registry::get_ocr_backend_registry; let registry get_ocr_backend_registry(); let registry registry.read(); Ok(registry.list()) }3. 全局单例注册表。crates/xberg/src/plugins/registry/mod.rs#L94-L98 定义了get_ocr_backend_registry()返回ArcRwLockOcrBackendRegistry由LazyLock惰性初始化的OCR_BACKEND_REGISTRY静态变量支撑。这意味着所有注册、注销、列举操作都围绕同一个进程级注册表进行读写并发安全。4. 注册表实现。OcrBackendRegistry内部以HashMapString, Arcdyn OcrBackend保存名称到后端对象的映射从 crates/xberg/src/plugins/registry/ocr.rs 的backends字段与get、remove等方法的实现可以推断列举时取出全部键名并排序。四、返回值的确定性与排序保证一个值得注意的细节list_ocr_backends/0的返回列表是确定有序的。crates/xberg/src/plugins/registry/ocr.rs#L351-L356 的实现如下/// List all registered backend names. pub fn list(self) - VecString { let mut names: Vec_ self.backends.keys().cloned().collect(); names.sort_unstable(); names }即无论后端以什么顺序注册返回列表都会按名称做一次字典序排序sort_unstable。这对下游非常友好日志与监控输出稳定可对比便于 diff 前后两次调用自动化测试不必关心注册顺序断言结果确定同一进程内多次调用结果一致除非注册表内容本身发生变化。配套的registered_snapshot()方法同样先按名称排序再返回crates/xberg/src/plugins/registry/ocr.rs#L358-L366保持整体一致性。五、不止是名字搭配能力枚举接口做完整查询list_ocr_backends/0只返回名称若需要每个后端支持哪些语言的完整画像仓库提供了能力枚举的配套接口全部在 packages/elixir/lib/xberg.ex 中Elixir 函数作用Xberg.list_ocr_backends/0返回所有已注册 OCR 后端名称排序后Xberg.list_ocr_backend_capabilities/0返回每个后端的名称 supported_languages列表Xberg.list_ocr_backend_capabilities_for/1同上但按传入config如tessdata_path下的实际解析结果回答Xberg.ocr_backend_supports_language/2判断指定后端是否支持某语言如engXberg.ocr_backend_supports_language_for/3同上但按config上下文回答在 packages/elixir/lib/xberg/native.ex#L187-L233 的文档注释中明确说明list_ocr_backend_capabilities是list_ocr_backends的能力枚举对应物——前者只暴露名称后者额外暴露每个后端的supported_languages()这样消费方例如任务受理门槛不需要硬编码第二份语言清单。使用这些接口时要注意两条重要语义均记录在 Rust 文档中空语言列表 ≠ 不支持任何语言。supported_languages()是带默认实现的 trait 方法默认返回空数组并非所有后端都重写了它。例如 VLM 后端VlmOcrBackend通过supports_language接受任意语言却继承了空的默认实现。因此判断某语言是否可用应使用ocr_backend_supports_language绝不能从空列表推断不支持见 crates/xberg/src/plugins/ocr.rs#L618-L637。能力枚举不是零成本。Tesseract 后端的supported_languages()首次调用时会分配一个 Tesseract API 实例并针对真实 OCR 任务会解析到的同一 tessdata 目录初始化以枚举已安装的语言后续调用才走缓存。list_ocr_backend_capabilities_for/1存在的意义正是config.tessdata_path会改变 Tesseract 解析到的 tessdata 目录无配置形式回答的是无覆盖搜索链下的结果可能与实际任务加载的目录不同见 packages/elixir/lib/xberg/native.ex#L225-L233 的 GH#1857 说明。六、注册表生命周期注册、注销与清空列举是只读操作但要理解返回内容的来源还需要知道注册表如何被填充和清空。同一模块中提供了一组配套的插件桥接函数注册Xberg.register_ocr_backend(genserver_pid, plugin_name, implemented_methods \\ [])。这是 Elixir 侧的插件桥接入口注册一个实现Xberg.OcrBackend.Hostbehaviour 的 GenServer 作为后端implemented_methods列出实现模块导出的函数名未列出的可选 trait 方法保留 Rust 侧默认行为见 packages/elixir/lib/xberg.ex#L489-L503。注销Xberg.unregister_ocr_backend(name_or_opts)同时支持位置参数和关键字列表两种形式底层会调用后端的shutdown()钩子对应 Rust 侧 crates/xberg/src/plugins/ocr.rs#L579-L586。清空Xberg.clear_ocr_backends/0对注册表执行shutdown_all并清空对应 crates/xberg/src/plugins/registry/ocr.rs#L379-L390 的clear/shutdown_all。插件后端的宿主 behaviourXberg.OcrBackend.Host定义了process_image/2、process_image_file/2、supports_language/1、supported_languages/0、supports_table_detection/0、process_document/2等回调以及可选的initialize/0、shutdown/0生命周期钩子完整清单见 packages/elixir/lib/xberg.ex#L414-L487。一个值得注意的边界情况从注册表源码注释看OcrBackendRegistry会区分空注册表与缺少内置默认后端两种需要重新播种re-seed的状态——例如调用clear后只注册了另一个非默认后端默认配置下的 OCR 会缺少可用的回退目标见 crates/xberg/src/plugins/registry/ocr.rs#L392-L399。因此在实际项目中清空注册表后应紧接着注册可用的后端再用list_ocr_backends/0验证结果。七、端到端验证与回归测试该 API 的正确性由仓库中的端到端测试与 alef 夹具共同保障。测试夹具。fixtures/registry/list_ocr_backends.json定义了该调用的契约call: list_ocr_backends、input: {}无参数、assertions为not_error即该调用不允许失败。这正是 docs-site/src/snippets-generated/elixir/registry/list_ocr_backends.md 中 Elixir 示例片段的生成来源——这些 snippet 文件由 alef 自动生成文件头部的注释To regenerate: alef e2e generate、To verify freshness: alef verify说明它们需要与夹具保持同步。Elixir 端到端测试。e2e/elixir/test/registry_test.exs#L16-L21 给出了对应的回归断言describe list_ocr_backends do test list_ocr_backends do result Xberg.list_ocr_backends() refute result in [nil, :error] end end该测试验证真实 NIF 环境下调用不返回nil或:error确保 Elixir 绑定、NIF 桥接与 Rust 核心注册表整条链路在端到端测试环境中是通的。Elixir 侧的运行入口可参考 e2e/elixir 目录下的 mix 项目配置。八、实用建议与常见问题结合上文分析在实际项目中使用Xberg.list_ocr_backends/0时可以参考以下几点把它当作纯查询接口无副作用、可重复调用适合放在诊断命令、doctor报告或监控探针中。xberg 还提供了Xberg.doctor/0与Xberg.doctor/1用于探测后端与配置在宿主机上的实际执行情况见 packages/elixir/lib/xberg.ex#L70-L92与列举接口配合可形成完整的健康检查。用模式匹配处理返回由于返回值是{:ok, list} | {:error, reason}结构推荐显式匹配case Xberg.list_ocr_backends() do {:ok, backends} - IO.puts(Registered OCR backends: #{Enum.join(backends, , )}) {:error, reason, message} - IO.puts(Failed to list OCR backends: #{reason} #{message}) end需要语言级判断时别用空列表下结论判断后端 A 是否支持法语请调用Xberg.ocr_backend_supports_language(A, fra)而不是依赖list_ocr_backend_capabilities返回的列表是否为空。注意能力枚举的首次成本list_ocr_backend_capabilities首次调用可能触发 Tesseract 实例初始化与 tessdata 扫描在延迟敏感路径上应缓存结果若配置了tessdata_path务必使用_for变体保持语义一致。结合注册表生命周期使用list_ocr_backends/0是验证注册、注销、清空效果的最直接手段——注册后确认新名称出现注销与清空后确认名称消失形成完整的可观测闭环。赞分享后端AI 应用NLP【免费下载链接】xbergPolyglot document intelligence with a Rust core: extract text, metadata, images, tables, and structured data from 106 formats across 140 file extensions, plus code intelligence for 371 languages. Fifteen bindings, with CLI, REST API, and MCP server.项目地址https://gitcode.com/gh_mirrors/kr/xberg点击查看免费下载相关推荐Xberg C 绑定使用 ListOcrBackends 枚举注册的 OCR 后端Xberg C 绑定使用 ListOcrBackends 枚举注册的 OCR 后端 本文围绕 Xberg 的 C 绑定中 XbergConverter.Lis后端AI 应用NLPxberg Dart 绑定实战深入解析 listOcrBackends 与 OCR 后端注册表枚举xberg Dart 绑定实战深入解析 listOcrBackends 与 OCR 后端注册表枚举 本篇指南以 xberg 的 Dart 绑定为入口讲解如何后端AI 应用NLPxberg C FFI 实战用 xberg_list_ocr_backends 枚举全局 OCR 后端注册表xberg C FFI 实战用 xberg_list_ocr_backends 枚举全局 OCR 后端注册表 本篇以 xberg 仓库中 C 语言示例片段 o后端AI 应用NLP上一篇终极指南如何使用Circuit构建高效且完整的故障断路器实现下一篇如何快速入门DefiLlama AdaptersDeFi数据聚合的终极指南创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
