后端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 仓库中的 Kotlin (Android) 端到端示例format_docx_standalone为骨架讲解如何在 Android/Kotlin 环境中通过Xberg.extract一步完成独立 DOCX 文档的文本抽取。你将掌握ExtractInput、ExtractionConfig两个核心数据类的 JSON 反序列化方式、uri输入模式与 MIME 类型声明、默认配置下的安全默认值以及如何从ExtractionResult中读取抽取文本并理解这条调用链背后由 Rust 核心驱动的实现原理。一、示例全景一条 20 行的 Kotlin 抽取主流程仓库中的示例位于 docs-site/src/snippets-generated/kotlin-android/format_specific/format_docx_standalone.md完整代码仅 20 余行却覆盖了 Xberg Kotlin 绑定的标准用法import io.xberg.* import com.fasterxml.jackson.module.kotlin.jacksonObjectMapper fun main() kotlinx.coroutines.runBlocking { val mapper jacksonObjectMapper().setPropertyNamingStrategy(com.fasterxml.jackson.databind.PropertyNamingStrategies.SNAKE_CASE) val input mapper.readValue({\filename\:\fake.docx\,\kind\:\uri\,\mime_type\:\application/vnd.openxmlformats-officedocument.wordprocessingml.document\,\uri\:\https://example.com/docx/fake.docx\}, ExtractInput::class.java) val configDefault mapper.readValue({\url\:{\crawl\:{\ssrf\:{}}}}, ExtractionConfig::class.java) val result Xberg.extract(input, configDefault) println(result.results.first().content) }这段代码依次完成四件事构造 JacksonObjectMapper并启用SNAKE_CASE属性命名策略mime_type、extract_input这类下划线命名才能正确映射到 Kotlin 字段将描述文档来源的 JSON 反序列化为ExtractInput将抽取配置 JSON 反序列化为ExtractionConfig调用Xberg.extract(input, configDefault)执行抽取并从result.results.first().content取出第一个结果的纯文本内容。1.1 为什么输出results.first().contentXberg.extract的返回类型是ExtractionResult其定义见 ExtractionResult.kt包含三个字段results: ListExtractedDocument—— 按发现顺序排列的抽取文档列表errors: ListExtractionErrorItem—— 非致命性的逐输入错误以及聚合计数等元数据字段。其中ExtractedDocument见 ExtractedDocument.kt的核心字段content: String就是该文档的纯文本表示对应 Rust 侧ExtractedDocument.content的统一格式输出。由于单次extract只处理一个输入results列表通常只有一个元素因此示例直接取results.first().content打印。二、ExtractInput统一抽取入口的输入形状ExtractInput是 Xberg 所有公开抽取入口单次、批量、URI 抓取共用的输入结构定义在 ExtractInput.kt字段类型说明kindExtractInputKind输入来源类型默认URIbytes需要bytes字段uri需要uri字段bytesByteArray?kind bytes时的原始字节uriString?kind uri时使用的本地路径、file://URI 或 HTTP(S) URLmime_typeString?MIME 类型提示filenameString?用于 MIME 检测与元数据的文件名提示configFileExtractionConfig?逐输入per-input的抽取覆盖配置2.1uri模式与 MIME 声明示例采用kind: uri并同时给出三个关键提示{ filename: fake.docx, kind: uri, mime_type: application/vnd.openxmlformats-officedocument.wordprocessingml.document, uri: https://example.com/docx/fake.docx }uri指向一个 HTTP(S) URL抽取管线会先抓取该地址的内容mime_type显式声明 OOXML Word 文档的标准 MIME 类型application/vnd.openxmlformats-officedocument.wordprocessingml.document避免依赖内容嗅探filename作为兜底提示同时写入结果的元数据。从源码看该示例对应的端到端夹具 fixtures/format_specific/format_docx_standalone.json 中mock server 返回的content-type与这里的mime_type完全一致并指向../test_documents/docx/fake.docx作为响应体——也就是说真实测试里这个 URL 指向一个由 mock server 提供的 DOCX 文件而应用场景中你可以替换为任意可访问的 DOCX 地址。2.2 三种输入形态对比kind字段决定抽取的数据来源路径uri从远程 URL 或本地文件路径取数本文示例即此模式bytes直接在bytes字段中携带原始文件内容适合已读入内存的数据如从ContentResolver读取的 Android 文件流本地路径/file://URI 也是uri的合法取值可按需组合。在实际 Android 应用中如果文档来自Intent或Uri可以先读取为ByteArray再走bytes模式若文档本身托管在服务器上则直接使用uri模式省去客户端下载环节。三、ExtractionConfig最小可用的安全默认配置示例中的配置是整段代码里最“短小”却信息量最大的一行{url: {crawl: {ssrf: {}}}}这行 JSON 反序列化为ExtractionConfig后只显式设置了 URL 抓取行为其余全部走默认值。ExtractionConfig定义在 ExtractionConfig.kt是整条抽取管线的“总开关”其中与本文场景直接相关的默认值包括配置字段默认值对 DOCX 抽取的影响mime_detection_policyPREFER_CONTENTMIME 推断优先采用内容嗅探mime_type提示作为辅助use_cachetrue抽取结果默认启用缓存重复抽取同一 URI 可命中缓存enable_quality_processingtrue启用质量后处理文本质量门控等ocrnull不主动为已有可读文本的文档运行 OCRoutput_formatPlain输出为纯文本content字段即为最终文本extraction_timeout_secs600单文件抽取默认超时 10 分钟防止病态文件耗尽资源url必填URL 抓取与爬取配置本文显式给出3.1url.crawl.ssrf的意义ExtractionConfig中的url: UrlExtractionConfig是必填字段定义见 UrlExtractionConfig.kt包含modeURL 抽取模式默认AUTOcrawl: CrawlConfigHTTP(S) URL 抽取使用的抓取配置document_url_pattern可选的文档发现 URL 正则过滤。示例显式声明url.crawl.ssrf即开启抓取环节的 SSRF服务端请求伪造防护——当客户端向不可信服务器发起 HTTP 抓取时该配置会约束目标地址如拦截私网地址是面向公网部署的安全默认项。同时CrawlConfig中还可以扩展BrowserConfig浏览器渲染模式、等待策略等来应对需要 JavaScript 渲染的页面。关键点即使只写{url:{crawl:{ssrf:{}}}}这一行整个 DOCX 抽取链路所需的全部默认配置都会被补齐——这正是该示例名为“standalone”独立/最小化的原因。四、深入调用链Kotlin 门面 → JNI → Rust 核心Xberg.extract并不是在 Kotlin 侧实现的抽取逻辑而是一层薄门面。查看 Xberg.ktfun extract(input: ExtractInput, config: ExtractionConfig): ExtractionResult { val resultJson XbergBridge.nativeExtract(mapper.writeValueAsString(input), mapper.writeValueAsString(config)) return mapper.readValue(resultJson, ExtractionResult::class.java) }其完整调用链为JSON 序列化Xberg对象内置的 JacksonObjectMapper将ExtractInput、ExtractionConfig序列化为 JSON。注意这里注册了byteArrayModule——ByteArray被编码为无符号字节数组而非 Base64 字符串以匹配 Rust 侧 serde 对Vecu8的编码约定见 Xberg.ktJNI 调用XbergBridge.nativeExtract将 JSON 传入 JNI 桥接层最终落到 Rust 核心的抽取实现结果回传Rust 返回 JSON 字符串Kotlin 侧反序列化为ExtractionResult。在 JNI 侧Kotlin 绑定还处理了kotlin.time.Duration与毫秒整数的双向转换以及FAIL_ON_UNKNOWN_PROPERTIES false的宽松反序列化策略——即使 Rust 侧未来新增字段老版本 Kotlin 客户端也不会因此报错。4.1 DOCX 抽取在 Rust 核心中的位置DOCX 抽取由 Rust 核心中的DocxExtractor承担。在 extractors/mod.rs 中可以确认#[cfg(feature office)] pub mod docx; // ... #[cfg(feature office)] pub use docx::DocxExtractor;即 DOCX 抽取器在officefeature 下编译并导出属于 OOXML 容器文档DOCX、PPTX、XLSX 等家族。从抽取结果测试tests_extraction_result.rs可以看到DOCX 文档会被解析为包含Heading、Paragraph、ListStart/ListItem等语义元素的内部文档模型再按所选output_format渲染——这解释了为什么content在Plain模式下是纯文本、在Markdown模式下则会带标题层级与列表标记。五、端到端测试佐证mock server 驱动的真实断言示例不是孤立文档它有完整的端到端测试支撑。仓库中的 FormatSpecificTest.kt 内testFormatDocxStandalone测试执行了同一流程Test fun testFormatDocxStandalone(): Unit runBlocking { val inputMockBaseUrl System.getProperty(mockServer.format_docx_standalone, ...) val inputJson {\filename\:\fake.docx\,\kind\:\uri\,\mime_type\:\application/vnd.openxmlformats-officedocument.wordprocessingml.document\,\uri\:\\$mock_url/docx/fake.docx\}.replace(\$mock_url, inputMockBaseUrl) val input MAPPER.readValue(inputJson, ExtractInput::class.java) val configDefault MAPPER.readValue({\url\:{\crawl\:{\ssrf\:{}}}}, ExtractionConfig::class.java) val result Xberg.extract(input, configDefault) assertTrue(result.results.first().content.length 20, expected length 20) }测试与示例的差异仅在于URI 指向本地 mock server$mock_url/docx/fake.docx且断言抽取文本长度不小于 20 字符。而夹具 fixtures/format_specific/format_docx_standalone.json 记录了完整契约call为extractassertions包含not_error调用无错误与min_lengthresults[0].content至少 20 字符。这套“夹具 JSON → 各语言 E2E 测试 → snippets 文档”由 alef 工具链自动生成与校验文档头部alef:hash即指纹因此你在文档中看到的代码就是仓库 CI 中真实执行并通过的代码——可直接照搬到自己的工程。六、实战把示例改造成 Android 应用代码将示例迁移到真实 Android 工程时需要做三处适配6.1 引入依赖在build.gradle.kts中引入 Xberg Kotlin/Android 绑定与 Jackson Kotlin 模块implementation(io.xberg:xberg-android:VERSION) implementation(com.fasterxml.jackson.module:jackson-module-kotlin:VERSION) implementation(org.jetbrains.kotlinx:kotlinx-coroutines-android:VERSION)具体版本以你使用的 Xberg 发布版本为准仓库 packages/kotlin-android 的构建配置中可查到当前依赖组合。6.2 加载原生库E2E 测试在套件初始化时执行了System.loadLibrary(xberg_jni)见 FormatSpecificTest.kt 的companion object并设置了CRAWLBERG_ALLOW_PRIVATE_NETWORKtrue、RUST_MIN_STACK等运行时属性。Android 应用中应在Application或首次调用前完成相同的原生库加载与初始化并确保 JNI 库已随 AAR 打包。6.3 在协程中调用示例用runBlocking便于在 main 函数演示Android 中应改用生命周期安全的协程作用域如viewModelScope因为Xberg.extract是阻塞调用建议放到Dispatchers.Default等后台调度器suspend fun extractDocx(uri: String) withContext(Dispatchers.Default) { val mapper jacksonObjectMapper() .setPropertyNamingStrategy(PropertyNamingStrategies.SNAKE_CASE) val input mapper.readValue( {filename:fake.docx,kind:uri,mime_type:application/vnd.openxmlformats-officedocument.wordprocessingml.document,uri:$uri}, ExtractInput::class.java ) val config mapper.readValue( {url:{crawl:{ssrf:{}}}}, ExtractionConfig::class.java ) Xberg.extract(input, config).results.first().content }七、常见问题与排查方向文本为空或长度异常检查output_format默认值Plain是否符合预期若希望得到带结构的 Markdown 输出可在ExtractionConfig中设置output_format: markdown参考仓库中 format_docx_equations 夹具 的用法。results.first()抛 NoSuchElement说明抽取失败返回空列表应先检查result.errors中的ExtractionErrorItem。URI 抓取失败或超时确认url.crawl.ssrf配置未被移除公网环境开启可防 SSRF并检查extraction_timeout_secs默认 600 秒是否被显式覆盖。MIME 判定不准DOCX 的 MIME 提示务必写全application/vnd.openxmlformats-officedocument.wordprocessingml.documentfilename后缀.docx也会参与推断二者保持一致可避免走错抽取分支。八、小结从这条 20 行的 Kotlin 示例出发你可以看到 Xberg 在 Android 侧的完整用法范式以ExtractInput声明文档来源、以ExtractionConfig控制抽取行为、以Xberg.extract一行触发、以ExtractionResult.results[].content取回文本。其背后是 Rust 核心的DocxExtractor与 JNI 桥接的成熟管道而文档本身由 alef 工具链从真实 E2E 测试自动生成保证了示例代码的可运行性与准确性。将同样的ExtractInput/ExtractionConfig组合稍作修改切换kind、调整output_format、追加images/chunking等配置块即可覆盖 DOCX 之外的大量文档格式与更复杂的抽取需求。赞分享后端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 Elixir 绑定实战用 extract API 完成 DOCX 文档独立提取Xberg Elixir 绑定实战用 extract API 完成 DOCX 文档独立提取 本篇指南围绕 Xberg 项目 Elixir 绑定中的 forma后端AI 应用NLPXberg Java 绑定实战用 extract 完成 HWPX 文档的独立文本抽取Xberg Java 绑定实战用 extract 完成 HWPX 文档的独立文本抽取 导读 本文围绕 Xberg 提供的 HWPXHangul Word P后端AI 应用NLPXberg Dart 绑定独立 DOCX 提取实战用 XbergBridge.extract 从 Word 文档抽取全文内容Xberg Dart 绑定独立 DOCX 提取实战用 XbergBridge.extract 从 Word 文档抽取全文内容 导读 本文聚焦 xberg 项目后端AI 应用NLP上一篇Quasar QLinearProgress 组件完全指南determinate / indeterminate / query 与缓冲进度条实战下一篇使用 Docker 与 Docker Compose 部署 Flink 集群Session 模式、Application 模式与镜像定制全指南创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考