给NAS装个万能格式转换器,PDF、图片、视频全都本地,不传第三方
前言
之前在威联通Qu805上折腾过Qsirch AI Mode和RAGFlow,一个管搜索,一个管知识库。这次的需求是文件格式转换。平时经常碰到各种格式要转来转去的情况,PDF转Word,图片转格式,视频抽音频,电子书换格式。以前都是找在线转换网站,把文件传上去,转完再下载。文件内容经手第三方服务器,心里总觉得有点不对。这次我把转换服务直接装到NAS上,所有转换都在本地完成。

选的是ConvertX,一个支持Docker部署的开源文件转换器,项目集成了多种转换引擎,覆盖上千种输入、输出格式和转换场景,但具体能够转换成哪些目标格式,仍取决于文件类型和对应转换引擎。这篇文章记录在威联通Qu805上的完整部署过程和实际使用体验。
一、ConvertX是什么
ConvertX是一个可自托管的在线文件转换服务。它的核心思路是把数据处理的控制权交还给用户。所有转换任务都在你自己的NAS或者私人服务器本地完成,文件不需要上传到任何第三方平台,数据泄露的风险从根源上被杜绝了。
它支持单文件转换,也支持批量处理。还提供了密码保护和多账户管理功能,适合个人使用,也适合小型团队共享,每个人有独立的访问权限。
部署方式对NAS用户很友好。支持Docker,在威联通的Container Station里创建应用程序,粘贴Docker Compose YAML代码就能跑起来。整个界面也很简单,把文件拖进去就能开始转换。
二、格式兼容性

ConvertX能支持这么多格式,靠的是集成了多种专业级转换引擎。每种引擎负责一个领域,组合起来覆盖了绝大部分日常需求。
图片方面,它用ImageMagick和GraphicsMagick处理,能转换超过245种图片格式。日常用的JPEG、PNG、WebP、HEIC这些都不在话下,各种小众的格式也能覆盖到。
文档转换主要依靠 LibreOffice 和 Pandoc。根据项目官方列表,LibreOffice 支持约41种输入格式和22种输出格式,Pandoc支持约43种输入格式和65种输出格式。PDF转Word,Word转Markdown,Markdown转HTML,这些常用场景都能处理。LibreOffice负责办公文档的相互转换,Pandoc负责标记语言和电子文档之间的转换。
视频音频方面,FFmpeg引擎提供了约472种输入格式和199种输出格式的处理能力。视频转码,音频抽取,格式封装,这类需求都能满足。
除了这三块主力,还有针对矢量图形、电子书、3D模型等领域的专用工具。SVG、EPUB这类格式有自己的处理引擎,专业需求也能覆盖。
三、部署准备
我的威联通Qu805支持Container Station,跑Docker没有任何压力。ConvertX的部署不需要额外开启SSH,全程可以在图形界面完成,这点比之前装RAGFlow要省事很多。

准备工作其实就一步,确认Container Station已经安装并更新到最新版本。然后在Container Station里找到创建应用程序的功能入口。
四、部署步骤
打开Container Station,进入应用程序页面,点击创建,选择创建应用程序。ConvertX官方仓库提供了Docker Compose配置,直接粘贴进去就行。
我用的配置大概长这样。
services:
convertx:
image: ghcr.io/c4illin/convertx:latest
container_name: convertx
restart: unless-stopped
ports:
- "3014:3000"
environment:
# 请替换为本地生成的固定随机字符串
JWT_SECRET: "请替换为至少64位的随机十六进制字符串"
# 仅限可信局域网通过HTTP直连时使用
# 配置HTTPS反向代理后应改为false
HTTP_ALLOWED: "true"
# 首个账号仍然可以正常初始化
ACCOUNT_REGISTRATION: "false"
ALLOW_UNAUTHENTICATED: "false"
# 每24小时检查并清理超过24小时的转换文件
AUTO_DELETE_EVERY_N_HOURS: "24"
# 普通NAS建议限制为1,性能较强的设备可测试2
MAX_CONVERT_PROCESS: "1"
TZ: "Asia/Shanghai"
volumes:
# 请根据自己的共享文件夹路径修改
- /share/Container/convertx/data:/app/data
有几个关键配置点需要单独说。
第一是端口映射。默认是3000:3000,把容器的3000端口映射到NAS的3000端口。如果你的NAS上3000端口被其他服务占用了,可以改成别的,比如3014:3000,访问地址跟着变就行。
第二是JWT_SECRET。这个是用于签发和验证登录令牌,必须设置为固定且难以猜测的随机字符串。它负责登录会话安全,但不能替代 HTTPS,也不会加密文件传输过程。
第三是ALLOW_REGISTRATION。这个开关决定是否开放用户注册。自己一个人用,可以先开注册建好账户,然后把它改成false关掉,防止别人注册进来。如果是团队用,保持true,让大家各自注册账号。

