后端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 语言提供了一套基于 FFI 的插件管理 API其中xberg_list_post_processors用于查询全局注册表当前已注册的全部后处理器Post-Processor名称。读完本文你将掌握该 C 函数的完整调用方式、返回值与错误处理约定、配套的_len辅助函数用法以及它背后 Rust 核心注册表按处理阶段与优先级组织、带读锁保护的实现原理从而能够在自己的 C 项目中安全地枚举和管理 xberg 的插件资源。一、C 端完整调用示例xberg 文档站中由 alef 自动生成的 C 语言插件 API 代码片段post_processors_list.md展示了最简调用流程其标题为 List all registered post-processors。完整可运行示例如下#include assert.h #include stdint.h #include stdio.h #include stdlib.h #include string.h #include xberg.h int main(void) { char* result xberg_list_post_processors(); xberg_free_string(result); return EXIT_SUCCESS; }这段示例包含两个关键动作调用xberg_list_post_processors()从全局后处理器注册表中列出所有已注册的后处理器名称返回一个 NUL 结尾的 C 字符串调用xberg_free_string(result)释放该字符串防止内存泄漏。xberg 的 C ABI 遵循“谁分配、谁必须用对应 free 函数释放”的约定所有由 xberg 返回的字符串都必须经由xberg_free_string释放见 xberg.h 中的声明。实际业务中你可以先打印返回值再释放。由于该函数返回的是 JSON 数组字符串Rust 侧VecString经serde_json序列化C 侧通常配合strlen/strtol等解析或直接交给 JSON 库处理int main(void) { char* result xberg_list_post_processors(); if (result NULL) { fprintf(stderr, listing failed: %s\n, xberg_last_error_message()); return EXIT_FAILURE; } printf(registered post-processors: %s\n, result); xberg_free_string(result); return EXIT_SUCCESS; }二、C ABI 签名与配套函数在 xberg.h 中xberg_list_post_processors的声明为char *xberg_list_post_processors(void); uintptr_t xberg_list_post_processors_len(void);头文件注释明确了以下语义xberg.h#L29950-L29978项目说明返回值成功时返回 NUL 结尾的 C 字符串注册表内所有后处理器名称的 JSON 数组失败如注册表锁被毒化、序列化失败时返回NULL内存管理返回的字符串必须由调用方使用xberg_free_string释放线程约定长度函数_len返回“本线程最近一次主调用”产生的字符串字节长度错误约定返回NULL时应通过 xberg 的 last-error 接口获取具体错误信息与错误码配套的xberg_list_post_processors_len返回最近一次主调用产生的字符串字节长度当主调用返回NULL或在产生字符串前失败时返回0。头文件注释特别指出这个伴生 ABI 让 Zig、Java FFM Panama 等语言在构造字符串切片时无需做 NUL 扫描即可获得安全长度xberg.h#L29970-L29978。对纯 C 使用者而言它也可以用于在不strlen的情况下预估缓冲需求。三、FFI 实现Rust 侧的调用链xberg_list_post_processors的 FFI 实现位于 xberg-ffi/src/lib.rs#L85736-L85786其执行流程为clear_last_error()清空线程本地的错误状态保证本次调用的错误信息是全新的在std::panic::catch_unwind保护下调用核心库函数xberg::list_post_processors()lib.rs#L85740成功时将VecString用serde_json::to_string序列化为 JSON 数组字符串再经CString::new(...).into_raw()转为 C 字符串指针返回并通过set_last_return_len记录本线程的返回长度供_len函数读取失败时调用set_last_error记录错误码与错误消息返回NULL若核心调用发生 panic 且此前尚未记录更具体的错误则打上通用 panic 错误标记保证上下文不丢失lib.rs#L85765-L85775。_len伴生函数同样在 panic 保护下读取线程本地的last_return_len记录lib.rs#L85784-L85786因此“长度查询必须紧跟在同一次成功调用的同一线程之后使用”是其正确使用前提。四、核心注册表list_post_processors 的 Rust 实现FFI 层只是薄封装真正的逻辑在核心 crate 中。plugins/processor/registry.rs#L28-L35 中的实现只有四行核心代码pub fn list_post_processors() - crate::ResultVecString { use crate::plugins::registry::get_post_processor_registry; let registry get_post_processor_registry(); let registry registry.read(); Ok(registry.list()) }它先取得全局后处理器注册表registry/mod.rs#L127 中返回ArcRwLockPostProcessorRegistry然后获取读锁RwLock::read()最后调用registry.list()。这意味着并发安全列举操作持读锁多个 C 线程可以同时调用xberg_list_post_processors而不互相阻塞只有注册/移除操作需要写锁失败条件文档注释说明唯一返回Err的场景是“注册表锁被毒化”某个持写锁的线程 panic 导致 lock poisoned这正是 C 侧会收到NULL返回并需要读取 last-error 的原因返回值即名称列表list()直接返回所有已注册后处理器的名称向量registry/processor.rs#L148-L151。注册表内部结构从 PostProcessorRegistry 的源码结构看注册表按两个维度组织处理器pub struct PostProcessorRegistry { processors: HashMapProcessingStage, BTreeMapi32, VecArcdyn PostProcessor, name_index: HashMapString, (ProcessingStage, i32), generation: u64, }外层HashMapProcessingStage, ...按处理阶段ProcessingStage分组同一阶段内再按优先级i32排序——源码注释说明优先级来自PostProcessor::priority()trait 方法默认值为 50数值越大越先运行processor.rs#L42-L46name_index是名称到阶段、优先级的倒排索引list()直接取name_index的键集合返回因此列举成本与已注册数量线性相关且无需遍历全部阶段generation字段在每次注册/移除后递增供缓存快照如处理器缓存检测自身是否过期——从源码结构看这是一个用于失效判断的“代数”机制注册时的名称必须通过校验非空且仅允许字母、数字、连字符和下划线processor.rs#L55-L60因此你在 C 侧拿到的名称列表天然满足这套命名约束。五、e2e 测试对行为契约的验证xberg 的端到端测试以 JSON fixture 驱动post_processors_list场景定义在 fixtures/plugin_api/post_processors_list.json其要点category为post_processor_managementcall为list_post_processors断言类型为not_error——即该调用不应产生错误且文档元数据标注side_effects: safe纯查询、无副作用。对应到 Rust 侧的 e2e 测试 e2e/rust/tests/post_processor_management_test.rs#L15-L19#[test] fn test_post_processors_list() { // List all registered post-processors let _ list_post_processors().expect(call failed); }同一 fixture 还会被 wasm、node、python、php、ruby、elixir、zig 等多语言 e2e 套件消费例如 e2e/python/tests/test_post_processor_management.py保证各语言绑定上list_post_processors的语义一致正常状态下调用成功、返回列表可迭代。六、实践建议与边界说明结合上述实现在 C 项目中集成该 API 时建议遵循以下约定判空后再使用先检查返回值是否为NULL失败时读取 last-error 接口获取错误码/消息而不是直接打印务必释放每条成功返回的字符串都必须xberg_free_string包括你在if分支中提前return的路径长度查询与主调用同线程相邻xberg_list_post_processors_len读取的是线程本地记录若期间本线程调用了其他 xberg 字符串函数记录会被覆盖注册表是进程级全局的列举结果反映当前进程注册表的全部后处理器注册/移除发生在其他线程时需写锁你的下一次调用会看到更新后的集合与 Rust 侧行为对齐C 侧拿到的是 JSON 数组字符串而非裸指针数组这与xberg::list_post_processors() - VecString的序列化约定一致解析时按 JSON 数组处理即可。以上行为均以当前仓库中 crates/xberg-ffi/include/xberg.h、crates/xberg-ffi/src/lib.rs 与 crates/xberg/src/plugins/processor/registry.rs 的实际代码为准若后续 FFI 层新增字段或错误码建议以仓库头文件中的注释更新为准进行适配。赞分享后端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 FFI 插件 API 实战xberg_list_embedding_backends 枚举已注册嵌入后端xberg C FFI 插件 API 实战xberg_list_embedding_backends 枚举已注册嵌入后端 本文以 xberg 的 C FFI后端AI 应用NLPxberg C FFI 后处理器注册表管理xberg_clear_post_processor 与 post_processors_clear 实战解析xberg C FFI 后处理器注册表管理xberg_clear_post_processor 与 post_processors_clear 实战解析 本文后端AI 应用NLPxberg C API 实战用 xberg_list_reranker_backends 枚举全部已注册的 Reranker 后端xberg C API 实战用 xberg_list_reranker_backends 枚举全部已注册的 Reranker 后端 本文围绕 xberg 的后端AI 应用NLP上一篇7个实用技巧让你彻底掌握Mihon阅读数据统计时长跟踪与完成率分析终极指南下一篇Lefthook stage_fixed 实战指南让 pre-commit 钩子自动暂存修复后的文件创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考