后端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点击查看免费下载extraction_timeout_secs是 xbergRust 核心的多语言文档智能引擎中控制单次文档提取耗时的核心配置项它以秒为单位为每次提取设置硬性时间上限默认 600 秒10 分钟可通过 JSON 配置传入各语言绑定并在超时时返回携带elapsed_ms/limit_ms的结构化TimeoutError。本文以 C 语言契约测试用例 为骨架结合核心配置定义、提取引擎与批量调度实现完整讲清该字段的语义、默认值、C API 用法、底层tokio::time::timeout 取消令牌cancellation token机制以及批量场景下的边界行为读完即可在自己的绑定或 CLI/REST 场景中正确配置与诊断提取超时。字段语义与默认值extraction_timeout_secs定义在核心提取配置ExtractionConfig中类型为Optionu64见 配置定义/// Default per-file timeout in seconds for batch extraction. /// /// When set, each file in a batch will be canceled after this duration /// unless overridden by [FileExtractionConfig::timeout_secs]. /// /// Defaults to Some(600) (10 minutes) to prevent pathological files /// (e.g. deeply nested archives, documents with millions of cells) from /// running indefinitely and exhausting caller resources, while still /// giving slow paths (VLM-based OCR, large scanned documents) enough /// headroom to finish. Set to None to disable the timeout for trusted /// input or long-running workloads. #[serde(default ExtractionConfig::default_extraction_timeout)] pub extraction_timeout_secs: Optionu64,从源码注释可以提炼出三条关键语义默认值为Some(600)即 600 秒 / 10 分钟。即使调用方完全不传该字段所有提取路径也默认受超时保护防止病态文档如深层嵌套压缩包、含数百万单元格的表格无限运行、耗尽调用方资源。None表示关闭超时适用于完全可信的输入或需要长时间运行的工作负载。注意默认配置默认不是None需要显式设置才能禁用。批量粒度它是每个文件per-file / per-document的超时而非整个批量操作的总超时批量中的每个文件独立计时、独立判定。逐文件覆盖FileExtractionConfig.timeout_secs文档注释提到该字段可被FileExtractionConfig::timeout_secs覆盖。在 with_file_overrides 中逐文件覆盖逻辑为if let Some(v) timeout_secs { config.extraction_timeout_secs Some(*v); }也就是说调用方可以在extract_batch的每个输入项上附带FileExtractionConfig为单个文件单独指定超时而批量级默认值仍然作用于其余文件批量级字段如max_concurrent_extractions不受逐文件覆盖影响。C 绑定中的配置传递契约测试用例解读仓库以 alef 契约测试的形式给出了 C 语言下验证该字段的最小可运行示例即 config_extraction_timeout.md该文件由 alef 自动生成标注DO NOT EDIT#include assert.h #include stdint.h #include stdio.h #include stdlib.h #include string.h #include xberg.h int main(void) { XBERGAlefHandle input_handle xberg_extract_input_from_json({\kind\:\uri\,\uri\:\https://example.com/pdf/fake_memo.pdf\}); XBERGAlefHandle config_handle xberg_extraction_config_from_json({\extraction_timeout_secs\:300}); XBERGAlefHandle result xberg_extract(input_handle, config_handle); xberg_extract_input_free(input_handle); xberg_extraction_config_free(config_handle); xberg_extraction_result_free(result); return EXIT_SUCCESS; }这段代码演示了 xberg C API 的标准三段式用法四个函数在 FFI 头文件 中均有声明xberg_extract_input_from_json(const char *json)把 JSON 形式的ExtractInput此处为kind: uri的远程文档输入反序列化为不透明句柄见 xberg.h 声明xberg_extraction_config_from_json(const char *json)把 JSON 形式的提取配置反序列化为配置句柄见 xberg.h 声明本用例仅设置extraction_timeout_secs: 300其余字段全部走默认值xberg_extract(input, config)执行单次提取返回结果句柄见 xberg.h 声明三个*_free调用释放输入、配置、结果句柄避免内存泄漏。FFI 层还暴露了与超时直接相关的辅助函数便于从 C 侧查询运行时状态xberg_extraction_config_extraction_timeout_secs(handle)/xberg_extraction_config_has_extraction_timeout_secs(handle)读取配置中是否设置了超时及具体秒数xberg.hxberg_extraction_config_default_extraction_timeout()返回默认超时值 600供调用方在未显式配置时按默认值 600 秒执行的场景下做展示或校验xberg.h。该用例验证的两个契约点用例描述明确写道Tests that extraction_timeout_secs config field is accepted and does not affect fast extractions即契约测试关注两点字段可被接受xberg_extraction_config_from_json解析包含extraction_timeout_secs: 300的 JSON 不会失败配置校验通过提取正常执行不影响快速提取对一个很快就能完成的文档本用例是小型 PDF配置超时不会误伤——超时只在耗时超过阈值时才触发快速路径在tokio::time::timeout内正常返回结果不会因为设置了超时而产生额外开销或误判。对应的契约 fixture 在 config_extraction_timeout.json 中给出了更完整的断言细节测试通过 mock server 提供https://example.com/pdf/fake_memo.pdf响应content-type: application/octet-stream正文为 PDF 二进制并断言results[0].mime_type application/pdf、results[0].content最小长度 10。也就是说带上 300 秒超时配置的提取必须成功识别出 PDF 并产出非空文本内容——这正是不影响快速提取的可验证落点。底层实现timeout 包装与取消令牌配置字段最终如何落地为真正的超时行为核心逻辑位于 bytes 提取路径其模式可以概括为把整个提取 future 用tokio::time::timeout包裹超时则触发cancel_token.cancel()并返回XbergError::Timeout。无显式令牌时的内部兜底在 extract_bytes 入口 中实现会检查当配置了extraction_timeout_secs但调用方未提供cancel_token时通过ensure_cancel_token安装一个内部取消令牌#[cfg(all(feature tokio-runtime, not(target_arch wasm32)))] let config: ExtractionConfig if config.extraction_timeout_secs.is_some() config.cancel_token.is_none() { let mut owned config.clone(); owned.ensure_cancel_token(); owned_config_with_cancel_token owned; owned_config_with_cancel_token } else { config };ensure_cancel_token 的实现与注释说明了一个重要的正确性细节绑定驱动binding-driven和 CLI 驱动的调用通常不会携带cancel_token如果没有这个兜底超时只会让等待方返回XbergError::Timeout而已经 spawn 出去的提取工作仍会继续运行并占用工作线程安装了内部令牌后token.cancel()能真正中止提取。调用方自带的令牌始终不被覆盖REST 取消路径与 Rust 调用方观察到的仍是同一个共享令牌。超时判定与错误构造核心计时逻辑在 bytes.rs 的 timeout 分支#[cfg(all(feature tokio-runtime, not(target_arch wasm32)))] let result if let Some(secs) config.extraction_timeout_secs { let start std::time::Instant::now(); match tokio::time::timeout(std::time::Duration::from_secs(secs), extraction_future).await { Ok(inner) inner, Err(_elapsed) { if let Some(ref token) config.cancel_token { token.cancel(); } Err(crate::XbergError::Timeout { elapsed_ms: start.elapsed().as_millis() as u64, limit_ms: secs * 1000, }) } } } else { extraction_future.await };超时后的错误对象携带两个诊断字段elapsed_ms实际已耗时与limit_ms配置的秒数 × 1000调用方无需自行计时即可定位差多久超时。注意该分支与令牌安装一样被cfg(all(feature tokio-runtime, not(target_arch wasm32)))门控在 wasm32 或未启用tokio-runtime的目标上由于没有可用的 tokio 定时器且 WASM 下std::time::Instant::now()会 panic代码会选择忽略该限制并继续运行提取同时输出tracing::debug日志extraction_timeout_secs is ignored on this target (no usable tokio timer); running without a timeout见 bytes.rs。这是默认值为 600 秒在受限目标上不会导致每次调用都报错的关键设计。批量提取逐项超时与共享 URL 的特殊语义在extract_batch批量路径中超时按逐项施加。调度器在 run_batch_item 中对每个输入单独包裹tokio::time::timeoutlet mut result match timeout_secs { Some(secs) match tokio::time::timeout(std::time::Duration::from_secs(secs), extraction_future).await { Ok(inner) inner, Err(_elapsed) { if let Some(ref token) cancel_token { token.cancel(); } Err(XbergError::Timeout { elapsed_ms: start.elapsed().as_millis() as u64, limit_ms: secs * 1000, }) } }, None extraction_future.await, };批量入口 resolve_batch_input_config 在解析每个输入的分辨配置时同样会执行ensure_cancel_token确保逐项取消令牌就绪成功项还会把实际耗时写入metadata.extraction_duration_ms供调用方观测每个文件的实际提取耗时。一个容易踩坑的边界共享 URL 组批量输入中出现多个相同 URL 时xberg 会通过共享 URL 组shared-URL group复用同一个抓取结果。此时超时语义有一个精确的细微差别见 finalize_shared_item 的实现注释批量模式下真正的网络抓取发生在 crawlberg 的batch_scrape/batch_crawl内部由共享的CrawlConfig如request_timeout_ms、rate_limit_ms管理并发与单请求超时。因此逐项per-item的extraction_timeout_secs只约束转换阶段extract_bytes管线即 finalize_shared_item 包裹的部分而在非共享的逐项路径中同一个超时同时约束网络抓取与转换。换句话说对普通输入超时覆盖下载 转换全程对共享 URL 组中的重复 URL超时仅从转换阶段开始计时下载阶段由爬虫配置另行控制。设计批量超时时如果需要限制共享 URL 的下载耗时应当同时配置url子配置中的抓取超时参数。超时错误的跨接口传播XbergError::Timeout在 xberg 的所有对外接口中都有统一、可机器识别的表示接口超时表现依据REST APIerror_type为TimeoutError归入Internal状态类别error.rs 的 api_error_type、api_status_category批量错误项error_type为timeout数值错误码1014error.rs 的 extraction_error_type / codeMCP错误消息格式化为Extraction timed out after {elapsed_ms}ms (limit: {limit_ms}ms)MCP 错误映射其中数值错误码 1014 与 FFI 稳定错误码一一对应跨语言绑定C、Go、Java、Python 等判断超时时应优先匹配error_type timeout或code 1014而不是依赖人类可读的消息文本。REST 服务层service/mod.rs还提供了独立的TimeoutService包装可在服务构建器层面如with_timeout(Duration::from_secs(30))为整个请求管线追加兜底超时将超时的BoxError统一转换为XbergError::Timeout与配置字段形成配置内超时 服务层兜底的双层防护。配置建议与注意事项综合源码实现给出几条实操建议快速提取无需调整契约测试证明 300 秒这类宽松超时对毫秒级完成的普通文档零影响只有真正卡住的病态文档才会触发取消。日常使用可保持默认 600 秒。慢速 OCR / VLM 场景调大或禁用VLM 驱动的 OCR、大型扫描件耗时可能接近 10 分钟若频繁超时可在 JSON 配置中调大该值或在完全可信的内网输入上显式设为null禁用如{extraction_timeout_secs: null}。批量内逐文件差异化通过FileExtractionConfig.timeout_secs为单个大文件单独放宽其余文件维持默认共享 URL 组的下载阶段需另配url.crawl抓取超时。受限目标自知wasm32 / 无tokio-runtime构建下该配置会被忽略并回退为无超时运行依赖该字段做硬性资源上限的应用应避免在这些目标上部署。超时诊断看结构化字段捕获错误后读取elapsed_ms/limit_ms配合结果项的extraction_duration_ms元数据可以快速区分输入本身慢还是配置过紧。进一步探索可在仓库中查看契约 fixture config_extraction_timeout.json 与 C 用例 config_extraction_timeout.md超时核心实现 extract_bytes、run_batch_item配置定义与覆盖逻辑 ExtractionConfig错误码与类型映射 error.rs以及 FFI 句柄 API 声明 xberg.h。赞分享后端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点击查看免费下载相关推荐微前端方案怎么选Magic Microservices对比qiankun、single-spa完整指南微前端方案怎么选Magic Microservices对比qiankun、single spa完整指南 Magic Microservices READM后端AI 应用NLP如何通过浏览器脚本彻底改造你的B站体验Bilibili-Evolved终极指南如何通过浏览器脚本彻底改造你的B站体验Bilibili Evolved终极指南 你是否厌倦了哔哩哔哩千篇一律的界面是否渴望拥有更强大的视频管理功能是否希望后端AI 应用NLPaxios超时控制请求超时与重试机制详解axios超时控制请求超时与重试机制详解 你是否曾因网络波动导致请求失败而困扰是否在处理关键业务时因超时设置不当引发用户投诉本文将系统讲解Axios超时控网络后端前端上一篇librealsense 实战3 步让 RealSense 深度相机的第一帧数据跑起来下一篇youtube-dl-gui窗口布局锁定防止误操作创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考