ConvertX 认知选型:自托管万能文件转换器的定位、引擎与替代方案

ConvertX v0.19.0 认知选型篇:自托管万能文件转换器的定位、22 个转换引擎矩阵、技术栈分析,以及与 VERT.sh、Stirling-PDF、CloudConvert 的量化对比与选型建议,全部信息标注来源与查询日期 2026-10-28。

ConvertX文件转换自托管2026/10/28

ConvertX 认知选型:自托管万能文件转换器的定位、引擎与替代方案

认知溯源篇:本文全部信息来自公开网络资料(官方仓库、官方 README、shields.io 徽章、vert.sh、cloudconvert.com/pricing),检索与核对日期为 2026-10-28,未包含任何本地实测内容。部署、配置与命令实战见同专栏后续三篇。

一、ConvertX 是什么

ConvertX 是一款自托管的在线文件格式转换器(self-hosted online file converter),官方仓库为 C4illin/ConvertX,README 的第一句自我定义是 "A self-hosted online file converter. Supports over a thousand different formats."(一个自托管的在线文件转换器,支持超过一千种不同的格式)。

它的核心产品逻辑是:把 ImageMagick、FFmpeg、Pandoc、LibreOffice、Calibre 等成熟命令行转换工具聚合到同一个 Web 界面背后——用户在浏览器里上传文件、选择目标格式,服务端自动分派给对应的引擎完成转换。对使用者而言是"一个网页转一切",对运维者而言是"一台服务器上的一组标准开源工具的编排层"。

项目信息内容(2026-10-28 查证)
仓库github.com/C4illin/ConvertX
最新稳定版v0.19.0(2026-09-26 发布,来源:GitHub Releases feed)
许可证AGPL-3.0(仓库页标注)
技术栈TypeScript + Bun + Elysia(README)
社区热度shields.io 徽章显示 GitHub Stars 约 19k 量级
官方交付形态以预构建 OCI 运行时为主要形态(ghcr.io / c4illin/convertx,latest 与 main 双标签),同时是标准 Bun 项目,可源码直装

二、核心功能(官方 README 口径)

  • 格式互转:覆盖一千种以上输入/输出组合,由 22 个转换引擎共同支撑;
  • 批量处理:一次任务(Process)可同时上传并转换多个文件;
  • 多账号:内置账号体系,首个注册账号由"首次运行"流程创建,支持开启/关闭注册;
  • 密码保护:全站 JWT 登录态保护,支持禁止未认证访问;
  • 自动清理:内置按小时粒度的历史任务自动删除机制(AUTO_DELETE_EVERY_N_HOURS,默认 24 小时);
  • 可定制:站点名(BRANDING)、子路径发布(WEBROOT)、界面语言(LANGUAGE)均可通过环境变量调整。

值得注意的是,ConvertX 不追求单文件深度处理:它的定位是"格式广度优先"的万能转换台,而非某一类文件的专业工作站。

三、架构与技术栈分析

ConvertX 的架构可以概括为三层:

  1. Web 层:Elysia(基于 Bun 的 TypeScript Web 框架)提供页面与表单路由,登录态用 @elysiajs/jwt 签发的 JWT Cookie 维持;
  2. 编排层:一份"引擎注册表"(converters 注册模块)声明每个引擎支持的输入/输出格式映射,收到转换请求后按"目标格式,引擎名"分派;
  3. 执行层:真正的转换由服务端调用系统命令行工具完成——ImageMagick、GraphicsMagick、FFmpeg、Pandoc、LibreOffice(无头模式)、Calibre(ebook-convert)、Inkscape 等,输出文件落在按用户/任务组织的输出目录。

持久化采用 SQLite 单库,数据目录(库文件 + 上传区 + 输出区)即为全部状态,这使备份恢复天然简单。运行时依赖 Bun(官方构建锁定 bun-v1.4.2),资源占用轻,单机即可承载小型团队使用。

这种"聚合器"架构的优缺点同样鲜明:优点是格式矩阵极大、引擎可独立升级、行为与对应 CLI 工具一致、可预期性强;缺点是能力上限取决于所聚合的 CLI(例如 PDF 引擎依赖 XeLaTeX 全家桶,直装时依赖清单不小),且不支持分布式/集群部署——它是典型的单机自托管服务。

四、转换引擎矩阵(官方 README,2026-10-28 查证)

引擎用途可转自可转至
ImageMagick图像245183
FFmpeg视频/音频~472~199
GraphicsMagick图像167130
Assimp3D 资产7723
Pandoc文档4365
LibreOffice办公文档4122
Calibre电子书2619
Vips图像4523
Inkscape矢量图717
libjxlJPEG XL1111
VTracer位图转矢量81
Potrace位图转矢量411
libheifHEIF24
Dasel数据文件(JSON/YAML/TOML 等)54
DjVuLibreDjVu 文档22
dvisvgm矢量图42
XeLaTeXLaTeX11
Markitdown(微软)文档转 Markdown61
msgconvertOutlook 邮件11
VCF to CSV联系人11
resvgSVG11
pdftops(Poppler)PDF/PS12

官方同时注明:FFmpeg 的格式计数存在重复统计。引用时建议以"引擎 × 用途"的定性判断为主,精确到数字时应自行以目标版本实测为准。

五、量化选型对比:ConvertX vs VERT.sh vs Stirling-PDF vs CloudConvert

四款产品经常出现在同一份候选清单里,但它们解决的是三类不同的问题。下表数据均于 2026-10-28 查证,来源标注在表后。