容器启动后,浏览器打开NAS的IP地址加端口。
第一次访问会看到注册页面。注册一个账号,登录进去就是主界面了。主界面很干净,中间一个大拖拽区域,周围是转换任务列表和设置入口。

登录后第一件事我建议去设置里看一下账户安全相关的选项。创建首个账号后,再次检查 Compose 中的 ACCOUNT_REGISTRATION 是否为 false。如果修改了环境变量,需要在 Container Station 中重新应用应用程序配置。密码保护生效之后,整个服务相当于加了一道锁,只有有账号的人才能使用转换功能。
六、实际使用体验
部署完顺手测了几个典型的转换场景。

第一个是PDF转Word。我拿了一份之前攒的PDF文档拖进去,选择Word格式,点转换。几十秒完成,下载下来打开看,文字和段落基本都保留了,排版有轻微变化,但内容完整。对日常使用来说这个质量够用了。

PDF文件转Word的话,受限于NAS性能,相对来说比在台式机上转换要更慢一点,不过,反正NAS是24小时开机的,它慢慢转换也行。

第二个是图片格式转换。一张HEIC格式的照片,转成JPEG。拖进去选格式,几秒钟就完成。HEIC这个格式Windows上经常打不开,转成JPEG就省事多了。

HEIC格式的文件转换就很快,而且支持批量转换,那就很nice了,转换完还能直接在上面预览。

第三个是视频抽音频。一个MP4文件转成MP3。FFmpeg引擎干活很快,一个两分钟的视频,几秒就转完了,音频质量正常。

多个转换任务的话它还会自己排队。

第四个是批量转换。我一次拖了十几张图片进去,全部转成WebP。批量任务会排队执行,完成一个显示一个,进度一目了然。批量处理这个功能对整理素材库很实用,不用一张一张转。

整个转换过程全部在本地完成,文件没有离开我的NAS。从上传到下载,数据的路径是NAS内部,安全性比在线转换网站踏实得多。
七、资源占用
运行一周下来观察了一下资源占用。
CPU平时几乎不占,转换任务执行的时候会起来。图片和文档转换负载很低,视频转换的时候负载会明显上去,因为FFmpeg是计算密集型的。转换结束后CPU占用立刻回落。
内存占用很稳定,ConvertX本身是个轻量服务,不转换的时候占用的内存非常少。比起RAGFlow那套五六个容器动辄十几个GB内存的吃法,ConvertX对NAS来说几乎是无感的。
磁盘方面,转换产生的文件都存在挂载的数据目录里。注意一点,转换任务会保留中间文件和输出文件,用的时间长了要定期清理一下,或者看看有没有自动清理的配置项,避免数据目录越堆越大。
八、踩坑记录
坑一,端口冲突。 第一次部署的时候没注意,直接用了3000:3000,结果我的NAS上3000端口已经被别的服务占用了,容器起来但访问不到。解决办法是把端口改成3014:3000,重新创建容器就好了。
坑二,JWT_SECRET太简单。 如果出现注册后无法保持登录、反复跳回登录页等情况,先检查访问方式。如果使用内网IP+端口访问,需要在可信局域网环境下设置 HTTP_ALLOWED=true;如果通过 HTTPS 访问,则应保持为 false。
坑三,转换中文文件名乱码。 有一次传了一个中文文件名的文档,转换完成后下载的文件名变成了乱码。把文件名改成拼音或者英文再传就正常了。不知道是容器编码的问题还是文件系统的问题,临时用改名绕过去了。
坑四,大视频转换时间长。 传了一个比较大的视频文件转格式,转换时间比预想的长很多,中间一度以为卡住了。实际是FFmpeg在正常干活,耐心等就行。NAS的CPU性能决定了大文件转换的速度,想要更快只能换更强的设备。
九、总结
ConvertX这个项目解决了一个很实际的问题。文件格式转换这个需求,每个人都会遇到,但大多数人都在用在线服务,把文件交给第三方。ConvertX把这件小事拿回了自己手里,部署简单,界面干净,格式覆盖广,转换质量过关。

如果你在NAS上跑Docker,装一个ConvertX的成本很低,Container Station里粘贴一段配置就能搞定。装完之后,图片、文档、视频、音频、电子书这些格式转换需求都可以在本地解决。文件不上传第三方,转换结果直接存在自己硬盘上,隐私和便利都拿到了。
比起我NAS上跑的其他服务,ConvertX是部署最轻松、日常使用频率又很高的一个。文件转换这个需求虽然不起眼,但私有化之后,数据安全这块就再也不用操心了。接下来我打算把团队共享的场景也测一下,开几个子账户给同事用,看看多账户管理的体验怎么样,有结果再更新。

