拓冰网站定制 
后端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点击查看免费下载本文以仓库中自动生成的契约测试文档 output_format_bytes_markdown.md 为主线完整讲解如何在 Elixir 中通过Xberg.extract_async/2把内存中的 PDF 字节数组作为输入借助output_format: markdown配置得到 Markdown 形式的抽取结果并读懂其契约断言与底层实现。读完本文你将掌握Xberg.ExtractInput的构造方式、配置 JSON 的传递方法、结果信封ExtractionResult/ExtractedDocument/Metadata的字段含义以及如何对照仓库中的 fixture 与 e2e 测试验证该行为。契约测试文档讲的是什么docs-site/src/snippets-generated/elixir/contract/output_format_bytes_markdown.md是 alef 工具自动生成的 Elixir 语言测试片段文件头部标注了auto-generated by alef — DO NOT EDIT并带有alef:hash指纹可通过alef e2e generate/alef verify重新生成与校验。它属于contract主题归属于fixtures/contract下的 API 契约测试集目的是验证通过 bytes 提取 API 提交一段 PDF 字节并在配置中指定 Markdown 输出格式时返回结果的 mime 类型、正文内容和元数据是否符合预期。文档正文很短只有一段可执行的 Elixir 代码input_value %Xberg.ExtractInput{bytes: :binary.bin_to_list(File.read!(pdf/fake_memo.pdf)), config: %{output_format markdown}, filename: fake_memo.pdf, kind: bytes, mime_type: application/pdf} result Xberg.extract_async(input_value, {\output_format\:\markdown\}) IO.inspect(Enum.at(result.results, 0).mime_type) IO.inspect(Enum.at(result.results, 0).content) IO.inspect(Enum.at(result.results, 0).metadata.output_format)这段代码是整套 API 契约测试的最小复现它不依赖真实文件服务器而是把fake_memo.pdf的原始字节直接读入内存再交给提取引擎从而可以在无网络环境下验证“字节输入 输出格式控制”这条链路。下面逐行拆解。第一步构造统一输入结构 Xberg.ExtractInput示例中首先构造了一个%Xberg.ExtractInput{}结构体这是 Xberg Elixir 绑定提供的“统一提取输入”类型定义见 extract_input.ex。其字段与含义如下字段类型示例值说明kindXberg.ExtractInputKind.t()bytes输入来源类型bytes表示直接传字节数组uri表示传远程地址bytesbinary() \| nil:binary.bin_to_list(...)原始文档字节以整数列表形式传给底层 NIF因此示例用bin_to_list转换uriString.t() \| nil本例为nil当kind: uri时的目标地址mime_typeString.t() \| nilapplication/pdf声明输入文档的 MIME 类型filenameString.t() \| nilfake_memo.pdf原始文件名用于格式推断与元数据configXberg.FileExtractionConfig.t() \| nil%{output_format markdown}本次提取的配置此处直接放在结构体内从源码看该结构默认kind: :uri其余字段为nil并且它实现了Jason.Encoder编码时会剔除所有nil字段保证送入底层的是精简 JSON见 extract_input.ex。值得注意的一个细节示例里既在%Xberg.ExtractInput{config: %{output_format markdown}}中携带了配置又在调用extract_async时以第二个参数再次传入{\output_format\:\markdown\}。这是契约文档刻意展示的两种配置承载方式——配置既可以挂在输入结构上也可以作为独立 JSON 字符串参数传入最终都会合并到提取请求的 config 中。第二步调用 extract_async 并理解配置 JSON示例的第二行调用Xberg.extract_async(input_value, {\output_format\:\markdown\})。在 Elixir 绑定中实际面向用户的高层入口是Xberg.extract/1定义在 xberg.exdef extract(opts \\ []) do Xberg.Native.extract_async( case Keyword.get(opts, :input) do nil - nil v when is_binary(v) - v v - Jason.encode!(v) end, case Keyword.get(opts, :config) do nil - nil v when is_binary(v) - v v - Jason.encode!(v) end ) end可以看到input与config两个关键字参数中二进制字符串会原样透传map / struct 等数据结构会被Jason.encode!序列化为 JSON 字符串随后统一交给 NIF 层Xberg.Native.extract_async/2其声明位于 native.ex当 NIF 未加载时抛出:nif_not_loaded。这解释了为什么示例中第二个参数是一个 JSON 字符串字面量它等价于Xberg.extract(input: input_value, config: %{output_format markdown})两种写法在契约测试与 e2e 测试中均被验证见下文。配置里的output_format键在 Rust 核心侧由 handlers.rs 解析为crate::core::config::OutputFormat第 98 行附近的output_format: Optioncrate::core::config::OutputFormat并在第 317 行附近按output_format键读取最终决定ExtractedDocument.content字段以何种格式序列化。output_format 支持哪些值Elixir 侧的类型定义在 output_format.ex其moduledoc明确指出“该选项控制ExtractedDocument中content字段的格式”各取值如下值wire 值含义:plainplain纯文本默认:markdownmarkdownMarkdown 格式:djotdjotDjot 标记语言:htmlhtmlHTML 格式:jsonjson带标题驱动的章节结构的 JSON 树:doc_tagsdoctagsDocling DocTags 格式表格渲染为 OTSL:customcustom通过 RendererRegistry 注册的自定义渲染器如docx、latexwire_value/1函数output_format.ex把这些 Elixir atom 映射为跨语言 JSON 边界上的字符串值%{output_format markdown}中的markdown正是与:markdown对应的 wire 值。第三步解读返回的 results 结构示例后三行用Enum.at(result.results, 0)取出第一个抽取结果并打印三个字段这对应 Xberg Elixir 绑定的三层返回结构ExtractionResult见 extraction_result.ex统一结果信封包含results每个文档的抽取结果列表、errors错误项、summary汇总、以及爬虫相关字段crawl_final_urls/crawl_redirect_count/crawl_unique_normalized_urls。单文档场景下Enum.at(result.results, 0)即取到该文档。ExtractedDocument见 extracted_document.ex每个文档的完整载荷字段包括content、mime_type、metadata、extraction_method、tables、counts、detected_languages、chunks、images、pages、elements、quality_score等数十项覆盖文本、表格、图像、代码、公式、结构化输出等维度。Metadata见 metadata.ex文档级元数据其中就包含契约测试重点断言的output_format字段output_format: String.t() | nil它回显本次实际生效的输出格式。示例打印的三行输出分别对应Enum.at(result.results, 0).mime_type期望为application/pdf输入是什么格式结果仍标注什么格式Enum.at(result.results, 0).content期望为长度不小于 10 的 Markdown 正文PDF 中抽取出的文字内容按 Markdown 语法排版Enum.at(result.results, 0).metadata.output_format期望为markdown证明output_format配置确实被核心引擎接受并生效。契约断言的正式定义该测试片段的完整契约定义在同名 fixture JSON 中output_format_bytes_markdown.json。其中input部分给出了与示例一致的输入kind: bytes、mime_type: application/pdf、filename: fake_memo.pdf以及一长串以%PDF-1.3开头的真实 PDF 字节数组config为{output_format: markdown}而assertions部分用机器可读的方式把上面三步断言固化了下来断言类型字段路径期望值equalsresults[0].mime_typeapplication/pdfmin_lengthresults[0].content10equalsresults[0].metadata.output_formatmarkdown这套断言同时被 Elixir、Rust、Go、Python、Node 等多语言的 e2e 测试共享保证不同语言绑定对“bytes markdown 输出”这一契约行为的观测完全一致。在 e2e 测试中如何被验证仓库的 Elixir e2e 测试 contract_test.exs 第 27260 行起实现了与契约文档一一对应的describe output_format_bytes_markdown测试块input_value %Xberg.ExtractInput{ bytes: :binary.bin_to_list(File.read!(pdf/fake_memo.pdf)), config: %{output_format markdown}, filename: fake_memo.pdf, kind: bytes, mime_type: application/pdf } {:ok, result} Xberg.extract(input: input_value, config: {\output_format\:\markdown\}) assert Enum.at(result.results, 0).mime_type application/pdf assert (is_binary(Enum.at(result.results, 0).content) byte_size(Enum.at(result.results, 0).content) 10) || (is_list(Enum.at(result.results, 0).content) length(Enum.at(result.results, 0).content) 10) assert Enum.at(result.results, 0).metadata.output_format markdown测试的几处要点字节来源File.read!(pdf/fake_memo.pdf)从 e2e 测试工作目录读取 PDF 样本:binary.bin_to_list/1将其转为字节整数列表供底层 NIF 消费返回值处理Xberg.extract/1返回{:ok, result}元组失败时返回{:error, atom, String.t()}因此测试用模式匹配解包content 断言放宽content既可能是二进制字符串也可能是列表测试对两种情况都做了最小长度校验≥ 10这与 fixture 中的min_length: 10断言保持一致同样的测试块下方第 27280 行起还有output_format_markdown它改用kind: uri从 mock 服务器拉取同一个 PDF 后做相同断言正好构成“bytes 直传”与“uri 拉取”两种输入路径的对照证明output_format配置对两种入口一视同仁。从 bytes 到 URI输入形态的扩展kind字段决定了输入的来源形态是Xberg.ExtractInput中最重要的开关之一。契约文档演示的是bytes形态——适合已在内存中例如刚从数据库或网络下载的文档无需中间文件。仓库中与之对应的 URI 形态契约文档见 output_format_markdown.md同目录下其输入只构造了kind: uri与目标地址其余字段保持默认input_value %Xberg.ExtractInput{kind: uri, uri: https://example.com/pdf/fake_memo.pdf} result Xberg.extract_async(input_value, {\output_format\:\markdown\})此外如果需要对多个文档执行相同的 Markdown 输出配置可使用Xberg.extract_batch(inputs: [...], config: ...)定义见 xberg.ex它对应fixtures/contract/api_extract_batch_bytes_with_config.json等批量契约。选择原则可以概括为文档已在本进程内就传bytes文档在远端就传uri多份文档统一配置就走extract_batch。运行与验证方式上述契约片段与 e2e 测试的运行前提是Elixir 绑定已经加载了编译好的 Xberg 原生 NIFXberg.Native且测试环境下存在pdf/fake_memo.pdf样本文件。在本地复现时可按以下路径推进阅读并对照 output_format_bytes_markdown.md 与 output_format_bytes_markdown.json确认输入、配置与断言三者一致在 Elixir e2e 工程中运行contract_test.exs内output_format_bytes_markdown测试块文件路径 contract_test.exs观察三项断言是否全部通过若修改了契约文档或绑定代码按文件头注释使用alef e2e generate重新生成片段、用alef verify校验新鲜度并同步更新 fixtures/contract 下的对应 JSON 与各语言 e2e 测试。小结一条完整的“字节输入 → Markdown 输出”链路回顾整个契约文档可以把 Xberg 的 bytes Markdown 提取链路总结为四步构造输入%Xberg.ExtractInput{kind: bytes, bytes: 字节列表, mime_type: application/pdf, filename: fake_memo.pdf, config: %{output_format markdown}}调用入口Xberg.extract_async(input_value, {\output_format\:\markdown\})或等价的Xberg.extract(input: input_value, config: ...)配置 JSON 由 Elixir 绑定序列化后传入 NIF核心处理Rust 侧 handlers.rs 解析output_format为core::config::OutputFormat控制content字段的渲染格式读取结果从ExtractionResult.results取文档核对mime_type、content长度 ≥ 10 的 Markdown 正文与metadata.output_format markdown。这条链路既在自动生成的契约文档中有最小可执行示例又在 contract_test.exs 中有完整测试背书还可在 output_format_bytes_markdown.json 中找到机器可读的输入与断言——三者相互印证是理解 Xberg Elixir 绑定“输出格式控制”能力最直接、最可靠的入口。赞分享后端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 绑定实战使用 bytes 输入调用 extract 文档提取 APIxberg Dart 绑定实战使用 bytes 输入调用 extract 文档提取 API 本文围绕 xberg 的 Dart 语言绑定展开以 extrac后端AI 应用NLPxberg C API 实战通过 bytes 输入将 PDF 提取为 Markdown 输出格式xberg C API 实战通过 bytes 输入将 PDF 提取为 Markdown 输出格式 本文基于 xberg 仓库中自动生成的 C 语言契约测试片段后端AI 应用NLPbrpc baidu_std 协议 Wireshark 解析插件完全指南wireshark_baidu_std.lua 的安装、配置与源码剖析brpc baidu_std 协议 Wireshark 解析插件完全指南wireshark_baidu_std.lua 的安装、配置与源码剖析 wiresha后端AI 应用NLP上一篇终极指南解决Azure DevOps .NET示例项目的10个常见问题下一篇Azure DevOps Migration Tools 常见问题解决方案创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Xberg Elixir 文档提取实战：用 bytes 输入调用 extract API 并输出 Markdown 格式
后端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点击查看免费下载本文以仓库中自动生成的契约测试文档 output_format_bytes_markdown.md 为主线完整讲解如何在 Elixir 中通过Xberg.extract_async/2把内存中的 PDF 字节数组作为输入借助output_format: markdown配置得到 Markdown 形式的抽取结果并读懂其契约断言与底层实现。读完本文你将掌握Xberg.ExtractInput的构造方式、配置 JSON 的传递方法、结果信封ExtractionResult/ExtractedDocument/Metadata的字段含义以及如何对照仓库中的 fixture 与 e2e 测试验证该行为。契约测试文档讲的是什么docs-site/src/snippets-generated/elixir/contract/output_format_bytes_markdown.md是 alef 工具自动生成的 Elixir 语言测试片段文件头部标注了auto-generated by alef — DO NOT EDIT并带有alef:hash指纹可通过alef e2e generate/alef verify重新生成与校验。它属于contract主题归属于fixtures/contract下的 API 契约测试集目的是验证通过 bytes 提取 API 提交一段 PDF 字节并在配置中指定 Markdown 输出格式时返回结果的 mime 类型、正文内容和元数据是否符合预期。文档正文很短只有一段可执行的 Elixir 代码input_value %Xberg.ExtractInput{bytes: :binary.bin_to_list(File.read!(pdf/fake_memo.pdf)), config: %{output_format markdown}, filename: fake_memo.pdf, kind: bytes, mime_type: application/pdf} result Xberg.extract_async(input_value, {\output_format\:\markdown\}) IO.inspect(Enum.at(result.results, 0).mime_type) IO.inspect(Enum.at(result.results, 0).content) IO.inspect(Enum.at(result.results, 0).metadata.output_format)这段代码是整套 API 契约测试的最小复现它不依赖真实文件服务器而是把fake_memo.pdf的原始字节直接读入内存再交给提取引擎从而可以在无网络环境下验证“字节输入 输出格式控制”这条链路。下面逐行拆解。第一步构造统一输入结构 Xberg.ExtractInput示例中首先构造了一个%Xberg.ExtractInput{}结构体这是 Xberg Elixir 绑定提供的“统一提取输入”类型定义见 extract_input.ex。其字段与含义如下字段类型示例值说明kindXberg.ExtractInputKind.t()bytes输入来源类型bytes表示直接传字节数组uri表示传远程地址bytesbinary() \| nil:binary.bin_to_list(...)原始文档字节以整数列表形式传给底层 NIF因此示例用bin_to_list转换uriString.t() \| nil本例为nil当kind: uri时的目标地址mime_typeString.t() \| nilapplication/pdf声明输入文档的 MIME 类型filenameString.t() \| nilfake_memo.pdf原始文件名用于格式推断与元数据configXberg.FileExtractionConfig.t() \| nil%{output_format markdown}本次提取的配置此处直接放在结构体内从源码看该结构默认kind: :uri其余字段为nil并且它实现了Jason.Encoder编码时会剔除所有nil字段保证送入底层的是精简 JSON见 extract_input.ex。值得注意的一个细节示例里既在%Xberg.ExtractInput{config: %{output_format markdown}}中携带了配置又在调用extract_async时以第二个参数再次传入{\output_format\:\markdown\}。这是契约文档刻意展示的两种配置承载方式——配置既可以挂在输入结构上也可以作为独立 JSON 字符串参数传入最终都会合并到提取请求的 config 中。第二步调用 extract_async 并理解配置 JSON示例的第二行调用Xberg.extract_async(input_value, {\output_format\:\markdown\})。在 Elixir 绑定中实际面向用户的高层入口是Xberg.extract/1定义在 xberg.exdef extract(opts \\ []) do Xberg.Native.extract_async( case Keyword.get(opts, :input) do nil - nil v when is_binary(v) - v v - Jason.encode!(v) end, case Keyword.get(opts, :config) do nil - nil v when is_binary(v) - v v - Jason.encode!(v) end ) end可以看到input与config两个关键字参数中二进制字符串会原样透传map / struct 等数据结构会被Jason.encode!序列化为 JSON 字符串随后统一交给 NIF 层Xberg.Native.extract_async/2其声明位于 native.ex当 NIF 未加载时抛出:nif_not_loaded。这解释了为什么示例中第二个参数是一个 JSON 字符串字面量它等价于Xberg.extract(input: input_value, config: %{output_format markdown})两种写法在契约测试与 e2e 测试中均被验证见下文。配置里的output_format键在 Rust 核心侧由 handlers.rs 解析为crate::core::config::OutputFormat第 98 行附近的output_format: Optioncrate::core::config::OutputFormat并在第 317 行附近按output_format键读取最终决定ExtractedDocument.content字段以何种格式序列化。output_format 支持哪些值Elixir 侧的类型定义在 output_format.ex其moduledoc明确指出“该选项控制ExtractedDocument中content字段的格式”各取值如下值wire 值含义:plainplain纯文本默认:markdownmarkdownMarkdown 格式:djotdjotDjot 标记语言:htmlhtmlHTML 格式:jsonjson带标题驱动的章节结构的 JSON 树:doc_tagsdoctagsDocling DocTags 格式表格渲染为 OTSL:customcustom通过 RendererRegistry 注册的自定义渲染器如docx、latexwire_value/1函数output_format.ex把这些 Elixir atom 映射为跨语言 JSON 边界上的字符串值%{output_format markdown}中的markdown正是与:markdown对应的 wire 值。第三步解读返回的 results 结构示例后三行用Enum.at(result.results, 0)取出第一个抽取结果并打印三个字段这对应 Xberg Elixir 绑定的三层返回结构ExtractionResult见 extraction_result.ex统一结果信封包含results每个文档的抽取结果列表、errors错误项、summary汇总、以及爬虫相关字段crawl_final_urls/crawl_redirect_count/crawl_unique_normalized_urls。单文档场景下Enum.at(result.results, 0)即取到该文档。ExtractedDocument见 extracted_document.ex每个文档的完整载荷字段包括content、mime_type、metadata、extraction_method、tables、counts、detected_languages、chunks、images、pages、elements、quality_score等数十项覆盖文本、表格、图像、代码、公式、结构化输出等维度。Metadata见 metadata.ex文档级元数据其中就包含契约测试重点断言的output_format字段output_format: String.t() | nil它回显本次实际生效的输出格式。示例打印的三行输出分别对应Enum.at(result.results, 0).mime_type期望为application/pdf输入是什么格式结果仍标注什么格式Enum.at(result.results, 0).content期望为长度不小于 10 的 Markdown 正文PDF 中抽取出的文字内容按 Markdown 语法排版Enum.at(result.results, 0).metadata.output_format期望为markdown证明output_format配置确实被核心引擎接受并生效。契约断言的正式定义该测试片段的完整契约定义在同名 fixture JSON 中output_format_bytes_markdown.json。其中input部分给出了与示例一致的输入kind: bytes、mime_type: application/pdf、filename: fake_memo.pdf以及一长串以%PDF-1.3开头的真实 PDF 字节数组config为{output_format: markdown}而assertions部分用机器可读的方式把上面三步断言固化了下来断言类型字段路径期望值equalsresults[0].mime_typeapplication/pdfmin_lengthresults[0].content10equalsresults[0].metadata.output_formatmarkdown这套断言同时被 Elixir、Rust、Go、Python、Node 等多语言的 e2e 测试共享保证不同语言绑定对“bytes markdown 输出”这一契约行为的观测完全一致。在 e2e 测试中如何被验证仓库的 Elixir e2e 测试 contract_test.exs 第 27260 行起实现了与契约文档一一对应的describe output_format_bytes_markdown测试块input_value %Xberg.ExtractInput{ bytes: :binary.bin_to_list(File.read!(pdf/fake_memo.pdf)), config: %{output_format markdown}, filename: fake_memo.pdf, kind: bytes, mime_type: application/pdf } {:ok, result} Xberg.extract(input: input_value, config: {\output_format\:\markdown\}) assert Enum.at(result.results, 0).mime_type application/pdf assert (is_binary(Enum.at(result.results, 0).content) byte_size(Enum.at(result.results, 0).content) 10) || (is_list(Enum.at(result.results, 0).content) length(Enum.at(result.results, 0).content) 10) assert Enum.at(result.results, 0).metadata.output_format markdown测试的几处要点字节来源File.read!(pdf/fake_memo.pdf)从 e2e 测试工作目录读取 PDF 样本:binary.bin_to_list/1将其转为字节整数列表供底层 NIF 消费返回值处理Xberg.extract/1返回{:ok, result}元组失败时返回{:error, atom, String.t()}因此测试用模式匹配解包content 断言放宽content既可能是二进制字符串也可能是列表测试对两种情况都做了最小长度校验≥ 10这与 fixture 中的min_length: 10断言保持一致同样的测试块下方第 27280 行起还有output_format_markdown它改用kind: uri从 mock 服务器拉取同一个 PDF 后做相同断言正好构成“bytes 直传”与“uri 拉取”两种输入路径的对照证明output_format配置对两种入口一视同仁。从 bytes 到 URI输入形态的扩展kind字段决定了输入的来源形态是Xberg.ExtractInput中最重要的开关之一。契约文档演示的是bytes形态——适合已在内存中例如刚从数据库或网络下载的文档无需中间文件。仓库中与之对应的 URI 形态契约文档见 output_format_markdown.md同目录下其输入只构造了kind: uri与目标地址其余字段保持默认input_value %Xberg.ExtractInput{kind: uri, uri: https://example.com/pdf/fake_memo.pdf} result Xberg.extract_async(input_value, {\output_format\:\markdown\})此外如果需要对多个文档执行相同的 Markdown 输出配置可使用Xberg.extract_batch(inputs: [...], config: ...)定义见 xberg.ex它对应fixtures/contract/api_extract_batch_bytes_with_config.json等批量契约。选择原则可以概括为文档已在本进程内就传bytes文档在远端就传uri多份文档统一配置就走extract_batch。运行与验证方式上述契约片段与 e2e 测试的运行前提是Elixir 绑定已经加载了编译好的 Xberg 原生 NIFXberg.Native且测试环境下存在pdf/fake_memo.pdf样本文件。在本地复现时可按以下路径推进阅读并对照 output_format_bytes_markdown.md 与 output_format_bytes_markdown.json确认输入、配置与断言三者一致在 Elixir e2e 工程中运行contract_test.exs内output_format_bytes_markdown测试块文件路径 contract_test.exs观察三项断言是否全部通过若修改了契约文档或绑定代码按文件头注释使用alef e2e generate重新生成片段、用alef verify校验新鲜度并同步更新 fixtures/contract 下的对应 JSON 与各语言 e2e 测试。小结一条完整的“字节输入 → Markdown 输出”链路回顾整个契约文档可以把 Xberg 的 bytes Markdown 提取链路总结为四步构造输入%Xberg.ExtractInput{kind: bytes, bytes: 字节列表, mime_type: application/pdf, filename: fake_memo.pdf, config: %{output_format markdown}}调用入口Xberg.extract_async(input_value, {\output_format\:\markdown\})或等价的Xberg.extract(input: input_value, config: ...)配置 JSON 由 Elixir 绑定序列化后传入 NIF核心处理Rust 侧 handlers.rs 解析output_format为core::config::OutputFormat控制content字段的渲染格式读取结果从ExtractionResult.results取文档核对mime_type、content长度 ≥ 10 的 Markdown 正文与metadata.output_format markdown。这条链路既在自动生成的契约文档中有最小可执行示例又在 contract_test.exs 中有完整测试背书还可在 output_format_bytes_markdown.json 中找到机器可读的输入与断言——三者相互印证是理解 Xberg Elixir 绑定“输出格式控制”能力最直接、最可靠的入口。赞分享后端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 绑定实战使用 bytes 输入调用 extract 文档提取 APIxberg Dart 绑定实战使用 bytes 输入调用 extract 文档提取 API 本文围绕 xberg 的 Dart 语言绑定展开以 extrac后端AI 应用NLPxberg C API 实战通过 bytes 输入将 PDF 提取为 Markdown 输出格式xberg C API 实战通过 bytes 输入将 PDF 提取为 Markdown 输出格式 本文基于 xberg 仓库中自动生成的 C 语言契约测试片段后端AI 应用NLPbrpc baidu_std 协议 Wireshark 解析插件完全指南wireshark_baidu_std.lua 的安装、配置与源码剖析brpc baidu_std 协议 Wireshark 解析插件完全指南wireshark_baidu_std.lua 的安装、配置与源码剖析 wiresha后端AI 应用NLP上一篇终极指南解决Azure DevOps .NET示例项目的10个常见问题下一篇Azure DevOps Migration Tools 常见问题解决方案创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考