维度ConvertXVERT.shStirling-PDFCloudConvert
产品形态自托管 Web 服务自托管/公开实例 Web 服务自托管 Web 服务公有云 SaaS + API
文件去向上传后在本机服务端转换,存于输出目录"尽可能完全在设备端转换"(官网 About 原文 "all files are converted completely on-device")本机服务端处理上传至云端处理
格式广度1000+ 组合(22 引擎)常见图像/文档/音视频/3D 模型PDF 专精(合并/拆分/OCR/签名等数十项)官方宣称 200+ 格式
PDF 深度由 Pandoc/XeLaTeX/LibreOffice/pdftops 承担,偏"生成/转出"基础最强项:PDF 全流程操作支持,按 credits 计费
电子书/3D/矢量化支持(Calibre/Assimp/Potrace/VTracer)部分(含 3D 模型)无部分
账号体系JWT 多账号、可关注册公开实例无账号可配置账号 + API Key
计费免费自托管(承担服务器与带宽成本)免费开源,接受捐赠免费自托管Free 档 10 credits/日、单文件 1GB、单任务 5 分钟、并发 5;Package 一次性付费或 Subscription 月付
许可证AGPL-3.0(仓库页)AGPL-3.0(shields.io license 徽章)仓库页未标注可识别许可(以仓库 LICENSE 为准)专有(闭源商业服务)
GitHub Stars(2026-10-28)≈19k(shields.io)≈16k(shields.io)≈95k(shields.io)—(闭源)
合规要点AGPL:对外提供服务需遵守 AGPL 义务同左以仓库许可文本为准数据出域/SLA 按商业合同

来源标注:

  • ConvertX:github.com/C4illin/ConvertX 仓库页与 README、GitHub Releases feed(releases.atom),2026-10-28;
  • VERT.sh:vert.sh 首页与 /about 页("Why VERT?" 定位描述)、github.com/vert-sh/vert,2026-10-28;
  • Stirling-PDF:github.com/Stirling-Tools/Stirling-PDF 仓库页、shields.io stars/license 徽章,2026-10-28;
  • CloudConvert:cloudconvert.com/pricing(Free 档额度与付费档说明),2026-10-28;
  • 星数均为 shields.io GitHub Stars 徽章实时渲染值,查询日期 2026-10-28。

解读与选型建议:

  1. ConvertX 的生态位是"自托管万能转换台"——当团队需求是"什么都可能要转一点"(图片、视频、文档、电子书、数据文件、甚至 3D 模型)且文件不能离开内网时,ConvertX 的引擎聚合优势最明显;代价是首次部署的转换后端依赖较多。
  2. VERT.sh 的生态位是"零信任隐私转换":转换尽量发生在浏览器端,服务器几乎不经手文件,适合对文件敏感、临时性、低并发的小流量场景;格式广度与批量、账号能力弱于 ConvertX。
  3. Stirling-PDF 的生态位是"PDF 专用工作台":若需求 90% 集中在 PDF 的合并、拆分、OCR、压缩、签名,它的深度无可替代;但拿它转图片视频就大材小用且能力不足。两者也可以互补部署。
  4. CloudConvert 的生态位是"免运维的 API 计费服务":适合嵌入业务系统(应用内格式转换 API)、无自托管运维能力的团队;代价是数据出域、按 credits 计费与供应商锁定。
  5. 若纠结 ConvertX 与 VERT.sh:看文件是否允许出客户端与是否需要账号/历史管理——需要服务端批量与历史记录选 ConvertX,追求端侧隐私且格式常见选 VERT.sh。

六、版本与发布节奏

  • v0.19.0(2026-09-26):官方说明为"积压已久的缺陷修复版本",新增站点自定义品牌名(自 v0.19 起支持 PUID/PGID 以非特权身份运行转换进程)、新增 pdftops 转换器、Calibre 支持 azw3 输入、FFmpeg 新增 m2ts/ts/vob/wmv 输入与 mka 输出、soffice 支持 Excel/Calc 电子表格转换、ImageMagick 转换时应用 EXIF 方向等(来源:v0.19.0 Release Notes,2026-10-28 查证);
  • 发布节奏自 2025 年起大致保持季度级稳定迭代(v0.14.1 2025-06、v0.15 2025-10、v0.16 2025-12、v0.17 2026-01、v0.18 2026-06、v0.19 2026-09),对自托管用户而言升级压力小,但也意味着新引擎需求响应不快;
  • 项目处于活跃维护状态(README 徽章区含 commits-since-latest 动态徽章),社区教程覆盖法语/中文/波兰语等,中文教程见 xzllll.com(官方 README 收录,2026-10-28 查证)。

七、适用与不适用场景

适合:

  • 个人/小团队内网自建"万能格式转换站",替代对公有云转换服务的依赖;
  • NAS/家庭服务器用户:轻量运行时 + 单文件数据库,备份简单;
  • 需要批量转换历史记录与多账号隔离的场景(ConX 的任务/历史页按用户隔离)。

不适合:

  • 高并发生产级转换服务:单机架构、无队列/集群设计,大流量应评估专用转码管线;
  • PDF 深度操作为主的需求(选 Stirling-PDF 类专精工具);
  • 零运维、希望按量付费的团队(选 CloudConvert 类 SaaS);
  • 对 AGPL 合规敏感且不愿开源修改的场景(AGPL 服务义务需要评估)。

八、小结

ConvertX 以"22 个成熟转换引擎 + 一个轻量 Web 壳"的组合,把"自托管文件转换"做成了一件低门槛的事:格式广度在自托管产品中几乎无出其右,SQLite + 单数据目录让运维负担接近于零;它的短板(PDF 深度、集群化)恰好由 Stirling-PDF 等专精工具与其他架构形态补位。若你的服务器上只打算放一个文件转换服务,ConvertX 是 2026 年自托管清单里的默认候选之一。

九、同系列导航