后端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 批量文档提取接口extract_batch的一项核心安全配置展开如何通过security_limits.max_content_size限制单次提取可产生的内容字节数在不可信输入归档炸弹、超大解压文本、恶意图像面前保持进程内存与 CPU 安全。文中以 C 语言 FFI 调用为例逐行解读官方测试夹具的写法并结合 Rust 核心中SecurityLimits的字段默认值、StringGrowthValidator与 ZIP 解压路径的强制逻辑讲清该上限在何处生效、为何生效、如何触发与规避。读完你将能够在任意绑定语言中为批量提取配置安全预算并准确判断错误来源。一次批量提取如何因内容过大而失败C 代码全文解读Xberg 的端到端测试体系alef为每种绑定语言生成了对同一份语义夹具的调用代码。C 语言的这份 extract_batch_bytes_size_cap 片段 完整展示了触发场景原文如下#include assert.h #include stdint.h #include stdio.h #include stdlib.h #include string.h #include xberg.h int main(void) { XBERGAlefHandle config_handle xberg_extraction_config_from_json({\security_limits\:{\max_content_size\:1}}); XBERGAlefHandle result xberg_extract_batch([{\bytes\:\text/fake_text.txt\,\kind\:\bytes\,\mime_type\:\text/plain\}], config_handle); if (result ! 0) { return EXIT_FAILURE; } xberg_extraction_config_free(config_handle); return EXIT_SUCCESS; }逐行拆解构建配置句柄xberg_extraction_config_from_json(...)把 JSON 字符串反序列化为ExtractionConfig句柄。这里只设置了一个键security_limits.max_content_size: 1其余字段全部走默认值。max_content_size的单位是字节1意味着本次提取产生的内容超过 1 字节就拒绝。发起批量提取xberg_extract_batch(inputs, config_handle)接收两个参数——一个 JSON 数组字符串多个输入和一个配置句柄。输入[{bytes:text/fake_text.txt,kind:bytes,mime_type:text/plain}]声明了一个kind bytes的输入mime_type为text/plain其中bytes字段指向演示文件路径text/fake_text.txtalef 在生成文档时用该路径代表真实字节负载对应夹具 bytes_size_cap.json 中实际填入的是 100 个a字节。契约判断C ABI 中XBERGAlefHandle是文档句柄的标量表示成功时返回非零句柄失败时返回哨兵值0。if (result ! 0) { return EXIT_FAILURE; }即若调用没有返回错误哨兵即意外成功则整个程序判失败——这是一个期望触发错误的断言式写法。释放资源调用成功后通过xberg_extraction_config_free(config_handle)归还配置句柄避免句柄泄漏。该片段对应的语义夹具位于 fixtures/batch/bytes_size_cap.json其assertions为[{ type: error }]config为{security_limits: {max_content_size: 1}}即在 1 字节的内容上限下这批输入必须整体报错而不是返回部分成功或静默截断。SecurityLimits一份完整的提取安全预算表max_content_size只是 Xberg 安全预算中的一个维度。全部维度定义在 crates/xberg/src/extractors/security.rs 的SecurityLimits结构体中其默认值见同文件 Default 实现如下字段默认值语义max_archive_size500 MiB归档解压后的总大小上限防解压炸弹max_compression_ratio100压缩比上限超出即判定为潜在 ZIP 炸弹max_files_in_archive10 000归档内文件数量上限max_nesting_depth1024结构嵌套深度上限XML、JSON、对象等max_entity_length1 MiB单个 XML 实体/属性/令牌的长度上限专防 billion-laughs 类攻击max_content_size100 MiB单次操作的字符串增长与解码图像分配预算max_iterations10 000 000解析循环迭代次数上限防 CPU 空转max_xml_depth1024XML 元素深度上限max_table_cells100 000单文档聚合表格单元格上限CSV/XLSX/HTML 表格max_pagesNone不限单文档页数上限仅对 PDF、PPTX、Keynote、ODP、多帧 TIFF 生效关于max_content_size的精确定义源码注释写得很明确security.rsMaximum string growth and decoded image allocation per operation (100 MB). Per-page passes such as layout detection charge each batch against this limit, not the whole document; onlymax_pagesbounds the rasters retained across a document.也就是说它钳制的是单次操作的累积文本增长与解码图像分配而不是简单的输入文件大小。逐页流程如版面检测按批次分别计费不会跨整个文档累计跨文档保留的栅格图像则交给max_pages控制。在配置参考configuration.md中ExtractionConfig.security_limits的说明进一步确认该配置除了防解压炸弹还为所有摄入用户可控字节的提取路径钳制嵌套深度、迭代次数、实体/令牌长度、总内容大小、解码图像分配与表格单元格数量。同时它被明确列为批量级全局策略在FileExtractionConfig的Excluded Fields清单中security_limits与max_concurrent_extractions、use_cache、acceleration一样不允许按单文件覆盖——整个批次共享同一份安全预算这是为了防止恶意输入通过逐文件放宽限额绕过防护。上限如何被强制执行从 ZIP 成员解压到文本累积器max_content_size不是仅存在于配置里的声明它在多处提取路径上被实际执行。核心机制是一组与单次提取绑定的校验器见 security.rs 的StringGrowthValidator累积式检查提取器在把用户可控内容累积进String/Vecu8时要求先调用check_append(len)记账再写入使生成方能在二次方拼接 / billion-laughs 式攻击演变成 OOM 之前提前停止累计值用饱和加法更新恶意输入无法通过整数回绕绕过。预算捆绑SecurityBudget::from_limits将深度、迭代、实体长度、字符串增长、表格单元格五个校验器捆绑成一份预算解析器线程只需持有一个可变引用即可逐事件强制执行它从ExtractionConfig.security_limits覆盖项构建未设置时回落到默认值。以归档提取为例crates/xberg/src/extraction/archive/zip.rs 展示了max_content_size在 ZIP 文本成员解压路径上的两道闸门单成员读取钳制zipcrate 只对压缩侧加Take限制声明在头部的大小字段并不会约束解压结果因此解压端被手动钳制在max_content_size 1字节。若读取结果超过上限直接返回validation错误ZIP archive member ... exceeds max_content_size while decompressing (limit: ... bytes)——宁可硬性拒绝也不静默截断或跳过因为一旦静默就会比累积总量超限报错的更安静路径更不可观测。聚合总量闸门每个成员解码后的文本长度用饱和加法累加进total_content_size一旦超过max_content_size即返回ZIP archive text content exceeds limit: ... bytes (max: ... bytes)。一个容易误解的点为什么纯文本输入未必触发该上限细心的读者会发现一个矛盾上面 C 片段喂入的是一个text/plain纯文本输入而max_content_size: 1理应让它立刻超限。但同目录夹具 bytes_size_cap.json 的skip字段给出了权威解释SecurityLimits.max_content_sizeis only enforced by archive/Excel extractors; test requires actual archive format to trigger error, which is not easily testable via byte fixtures即max_content_size的硬性校验集中在归档ZIP/TAR/7Z/GZIP与 Excel 提取路径普通文本提取路径并不会对该字节输入做此校验。正因如此除 C 外的全部 14 种绑定语言都在该夹具上被跳过——它们难以用纯字节夹具稳定构造一个真实的归档格式来触发错误而 C 是唯一保留该断言的语言。这也解释了为何 C 片段中该调用被期望返回错误哨兵0在内容上限被强制执行的路径上1 字节的预算必然命中拒绝分支。错误契约失败时返回什么、去哪查详情xberg_extract_batch在 C 层失败时的行为见 crates/xberg-ffi/src/lib.rs返回哨兵句柄0这是 C ABI 所有提取入口的统一错误约定xberg_extract()同样如此见 C API 参考。错误详情FFI 内部将错误码与消息记录到线程本地错误槽set_last_error/set_handle_error宿主语言绑定可通过对应的xberg_last_error_*系列函数取回。底层错误类型在 Rust 核心中内容超限对应 SecurityError::ContentTooLarge其消息格式为Content too large: {size} bytes (max: {max} bytes)同一枚举还覆盖ZipBombDetected、ArchiveTooLarge、TooManyFiles、NestingTooDeep、EntityTooLong、TooManyIterations、XmlDepthExceeded、TooManyCells、TooManyPages等全部安全失败形态方便上层按类别区分限额问题与解析问题。批量输入的 JSON 形态与批次隔离语义extract_batch的第一个参数是一个输入数组字符串每个元素对应 ExtractInput 结构字段类型说明kindbytes/uri输入来源类型bytes需配合bytes字段uri需配合uri字段bytesbase64/字节序列kind bytes时的原始字节uri字符串本地路径、file://URI 或 HTTP(S) URLmime_type字符串MIME 类型提示参与类型探测filename字符串文件名提示用于 MIME 探测与元数据configFileExtractionConfig单输入覆盖项不含security_limits等批量级字段C 片段中的[{\bytes\:\text/fake_text.txt\,\kind\:\bytes\,\mime_type\:\text/plain\}]即为上述结构的 JSON 形态一个kind bytes、显式声明mime_type的输入。批量语义上单个输入超限不会拖垮整个批次——超时文件与错误输入以独立错误项返回其余输入继续处理ExtractionResult.errors收集非致命单输入错误但安全预算本身就是批次级的配置层面的上限一旦违反属于整个调用级别的问题。实战建议何时调低、何时调高面向不可信输入的服务端保持默认预算100 MiB通常是安全的起点若上游会接收超大扫描文档或深嵌套归档应显式设置max_content_size与max_pages、max_archive_size而不是依赖隐式默认。注意max_pages默认None不限因为它是一个工作负载相关上限默认拒绝真实大文档比风险本身更糟——需要显式开启security.rs。想要更严格将max_content_size压到数 MiB 级别可显著压低恶意归档的单次解压峰值与文本累积峰值配合max_compression_ratio默认 100:1与max_files_in_archive默认 10 000构成完整的三道归档防线。信任度高的内部管道可上调max_table_cells解析大量合法大表时或调大max_content_size但应优先用max_pages限制逐页工作总量因为页数才是文档级成本的主因——单页压缩后可只有几 KB但成千上万页的逐页 OCR/版面工作会远超任何字节预算。运维可观测性安全拒绝以明确的validation错误返回消息中带实际大小与上限值不要把这些错误当成解析失败去修复而应视为资源预算触顶信号。小结extract_batch的security_limits.max_content_size是 Xberg 面向不可信文档的一道关键防线它以单次操作的累积字符串增长与解码图像分配为计量对象通过StringGrowthValidator与SecurityBudget在归档解压、Excel、文本累积等多条路径上强制记账超限即报ContentTooLarge类错误而非静默截断。C 绑定中失败表现为哨兵句柄0配合本仓库的夹具bytes_size_cap.json与安全模块源码security.rs、zip.rs即可完整复现、诊断并调优这一安全预算机制。赞分享后端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 绑定实战extract_batch 批量提取中的安全限制与 max_content_size 尺寸上限xberg C 绑定实战extract_batch 批量提取中的安全限制与 max_content_size 尺寸上限 本篇基于 xberg 仓库中自动生成的后端AI 应用NLPxberg 配置详解独立于提取线程预算的 LLM 并发上限max_concurrencyxberg 配置详解独立于提取线程预算的 LLM 并发上限max_concurrency 本文围绕 xberg 的契约contract测试 confi后端AI 应用NLP学之思考试系统Mysql版在线考试页面设计用户体验与交互优化学之思考试系统Mysql版在线考试页面设计用户体验与交互优化 学之思开源考试系统xzs mysql是一款基于JavaVue的前后端分离考试系统以其简洁后端前端教育小程序上一篇10分钟管完Windows右键菜单ContextMenuManager 清理、新增与排序完整上手指南下一篇Sec-Fetch-Dest: email-verification 头解析Email Verification API 的新请求指纹创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
