后端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点击查看免费下载本文是一份面向 .NET / C# 开发者的实操指南围绕 xberg 提供的XbergConverter.ExtractAsync接口讲解如何在 C# 中独立standalone提取 DOCX 文档的文本内容。文中给出的示例来自仓库的端到端测试夹具fixtureformat_docx_standalone并会结合 C# 绑定源码、测试用例与配套夹具文件说明ExtractInput/ExtractionConfig的关键字段、MIME 判定逻辑与可复现的运行方式。读完本文你将能在自己的 .NET 项目中直接调用 xberg 完成 DOCX乃至其他 106 种格式的文本抽取。一、场景与背景为什么需要独立 DOCX 提取xberg 是一个以 Rust 为核心的 Polyglot 文档智能库可提取文本、元数据、图片、表格及结构化数据支持 106 种格式、140 种文件扩展名并提供 15 种语言绑定。对于 C# 开发者而言最常见的接入方式是通过packages/csharp下的官方绑定调用其 FFI 桥接层。所谓独立提取standalone extraction指的是不依赖额外预处理步骤、直接针对单个文档发起一次extract调用并拿到结果的过程。仓库中用专门的身份标识符fixture idformat_docx_standalone记录了这一场景其描述为 Standalone DOCX extraction using extract见 fixtures/format_specific/format_docx_standalone.json。该夹具属于format_specific类别标签为[format_specific, docx, text_extraction]说明它正是格式相关 DOCX 文本提取的组合验证。与批处理extract_batch_*系列夹具不同独立提取只处理单个输入适合在业务代码中按需调用比如上传一个 Word 文档后立即抽取其正文。二、最小可运行示例核心代码逐行解读关联文档docs-site/src/snippets-generated/csharp/format_specific/format_docx_standalone.md给出了如下 C# 代码这是整个场景的最小骨架using System; using System.Text.Json; using Xberg; var ConfigOptions new JsonSerializerOptions { PropertyNameCaseInsensitive true }; var result await XbergConverter.ExtractAsync(new ExtractInput { Filename fake.docx, Kind JsonSerializer.DeserializeExtractInputKind(\uri\, ConfigOptions)!, MimeType application/vnd.openxmlformats-officedocument.wordprocessingml.document, Uri https://example.com/docx/fake.docx }, new ExtractionConfig()); Console.WriteLine(result.Results[0].Content);逐行拆解其含义var ConfigOptions new JsonSerializerOptions { PropertyNameCaseInsensitive true };声明一个大小写不敏感的 JSON 反序列化选项。示例中用它将字符串uri解析为枚举ExtractInputKind。实际上 C# 绑定内部已经内置了JsonStringEnumConverter(JsonNamingPolicy.SnakeCaseLower)见 ExtractInput.cs因此你也可以直接写ExtractInputKind.Uri更直观。Kind ...声明输入来源类型。取值见ExtractInputKind枚举当前示例为uri即从 URL/本地路径读取文档。MimeType application/vnd.openxmlformats-officedocument.wordprocessingml.document这是 DOCX 的标准 MIME 类型用于告诉提取引擎这是一个 Word 文档。Filename fake.docx文件名提示参与 MIME 探测与结果元数据。Uri https://example.com/docx/fake.docx实际文档来源。new ExtractionConfig()使用默认提取配置不指定输出格式、OCR 等额外参数。result.Results[0].Content取出第一个提取结果的内容即 DOCX 正文文本。这份示例与仓库内自动生成的端到端测试 FormatSpecificTests.cs 中的Test_FormatDocxStandalone几乎一一对应区别仅在于测试通过ExtractInput.FromJson(...)从 JSON 字符串构造输入并断言result.Results[0].Content.Length 20正文长度至少 20 个字符。三、ExtractInput输入描述模型的字段语义ExtractInput在 packages/csharp/src/Xberg/ExtractInput.cs 中定义为public sealed record注释明确说明它是所有公开提取入口的统一输入模型Unified extraction input for all public extraction entry points。各字段及约束如下字段JSON 属性名类型语义与约束KindkindExtractInputKind来源类型bytes需要配合Bytesuri需要配合UriBytesbytesbyte[]?kind bytes时的原始字节Uriuristring?kind uri时的本地路径、file://URI 或 HTTP(S) URLMimeTypemime_typestring?MIME 类型提示Filenamefilenamestring?文件名提示用于 MIME 探测与元数据ConfigconfigFileExtractionConfig?单输入级提取覆盖参数从源码可以看到几个值得注意的实现细节Kind默认值为ExtractInputKind.UriExtractInput.cs即不指定时按 URI 输入处理。ExtractInput.FromJson(string)提供从 JSON 字符串构建输入的能力ExtractInput.cs解析失败时抛出XbergException并附带底层异常信息。另有便捷工厂方法FromBytes(byte[] bytes, string mimeType, string? filename)与FromUri(string uri)ExtractInput.cs它们先通过 P/Invoke 调用原生层NativeMethods.ExtractInputFromBytes/ExtractInputFromUri再把原生层序列化的 JSON 反序列化回托管对象这正是 C# 绑定桥接 Rust 核心的典型路径。序列化策略上绑定使用DefaultIgnoreCondition JsonIgnoreCondition.WhenWritingNullExtractInput.csnullable 的 C# 字段默认值为null若直接序列化会把 Rust 侧必填字段覆盖为非法 null因此序列化时剔除 null 而保留显式的false/0保证调用意图不被丢失。四、MIME 类型与 DOCX 的识别逻辑示例中显式传入MimeType application/vnd.openxmlformats-officedocument.wordprocessingml.document这是 OOXML 的 WordprocessingML 文档即.docx的标准 MIME 类型。在 xberg 的输入模型中MIME 类型是提示hint与Filename一起参与最终格式判定。ExtractionConfig中有一个专门控制该过程的参数MimeDetectionPolicyExtractionConfig.cs其注释说明它控制 MIME 推断是偏好内容、受支持的扩展名还是仅依据内容。默认值为PreferContent即优先根据文档内容本身判断格式其次再参考文件扩展名。这也解释了为什么夹具测试中即使文档来源是模拟服务器返回的字节流只要content-type与 MIME 提示一致提取就能正确路由到 DOCX 解析器。在 fixtures/format_specific/format_docx_standalone.json 中可以看到完整的输入约定extract_input: { kind: uri, uri: $mock_url/docx/fake.docx, mime_type: application/vnd.openxmlformats-officedocument.wordprocessingml.document, filename: fake.docx }其中$mock_url是端到端测试框架注入的模拟服务器地址mock_responses段则声明了服务器对/docx/fake.docx返回 200 状态码、content-type为上述 DOCX MIME正文取自 e2e/csharp/../test_documents/docx/fake.docx 中的真实样本fixture 中引用为../test_documents/docx/fake.docx对应仓库 e2e/csharp/docx 目录下的样本文件。五、ExtractionConfig默认配置能做什么、还能扩展什么示例使用new ExtractionConfig()即默认配置完成提取。该类型定义在 packages/csharp/src/Xberg/ExtractionConfig.cs是一个约 629 行的public sealed record注释说明其包含提取过程的全部配置项可以从 TOML / YAML / JSON 文件加载也可以编程式创建。与 DOCX 文本提取最相关、也最常用的默认值如下配置项JSON 属性名默认值说明MimeDetectionPolicymime_detection_policyPreferContentMIME 推断策略UseCacheuse_cachetrue是否缓存提取结果EnableQualityProcessingenable_quality_processingtrue是否启用质量后处理ForceOcrforce_ocrfalse是否强制对可搜索 PDF 也做 OCROcrocrnullOCR 配置后端与语言选择ForceOcrPagesforce_ocr_pagesnull仅对指定页码强制 OCR1 起始仅 PDF需要说明的几点UseCache与EnableQualityProcessing默认开启因此无需额外配置即可获得缓存与质量后处理带来的收益如果你的场景对实时性更敏感或不需要后处理可以显式关闭。ForceOcr、ForceOcrPages等 OCR 参数仅对 PDF 文档生效对 DOCX 这类本身带文本层的 OOXML 文档不适用——这也是独立 DOCX 提取默认配置即可完成的原因DOCX 正文直接来自word/document.xml的文本节点无需 OCR。若要指定输出格式如 Markdown可在ExtractionConfig中设置output_format。同属format_specific类别的另一个夹具format_docx_equations见 fixtures/format_specific/format_docx_equations.json即通过output_format: markdown把 DOCX 内嵌公式转换为 LaTeX 数学表达式测试断言结果中包含$字符见 FormatSpecificTests.cs。这说明同一份ExtractAsync调用只需调整配置即可从纯文本切换到Markdown含公式输出。六、ExtractAsync 的底层调用链ExtractAsync定义在 XbergConverter.cs 附近签名如下public static async TaskExtractionResult ExtractAsync(ExtractInput input, ExtractionConfig config)其执行流程体现了托管 C# → 原生 FFI → Rust 核心的三层架构参数校验与序列化对input/config做ArgumentNullException.ThrowIfNull校验随后用JsonSerializationOptions剔除 null、枚举蛇形命名序列化为 JSON 字符串构造原生句柄通过 P/Invoke 调用NativeMethods.ExtractInputFromJson(...)与NativeMethods.ExtractionConfigFromJson(...)把 JSON 传入 Rust 侧生成不透明句柄handle异步执行在Task.Run中调用NativeMethods.Extract(...)完成后检查NativeMethods.LastErrorCode()非零则抛GetLastError()结果回传调用NativeMethods.ExtractionResultToJson(...)获取 JSONMarshal.PtrToStringUTF8转字符串后反序列化为ExtractionResult并在finally中释放所有原生句柄。值得注意的还有每次调用都走Task.Run把可能阻塞的 FFI 调用移出线程池的调用线程避免阻塞 UI / Web 请求线程错误统一收敛为XbergExceptionLastErrorCode() ! 0时抛出调用方可用try/catch捕获解析与提取阶段的失败见 ExtractTests.cs 中通过Assert.ThrowsAnyAsyncXbergException验证空 MIME 与不支持 MIME 的场景ExtractionResult是结果容器Results[0].Content即第一个文档的正文Result同时携带MimeType等元数据如 ExtractTests.cs 中Assert.Equal(application/pdf, result.Results[0].MimeType)所示。七、运行与验证如何在本地复现该场景仓库的端到端测试框架由 alef 自动生成文件头注明 This file is auto-generated by alef — DO NOT EDIT.通过alef e2e generate重新生成、alef verify校验新鲜度。要复现独立 DOCX 提取有两种途径方式一直接运行端到端测试Test_FormatDocxStandalone位于 e2e/csharp/tests/FormatSpecificTests.cs测试通过环境变量注入模拟服务器地址var Input_MockBaseUrl Environment.GetEnvironmentVariable(MOCK_SERVER_FORMAT_DOCX_STANDALONE) ?? Environment.GetEnvironmentVariable(MOCK_SERVER_URL) /fixtures/format_docx_standalone;即优先使用专用变量MOCK_SERVER_FORMAT_DOCX_STANDALONE否则回退到通用MOCK_SERVER_URL并拼接 fixture 路径。运行脚本可参考 scripts/e2e/run-with-mock-server.sh它负责拉起 mock server 再执行各语言绑定测试。方式二在自有项目中调用绑定将 packages/csharp/Xberg 中的绑定源码与原生库Rust 核心编译产物纳入你的 .NET 项目或参考 packages/csharp/Xberg/Xberg.csproj 的工程组织方式像示例代码一样构造ExtractInput与ExtractionConfig调用await XbergConverter.ExtractAsync(...)注意确保运行环境具备对应的原生动态库不同平台的 native 产物否则 FFI 层无法加载。八、边界与注意点输入来源kind uri支持本地路径、file://与 HTTP(S) URL若文档以字节形式存在内存中改用kind bytes并配合FromBytes工厂方法。MIME 与扩展名虽然默认策略PreferContent会优先看内容但显式提供正确的 MIMEDOCX 为application/vnd.openxmlformats-officedocument.wordprocessingml.document能减少探测开销、避免误判尤其是远程 URL 场景。OCR 无关DOCX 属文本型格式OCR 相关配置对其无效OCR 参数只影响 PDF / 图片类文档。结果结构ExtractionResult.Results是集合类型即使单输入也以数组形式返回取Results[0]时需确认索引存在正文长度断言 20是测试对提取成功且非空的通用约定可作为你自己校验结果质量的参考。九、小结通过XbergConverter.ExtractAsyncC# 开发者可以用十几行代码完成 DOCX 的独立文本提取ExtractInput描述文档在哪、是什么格式ExtractionConfig控制如何提取ExtractionResult承载提取到什么。本文基于 docs-site/src/snippets-generated/csharp/format_specific/format_docx_standalone.md 的示例结合 ExtractInput.cs、ExtractionConfig.cs、XbergConverter.cs 的源码实现以及 FormatSpecificTests.cs 的测试用例把最小示例 → 字段语义 → MIME 判定 → 配置扩展 → 底层调用链 → 本地复现串成了一条完整的实践链路。需要处理 PDF、HWPX、PPTX、XLSX 等其他格式时替换MimeType与输入来源即可复用同一套调用模式。赞分享后端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 提取独立 DOCX 文档xberg_extract 与 ExtractInput 实战解析Xberg C FFI 提取独立 DOCX 文档xberg_extract 与 ExtractInput 实战解析 本篇技术指南围绕 Xberg 开源仓库中的后端AI 应用NLPXberg C FFI 实战使用 extract API 对 HWPX 韩文办公文档进行独立文本提取Xberg C FFI 实战使用 extract API 对 HWPX 韩文办公文档进行独立文本提取 本篇技术指南围绕 XbergRust 核心的 Poly后端AI 应用NLPxberg C FFI 实战DOCX 文档提取的冒烟测试全解析xberg C FFI 实战DOCX 文档提取的冒烟测试全解析 本文围绕 xberg 仓库中一条自动生成的 C 语言冒烟测试样例展开它演示了如何通过 C F后端AI 应用NLP上一篇Rust By Practice 所有权与借用专题用 4 级挑战彻底攻克 Rust 最难的一关下一篇如何选择最佳日语语音模型japanese-hubert-base与主流方案的终极对比创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 xberg C 绑定实战：使用 ExtractAsync 独立提取 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点击查看免费下载本文是一份面向 .NET / C# 开发者的实操指南围绕 xberg 提供的XbergConverter.ExtractAsync接口讲解如何在 C# 中独立standalone提取 DOCX 文档的文本内容。文中给出的示例来自仓库的端到端测试夹具fixtureformat_docx_standalone并会结合 C# 绑定源码、测试用例与配套夹具文件说明ExtractInput/ExtractionConfig的关键字段、MIME 判定逻辑与可复现的运行方式。读完本文你将能在自己的 .NET 项目中直接调用 xberg 完成 DOCX乃至其他 106 种格式的文本抽取。一、场景与背景为什么需要独立 DOCX 提取xberg 是一个以 Rust 为核心的 Polyglot 文档智能库可提取文本、元数据、图片、表格及结构化数据支持 106 种格式、140 种文件扩展名并提供 15 种语言绑定。对于 C# 开发者而言最常见的接入方式是通过packages/csharp下的官方绑定调用其 FFI 桥接层。所谓独立提取standalone extraction指的是不依赖额外预处理步骤、直接针对单个文档发起一次extract调用并拿到结果的过程。仓库中用专门的身份标识符fixture idformat_docx_standalone记录了这一场景其描述为 Standalone DOCX extraction using extract见 fixtures/format_specific/format_docx_standalone.json。该夹具属于format_specific类别标签为[format_specific, docx, text_extraction]说明它正是格式相关 DOCX 文本提取的组合验证。与批处理extract_batch_*系列夹具不同独立提取只处理单个输入适合在业务代码中按需调用比如上传一个 Word 文档后立即抽取其正文。二、最小可运行示例核心代码逐行解读关联文档docs-site/src/snippets-generated/csharp/format_specific/format_docx_standalone.md给出了如下 C# 代码这是整个场景的最小骨架using System; using System.Text.Json; using Xberg; var ConfigOptions new JsonSerializerOptions { PropertyNameCaseInsensitive true }; var result await XbergConverter.ExtractAsync(new ExtractInput { Filename fake.docx, Kind JsonSerializer.DeserializeExtractInputKind(\uri\, ConfigOptions)!, MimeType application/vnd.openxmlformats-officedocument.wordprocessingml.document, Uri https://example.com/docx/fake.docx }, new ExtractionConfig()); Console.WriteLine(result.Results[0].Content);逐行拆解其含义var ConfigOptions new JsonSerializerOptions { PropertyNameCaseInsensitive true };声明一个大小写不敏感的 JSON 反序列化选项。示例中用它将字符串uri解析为枚举ExtractInputKind。实际上 C# 绑定内部已经内置了JsonStringEnumConverter(JsonNamingPolicy.SnakeCaseLower)见 ExtractInput.cs因此你也可以直接写ExtractInputKind.Uri更直观。Kind ...声明输入来源类型。取值见ExtractInputKind枚举当前示例为uri即从 URL/本地路径读取文档。MimeType application/vnd.openxmlformats-officedocument.wordprocessingml.document这是 DOCX 的标准 MIME 类型用于告诉提取引擎这是一个 Word 文档。Filename fake.docx文件名提示参与 MIME 探测与结果元数据。Uri https://example.com/docx/fake.docx实际文档来源。new ExtractionConfig()使用默认提取配置不指定输出格式、OCR 等额外参数。result.Results[0].Content取出第一个提取结果的内容即 DOCX 正文文本。这份示例与仓库内自动生成的端到端测试 FormatSpecificTests.cs 中的Test_FormatDocxStandalone几乎一一对应区别仅在于测试通过ExtractInput.FromJson(...)从 JSON 字符串构造输入并断言result.Results[0].Content.Length 20正文长度至少 20 个字符。三、ExtractInput输入描述模型的字段语义ExtractInput在 packages/csharp/src/Xberg/ExtractInput.cs 中定义为public sealed record注释明确说明它是所有公开提取入口的统一输入模型Unified extraction input for all public extraction entry points。各字段及约束如下字段JSON 属性名类型语义与约束KindkindExtractInputKind来源类型bytes需要配合Bytesuri需要配合UriBytesbytesbyte[]?kind bytes时的原始字节Uriuristring?kind uri时的本地路径、file://URI 或 HTTP(S) URLMimeTypemime_typestring?MIME 类型提示Filenamefilenamestring?文件名提示用于 MIME 探测与元数据ConfigconfigFileExtractionConfig?单输入级提取覆盖参数从源码可以看到几个值得注意的实现细节Kind默认值为ExtractInputKind.UriExtractInput.cs即不指定时按 URI 输入处理。ExtractInput.FromJson(string)提供从 JSON 字符串构建输入的能力ExtractInput.cs解析失败时抛出XbergException并附带底层异常信息。另有便捷工厂方法FromBytes(byte[] bytes, string mimeType, string? filename)与FromUri(string uri)ExtractInput.cs它们先通过 P/Invoke 调用原生层NativeMethods.ExtractInputFromBytes/ExtractInputFromUri再把原生层序列化的 JSON 反序列化回托管对象这正是 C# 绑定桥接 Rust 核心的典型路径。序列化策略上绑定使用DefaultIgnoreCondition JsonIgnoreCondition.WhenWritingNullExtractInput.csnullable 的 C# 字段默认值为null若直接序列化会把 Rust 侧必填字段覆盖为非法 null因此序列化时剔除 null 而保留显式的false/0保证调用意图不被丢失。四、MIME 类型与 DOCX 的识别逻辑示例中显式传入MimeType application/vnd.openxmlformats-officedocument.wordprocessingml.document这是 OOXML 的 WordprocessingML 文档即.docx的标准 MIME 类型。在 xberg 的输入模型中MIME 类型是提示hint与Filename一起参与最终格式判定。ExtractionConfig中有一个专门控制该过程的参数MimeDetectionPolicyExtractionConfig.cs其注释说明它控制 MIME 推断是偏好内容、受支持的扩展名还是仅依据内容。默认值为PreferContent即优先根据文档内容本身判断格式其次再参考文件扩展名。这也解释了为什么夹具测试中即使文档来源是模拟服务器返回的字节流只要content-type与 MIME 提示一致提取就能正确路由到 DOCX 解析器。在 fixtures/format_specific/format_docx_standalone.json 中可以看到完整的输入约定extract_input: { kind: uri, uri: $mock_url/docx/fake.docx, mime_type: application/vnd.openxmlformats-officedocument.wordprocessingml.document, filename: fake.docx }其中$mock_url是端到端测试框架注入的模拟服务器地址mock_responses段则声明了服务器对/docx/fake.docx返回 200 状态码、content-type为上述 DOCX MIME正文取自 e2e/csharp/../test_documents/docx/fake.docx 中的真实样本fixture 中引用为../test_documents/docx/fake.docx对应仓库 e2e/csharp/docx 目录下的样本文件。五、ExtractionConfig默认配置能做什么、还能扩展什么示例使用new ExtractionConfig()即默认配置完成提取。该类型定义在 packages/csharp/src/Xberg/ExtractionConfig.cs是一个约 629 行的public sealed record注释说明其包含提取过程的全部配置项可以从 TOML / YAML / JSON 文件加载也可以编程式创建。与 DOCX 文本提取最相关、也最常用的默认值如下配置项JSON 属性名默认值说明MimeDetectionPolicymime_detection_policyPreferContentMIME 推断策略UseCacheuse_cachetrue是否缓存提取结果EnableQualityProcessingenable_quality_processingtrue是否启用质量后处理ForceOcrforce_ocrfalse是否强制对可搜索 PDF 也做 OCROcrocrnullOCR 配置后端与语言选择ForceOcrPagesforce_ocr_pagesnull仅对指定页码强制 OCR1 起始仅 PDF需要说明的几点UseCache与EnableQualityProcessing默认开启因此无需额外配置即可获得缓存与质量后处理带来的收益如果你的场景对实时性更敏感或不需要后处理可以显式关闭。ForceOcr、ForceOcrPages等 OCR 参数仅对 PDF 文档生效对 DOCX 这类本身带文本层的 OOXML 文档不适用——这也是独立 DOCX 提取默认配置即可完成的原因DOCX 正文直接来自word/document.xml的文本节点无需 OCR。若要指定输出格式如 Markdown可在ExtractionConfig中设置output_format。同属format_specific类别的另一个夹具format_docx_equations见 fixtures/format_specific/format_docx_equations.json即通过output_format: markdown把 DOCX 内嵌公式转换为 LaTeX 数学表达式测试断言结果中包含$字符见 FormatSpecificTests.cs。这说明同一份ExtractAsync调用只需调整配置即可从纯文本切换到Markdown含公式输出。六、ExtractAsync 的底层调用链ExtractAsync定义在 XbergConverter.cs 附近签名如下public static async TaskExtractionResult ExtractAsync(ExtractInput input, ExtractionConfig config)其执行流程体现了托管 C# → 原生 FFI → Rust 核心的三层架构参数校验与序列化对input/config做ArgumentNullException.ThrowIfNull校验随后用JsonSerializationOptions剔除 null、枚举蛇形命名序列化为 JSON 字符串构造原生句柄通过 P/Invoke 调用NativeMethods.ExtractInputFromJson(...)与NativeMethods.ExtractionConfigFromJson(...)把 JSON 传入 Rust 侧生成不透明句柄handle异步执行在Task.Run中调用NativeMethods.Extract(...)完成后检查NativeMethods.LastErrorCode()非零则抛GetLastError()结果回传调用NativeMethods.ExtractionResultToJson(...)获取 JSONMarshal.PtrToStringUTF8转字符串后反序列化为ExtractionResult并在finally中释放所有原生句柄。值得注意的还有每次调用都走Task.Run把可能阻塞的 FFI 调用移出线程池的调用线程避免阻塞 UI / Web 请求线程错误统一收敛为XbergExceptionLastErrorCode() ! 0时抛出调用方可用try/catch捕获解析与提取阶段的失败见 ExtractTests.cs 中通过Assert.ThrowsAnyAsyncXbergException验证空 MIME 与不支持 MIME 的场景ExtractionResult是结果容器Results[0].Content即第一个文档的正文Result同时携带MimeType等元数据如 ExtractTests.cs 中Assert.Equal(application/pdf, result.Results[0].MimeType)所示。七、运行与验证如何在本地复现该场景仓库的端到端测试框架由 alef 自动生成文件头注明 This file is auto-generated by alef — DO NOT EDIT.通过alef e2e generate重新生成、alef verify校验新鲜度。要复现独立 DOCX 提取有两种途径方式一直接运行端到端测试Test_FormatDocxStandalone位于 e2e/csharp/tests/FormatSpecificTests.cs测试通过环境变量注入模拟服务器地址var Input_MockBaseUrl Environment.GetEnvironmentVariable(MOCK_SERVER_FORMAT_DOCX_STANDALONE) ?? Environment.GetEnvironmentVariable(MOCK_SERVER_URL) /fixtures/format_docx_standalone;即优先使用专用变量MOCK_SERVER_FORMAT_DOCX_STANDALONE否则回退到通用MOCK_SERVER_URL并拼接 fixture 路径。运行脚本可参考 scripts/e2e/run-with-mock-server.sh它负责拉起 mock server 再执行各语言绑定测试。方式二在自有项目中调用绑定将 packages/csharp/Xberg 中的绑定源码与原生库Rust 核心编译产物纳入你的 .NET 项目或参考 packages/csharp/Xberg/Xberg.csproj 的工程组织方式像示例代码一样构造ExtractInput与ExtractionConfig调用await XbergConverter.ExtractAsync(...)注意确保运行环境具备对应的原生动态库不同平台的 native 产物否则 FFI 层无法加载。八、边界与注意点输入来源kind uri支持本地路径、file://与 HTTP(S) URL若文档以字节形式存在内存中改用kind bytes并配合FromBytes工厂方法。MIME 与扩展名虽然默认策略PreferContent会优先看内容但显式提供正确的 MIMEDOCX 为application/vnd.openxmlformats-officedocument.wordprocessingml.document能减少探测开销、避免误判尤其是远程 URL 场景。OCR 无关DOCX 属文本型格式OCR 相关配置对其无效OCR 参数只影响 PDF / 图片类文档。结果结构ExtractionResult.Results是集合类型即使单输入也以数组形式返回取Results[0]时需确认索引存在正文长度断言 20是测试对提取成功且非空的通用约定可作为你自己校验结果质量的参考。九、小结通过XbergConverter.ExtractAsyncC# 开发者可以用十几行代码完成 DOCX 的独立文本提取ExtractInput描述文档在哪、是什么格式ExtractionConfig控制如何提取ExtractionResult承载提取到什么。本文基于 docs-site/src/snippets-generated/csharp/format_specific/format_docx_standalone.md 的示例结合 ExtractInput.cs、ExtractionConfig.cs、XbergConverter.cs 的源码实现以及 FormatSpecificTests.cs 的测试用例把最小示例 → 字段语义 → MIME 判定 → 配置扩展 → 底层调用链 → 本地复现串成了一条完整的实践链路。需要处理 PDF、HWPX、PPTX、XLSX 等其他格式时替换MimeType与输入来源即可复用同一套调用模式。赞分享后端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 提取独立 DOCX 文档xberg_extract 与 ExtractInput 实战解析Xberg C FFI 提取独立 DOCX 文档xberg_extract 与 ExtractInput 实战解析 本篇技术指南围绕 Xberg 开源仓库中的后端AI 应用NLPXberg C FFI 实战使用 extract API 对 HWPX 韩文办公文档进行独立文本提取Xberg C FFI 实战使用 extract API 对 HWPX 韩文办公文档进行独立文本提取 本篇技术指南围绕 XbergRust 核心的 Poly后端AI 应用NLPxberg C FFI 实战DOCX 文档提取的冒烟测试全解析xberg C FFI 实战DOCX 文档提取的冒烟测试全解析 本文围绕 xberg 仓库中一条自动生成的 C 语言冒烟测试样例展开它演示了如何通过 C F后端AI 应用NLP上一篇Rust By Practice 所有权与借用专题用 4 级挑战彻底攻克 Rust 最难的一关下一篇如何选择最佳日语语音模型japanese-hubert-base与主流方案的终极对比创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考