后端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 开源仓库中 Go 语言 contract 片段api_extract_batch_bytes_with_config源文件见 docs-site/src/snippets-generated/go/contract/api_extract_batch_bytes_with_config.md展开讲解如何用 Go 绑定一次性批量提取多份二进制文档并针对其中某一输入单独指定提取配置per-input config。读完本文你将掌握xberg.ExtractBatch的完整调用方式、ExtractInput/FileExtractionConfig的字段语义、输出结果的读取方法以及它在 FFI 层的真实调用链与对应的合约断言可直接复用到你自己的批量文档处理管线中。一、场景定位什么时候使用批量字节提取xberg 是一个以 Rust 为核心的 polyglot 文档智能提取引擎README.md 描述其可处理 106 种格式、140 种扩展名。在实际业务中文档很少单份出现——无论是归档导入、定时任务还是数据管道一次性送入多份 PDF、DOCX、HTML 是常态。extract_batch接口正是为此设计它接受多个输入每个输入可以是一段原始字节bytes也可以是一个本地路径 /file://URI / HTTP(S) URL返回统一的结果信封。而本篇重点的 contract 场景api_extract_batch_bytes_with_config则进一步演示了一个关键能力批量提取时每个输入可以携带自己独立的config用于覆盖全局提取配置中的对应项。典型用途包括同一批文档中A 文件希望输出 Markdown、B 文件希望输出纯文本或者某份扫描件需要单独开启 OCR其余文件保持默认——不需要拆成多次调用一次ExtractBatch即可完成差异化处理。二、核心 API 一览三个关键类型2.1 ExtractInput一条输入描述一份文档ExtractInput在 Go 绑定中定义于 packages/go/binding.go字段JSON 字段名类型语义Kindkind*ExtractInputKind输入来源类型bytes时要求提供Bytesuri时要求提供URIBytesbytes[]bytekind bytes时的原始字节内容URIuri*stringkind uri时的本地路径、file://URI 或 HTTP(S) URLMimeTypemime_type*stringMIME 类型提示辅助识别Filenamefilename*string文件名提示用于 MIME 推断与元数据Configconfig*FileExtractionConfig该输入的独立提取配置覆盖per-input config注意源码注释中的约束bytes与uri二选一Kind决定哪个字段生效。2.2 FileExtractionConfigper-input 覆盖项FileExtractionConfigpackages/go/binding.go不是一份全新的配置而是一组覆盖项override字段为nil时沿用批量全局配置设置后仅对该文件生效。字段覆盖面很广包括输出相关ResultFormat、OutputFormat、IncludeDocumentStructureOCR 相关Ocr、ForceOcr、OcrStrategy、ForceOcrPages、DisableOcr内容相关Chunking、ContentFilter、Images、Keywords、Layout增强能力StructuredExtraction、Summarization、Translation、Ner、Redaction、Captioning、QrCodes资源控制TimeoutSecs该文件超时秒数超时的文件产生错误结果但不影响批内其他文件本合约示例使用的正是其中最常见的一个output_format: markdown。2.3 ExtractBatch 的返回值ExtractionResultExtractBatch返回*ExtractionResultpackages/go/binding.go其核心字段Results []ExtractedDocument按输入顺序排列的提取结果非致命错误per-input errors也随信封返回单个失败不会使整批失败。每份ExtractedDocumentpackages/go/binding.go包含Content提取文本、MimeType源文档 MIME如application/pdf、Metadata作者、标题、日期及格式相关字段、Counts页数/表格数/图片数等结构计数、DetectedLanguagesISO 639-1 语言码等。三、带 per-input 配置的完整 Go 示例以下代码来自 contract 片段文档本身api_extract_batch_bytes_with_config.md它演示把一段 PDF 字节送入批量提取在该输入的config中指定output_format: markdown全局配置保持默认空值最后打印结果信封中的 MIME、内容与元数据中的输出格式。package main import ( encoding/json fmt xberg github.com/xberg-io/xberg/packages/go ) func main() { var inputs []xberg.ExtractInput if err : json.Unmarshal([]byte([{bytes:pdf/fake_memo.pdf,config:{output_format:markdown},filename:fake_memo.pdf,kind:bytes}]), inputs); err ! nil { panic(fmt.Sprintf(config parse failed: %v, err)) } config : xberg.ExtractionConfig{} result, err : xberg.ExtractBatch(inputs, config) if err ! nil { panic(err) } fmt.Printf(%v\n, result.Results[0].MimeType) fmt.Printf(%v\n, result.Results[0].Content) fmt.Printf(%v\n, result.Results[0].Metadata.OutputFormat) }四、逐行拆解这段代码做了什么构造输入切片通过json.Unmarshal把内联 JSON 反序列化为[]xberg.ExtractInput。这里的 JSON 对象含四个键kind:bytes声明这是一段原始字节输入bytes:...实际字节内容片段中为可读性以路径字符串pdf/fake_memo.pdf占位真实合约 fixture 中是一组整数数组见下文第六节filename:fake_memo.pdf文件名提示供 MIME 推断与结果元数据使用config:{output_format:markdown}per-input 配置——仅对这一个输入生效的FileExtractionConfig这里覆盖输出格式为 Markdown。全局配置留空config : xberg.ExtractionConfig{}表示不设置任何全局选项全部使用默认值per-input 的output_format依然独立生效。调用批量提取xberg.ExtractBatch(inputs, config)一次调用处理整批输入。读取结果result.Results[0]是第一个也是唯一一个输入的提取结果MimeType应识别为application/pdfContent为该 PDF 提取出的正文文本Metadata.OutputFormat反映本次生效的输出格式markdown。错误处理上json.Unmarshal失败JSON 解析与ExtractBatch失败调用级错误都通过 panic 暴露便于在 contract 环境中快速暴露问题生产代码建议改为返回 error。五、从 fixture 合约看断言与验收标准同一个场景在合约 fixture 中有机器可读的定义fixtures/contract/api_extract_batch_bytes_with_config.json。它声明了call: extract_batch、标签[contract, api, batch, input_config]并以三条断言约束了正确行为断言类型字段路径期望值含义equalsresults[0].mime_typeapplication/pdf输入被正确识别为 PDFmin_lengthresults[0].content10提取出的文本内容非空且有一定长度equalsresults[0].metadata.output_formatmarkdownper-input config 的output_format确实生效并被记录进元数据第三条断言正是本合约的灵魂它验证了 per-input 配置不仅影响输出内容还会在结果元数据中留下可追踪的痕迹——这对后续按文件核对实际用了什么配置非常有用。fixture 同时以presentation.files指明pdf/fake_memo.pdf对应输入字节说明该测试依赖仓库中真实的 PDF 测试样本。六、底层实现ExtractBatch 的 FFI 调用链ExtractBatch的 Go 实现位于 packages/go/binding.go。从源码看调用过程如下锁定线程runtime.LockOSThread()确保后续 CGO 调用始终在同一 OS 线程上执行defer runtime.UnlockOSThread()在返回时解锁序列化输入json.Marshal(inputs)把[]ExtractInput编码为 Rustserde_json可接受的 JSON构造 C 配置对象json.Marshal(config)后调用C.xberg_extraction_config_from_json把 JSON 转为 FFI 层配置指针失败时通过C.xberg_last_error_context取错误上下文执行提取调用C.xberg_extract_batch(cInputs, cConfig)若lastError()非空则释放指针并返回错误取回结果C.xberg_extraction_result_to_json把 Rust 侧结果转回 JSON再由json.Unmarshal填充ExtractionResult并返回。整个 Go 侧只是编解码壳真正的解析、MIME 识别、格式转换与元数据生成都在 Rust 核心完成这保证了各语言绑定行为一致。6.1 bytes 字段的 JSON 序列化细节源码中ExtractInput自定义了MarshalJSONpackages/go/binding.go把[]byte字段渲染为整数数组[]int而非 Go 默认的 base64 字符串——注释明确指出这是为了匹配 Rust serdeVecu8反序列化器期望的格式。这也解释了为什么合约 fixture 中bytes是一长串形如37, 80, 68, 70, 45, ...的整数37,80,68,70,45正是 ASCII 码%PDF-PDF 文件头。6.2 空输入与空配置的归一化两个边界情况在实现中被显式处理packages/go/binding.gonil 输入切片Go 的 nil 切片json.Marshal后是null而 Rust 侧from_str只接受[]因此代码把null归一化为[]让空批量空结果与空输入语义一致零值配置空ExtractionConfig{}序列化为{}已是合法形式若出现null则替换为{}Rust 侧构造默认实例——所有字段均可选且带默认值这与未设置项使用默认的语义等价。这两处细节解释了为什么示例中config : xberg.ExtractionConfig{}可以直接使用空配置会被安全地构造为默认实例per-input 覆盖照常生效。七、OutputFormat 枚举与元数据中的 output_format示例中output_format的取值来自OutputFormat枚举packages/go/binding.goGo 常量序列化值含义OutputFormatPlainplain纯文本内容默认OutputFormatMarkdownmarkdownMarkdown 格式OutputFormatDjotdjotdjot 标记格式OutputFormatHTMLhtmlHTML 格式OutputFormatJSONjson以标题驱动的 JSON 树结构OutputFormatDocTagsdoctagsDocling DocTags 格式表格渲染为 OTSL在批量提取中全局ExtractionConfig.OutputFormat与 per-inputFileExtractionConfig.OutputFormat是两条独立的设置路径packages/go/binding.go 与 packages/go/binding.goper-input 设置优先覆盖全局。fixture 的第三条断言确认该值最终会出现在results[0].metadata.output_format中便于结果消费方按文件回溯实际输出格式。八、实践建议与验证路径差异化配置的正确姿势把整批统一的设置放进全局ExtractionConfig把仅某文件需要的设置放进该输入的configFileExtractionConfig中留空nil的字段自动回落到全局默认。批量容错ExtractionResult信封携带 per-input 错误单个文件失败不会拖垮整批如需严格超时控制可设置全局ExtractionConfig的默认超时源码注释说明默认 600 秒见 packages/go/binding.go或对个别文件使用FileExtractionConfig.TimeoutSecs覆盖。如何验证自己的调用仓库已提供同场景的 Go e2e 测试作为参照——e2e/go/batch_test.go 中覆盖了Test_ExtractBatchBytesHappy混合输入 happy path、Test_ExtractBatchEmptyInputs空批量返回空结果、Test_ExtractBatchUriAllMissingURI 全部缺失等批量用例更早的契约级验证可运行合约 fixture api_extract_batch_bytes_with_config.json 对应的断言。整个 snippet 目录由 alef 自动生成alef e2e generate合约与语言片段保持同步可作为各绑定行为一致性的权威参照。小结批量字节提取 per-input 配置是 xberg 处理异构文档批量导入时的核心组合拳一次ExtractBatch调用即可混合处理字节与 URI 输入并通过ExtractInput.Config对单个文件做输出格式、OCR、分块等差异化覆盖结果以统一信封返回且错误隔离。理解ExtractInput/FileExtractionConfig/ExtractionResult三者关系并借助 fixture 断言与 e2e 测试验证行为就能在 Go 服务中稳定落地多格式、多策略的文档提取管线。赞分享后端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 Dart 绑定批量字节提取实战使用 extractBatch 与 per-input 配置提取多格式文档xberg Dart 绑定批量字节提取实战使用 extractBatch 与 per input 配置提取多格式文档 导读 xberg 的 Dart 绑定将后端AI 应用NLPXberg C FFI 批量 URI 提取实战extract_batch 与 per-input 配置详解Xberg C FFI 批量 URI 提取实战extract_batch 与 per input 配置详解 本文围绕 Xberg C FFI 契约测试片段 a后端AI 应用NLPxberg Dart 绑定批量 URI 提取实战基于 extract_batch 与 per-input 配置逐文件控制输出格式xberg Dart 绑定批量 URI 提取实战基于 extract_batch 与 per input 配置逐文件控制输出格式 本篇指南讲解如何在 xber后端AI 应用NLP上一篇PDF-to-Podcast核心组件详解PDF处理、AI代理与TTS服务下一篇AnimatedCircleLoadingView深度解析7个核心组件与动画原理创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考