 管理文档渲染器注册表)
后端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::listRenderers()是 xberg 项目 PHP 绑定暴露的插件管理 API用于列出当前进程中已注册的全部文档渲染器renderer名称。渲染器负责把管道内部的文档表示转换为最终输出格式字符串——包括内置的 Markdown、HTML、Djot、DocTags、DOT、DOCX、PDF 与纯文本以及由用户在运行时注册的自定义格式。读完本文你将掌握listRenderers()的调用方式、返回数据结构、内置渲染器清单、与clearRenderers()的配合使用以及它背后由 Rust 核心维护的全局渲染器注册表的工作机制。文档来源与定位本主题对应的关联文档为仓库中的自动生成快照renderers_list.md。它是 alef 多语言绑定生成器产出的 E2E 测试片段front-matter 声明了id: fixture_php_renderers_list、language: php、target: php且side_effect: safe无副作用可安全重复调用。该类片段由alef e2e generate生成、alef verify校验新鲜度因此其中的 PHP 调用代码与当前绑定实现保持同步。同一类快照还有 renderers_clear.md清空全部渲染器与 registry/list_renderers.md注册表类别下的同功能变体说明listRenderers同时被归类为插件 API 与注册表管理 API 两类测试主题。一、核心用法列出所有已注册渲染器关联文档给出的完整 PHP 代码段如下?php declare(strict_types1); require_once __DIR__ . /vendor/autoload.php; use Xberg\Xberg; $result Xberg::listRenderers(); var_dump($result);关键点逐一说明declare(strict_types1)PHP 8.2 严格类型模式保证绑定调用传参/返回类型校验严格require_once __DIR__ . /vendor/autoload.php加载 Composer 自动加载器。PHP 包通过composer require xberg-io/xberg安装见 packages/php/README.mdXberg::listRenderers()静态调用对应 Rust 端list_renderers()函数。它无参数、无副作用返回当前全局注册表中全部渲染器名称的字符串数组var_dump($result)输出数组内容与类型适合在脚本中快速确认注册表状态。返回值语义Rust 端实现位于 crates/xberg/src/plugins/renderer.rspub fn list_renderers() - ResultVecString { use crate::plugins::registry::get_renderer_registry(); let registry get_renderer_registry(); let registry registry.read(); Ok(registry.list()) }函数读取全局注册表的只读锁并返回VecString——即每个渲染器的格式名format name。在 PHP 中这对应liststring类型的结果可直接用foreach遍历或in_array()判断某个格式是否可用foreach ($result as $name) { echo renderer: {$name}\n; }二、内置渲染器注册表默认装载的八种格式listRenderers()首次调用时返回的列表并非空数组。全局注册表在构造时会装载一批内置渲染器见 crates/xberg/src/plugins/registry/renderer.rs渲染器名称输出格式说明markdownGFM Markdown基于 comrak 渲染htmlHTML5基于 comrak 渲染djotDjot 标记语言Djot 语法输出doctagsDocling DocTags表格输出为 OTSL对象树序列化语言dotGraphviz DOT从矢量来源恢复的图表docxOffice Open XMLbase64 编码需office特性feature编译pdfPDFbase64 编码需pdf特性编译plain纯文本无任何格式其中docx与pdf渲染器受 Cargo feature 门控只有启用office/pdf特性构建的二进制才会注册这两个名称。因此listRenderers()返回的具体集合取决于运行环境构建配置这一点在跨环境比对输出时应特别注意。上述默认集也体现在 registry 文档注释与单元测试中例如 crates/xberg/src/plugins/registry/renderer.rs 明确注释内置渲染器为markdown, html, djot, doctags, dot, docx, pdf, plain。三、结合 clearRenderers() 的注册表管理闭环listRenderers()通常与写入型 API 搭配使用形成查看-修改-复查的管理闭环。关联的姊妹快照 renderers_clear.md 演示了清空操作?php declare(strict_types1); require_once __DIR__ . /vendor/autoload.php; use Xberg\Xberg; Xberg::clearRenderers();典型排查流程调用Xberg::listRenderers()记录当前注册表快照注册自定义渲染器Xberg::registerRenderer(...)或清空注册表Xberg::clearRenderers()再次调用Xberg::listRenderers()验证变更生效。clearRenderers()在 Rust 端对应 crates/xberg/src/plugins/renderer.rs 的clear_renderers()会移除包括内置渲染器在内的全部条目。清空后注册表为空——此时若某次渲染请求按名称查找渲染器将由自愈机制ensure_renderers_initialized()重新装载内置渲染器见 crates/xberg/src/plugins/renderer.rs确保Custom输出格式派发路径不会因注册表被清空而中断。该自愈过程非破坏性用户注册的渲染器会被保留。四、底层原理全局渲染器注册表listRenderers()的数据来源是 crate 级的全局单例注册表定义于 crates/xberg/src/plugins/registry/renderer.rs。其核心结构为pub struct RendererRegistry { renderers: AHashMapString, RegisteredRenderer, }键为格式名即Plugin::name()的返回值也是listRenderers()返回列表中的每个元素值为 RegisteredRenderer区分内部internal即原生 Rust 渲染器与公开public即跨语言桥接注册的渲染器两种来源线程安全通过parking_lot::RwLock保护可被多线程并发读写list_renderers()仅取读锁因此并发安全且无副作用。渲染器本身是Plugin特性的子类型。公开的Renderer特性定义了绑定安全的入口render_result(ExtractedDocument) - ResultString其默认实现直接返回result.content原样文本见 crates/xberg/src/plugins/renderer.rs。这意味着即使是最简单的自定义渲染器不覆盖render_result也能通过注册表列出只是行为退化为透传已渲染文本。从源码结构看注册/注销对称性与listRenderers()配套的还有register_renderer(Arcdyn Renderer) - Result()——注册渲染器名称冲突时以新替旧并对名称做合法性校验crates/xberg/src/plugins/renderer.rsunregister_renderer(name: str) - Result()——按格式名注销同文件 L112-L118clear_renderers() - Result()——清空全部同文件 L141-L148。这些函数均通过get_renderer_registry()获取全局注册表构成一个对称、可审计的插件生命周期list只读、register/unregister精确变更、clear整体重置。五、测试与 E2E 契约如何验证该 API 的行为单元测试证据Rust 核心的单元测试直接验证了list_renderers()与注册/注销/清空的联动crates/xberg/src/plugins/renderer.rsregister_list_unregister_roundtrip注册test-fmt-a后list_renderers()结果必须包含该名称注销后必须不再包含register_list_clear_list_roundtrip注册test-fmt-b后list_renderers()包含它调用clear_renderers()后列表为空。这两组用例精确刻画了listRenderers()的语义它是注册表当前状态的忠实镜像。E2E fixture 契约PHP 侧的调用由 JSON fixture 驱动生成renderers_list.json 声明了{ id: renderers_list, category: renderer_management, call: list_renderers, assertions: [{ type: not_error }] }即该用例的核心断言是调用不报错验证 PHP 绑定到 Rust 核心的调用链Xberg::listRenderers()→ alef trait-bridge →list_renderers()可用。fixture 体系说明见 fixtures/plugin_api/README.md其中simple_list模式描述的正是这种无需 setup、返回字符串列表的测试形态。所有 E2E 测试均由 fixture 生成不允许手写见 README 的 Notes 章节以保证 15 种语言绑定的 API 行为完全一致。六、实战建议排查渲染问题优先列清单当Custom输出格式渲染异常时先Xberg::listRenderers()确认期望的格式名是否在注册表中再判断是 feature 未启用还是注册表被清空注意 feature 门控差异docx/pdf是否出现在列表中取决于构建时是否启用office/pdf特性不要对这两项做硬性假设把 clear 视作可自愈操作clearRenderers()清空内置渲染器后下一次渲染会触发ensure_renderers_initialized()自愈重装无需手动重新注册内置项在脚本中做存在性检查注册自定义渲染器前可先listRenderers()判断格式名是否已被占用register同名校名会覆盖旧渲染器。小结Xberg::listRenderers()是一个零副作用、线程安全、跨语言一致的注册表查询 APIPHP 一行静态调用即可读取由 Rust 全局注册表维护的全部渲染器清单。它既能用来审计内置的八种输出格式也能验证自定义渲染器的注册结果是理解与调试 xberg 插件渲染体系的第一入口。赞分享后端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 绑定实战用 listRenderers 管理渲染器注册表xberg Dart 绑定实战用 listRenderers 管理渲染器注册表 本指南以 xberg 官方 Dart 语言绑定中的 renderers_lis后端AI 应用NLPxberg Go 绑定之渲染器管理用 ListRenderers 查询已注册文档渲染器xberg Go 绑定之渲染器管理用 ListRenderers 查询已注册文档渲染器 xberg 以 Rust 核心提供多语言文档智能提取能力其渲染器R后端AI 应用NLPXberg Dart 绑定实战使用 listRenderers 枚举全部已注册渲染器Xberg Dart 绑定实战使用 listRenderers 枚举全部已注册渲染器 本篇指南围绕 Xberg 开源仓库中 Dart 语言绑定下的 listR后端AI 应用NLP上一篇深入解析 babel/runtime-corejs3基于 core-js3 的模块化运行时辅助库下一篇Meteor Accounts 完全指南用户模型、会话存储与密码/OAuth 登录认证体系深度解析创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
