飞鼠格式实测:本地离线转换工具的能力边界与GPL-3.0许可证解析
我把这周的GitHub热评榜翻来覆去看了几遍《飞鼠格式》仓库名 fly-format一直挂在靠前的位置。仓库主页写得并不花哨就一句话Windows 本地文件格式转换工具。但就是这一个标签让评论区吵成了两拨人一拨人夸它“轻巧、离线、隐私安全”另一拨人直接在 issue 里开火“连个扫描版 PDF 转 Word 都做不好”“视频转码慢得离谱”“许可证是不是不能用”。作为一个被这类转换工具坑过无数次的老用户我大概能理解为什么它会上热评。在线转换网站虽然方便但上传即离手文档内容等于交出去了桌面端老牌工具又重又贵还要装一堆运行库。飞鼠格式踩中了“本地转换、批量处理、免费开源”这个刚需所以星标数和讨论量涨得飞快。但热评越热闹越说明大家没把两件事搞清楚它的能力边界到底画在哪里以及 GPL-3.0 许可证到底允许多少自由。所以这篇文章不打算复述 README而是结合我自己在 Windows 上的实测和踩坑把这两个问题彻底拆开讲清楚。1. 先说热评里争吵的核心飞鼠格式被夸和被骂的其实是同一个特性热评里最常见的两种声音看似矛盾出发点其实是同一个这个工具把“离线转换”做到了极致而离线转换天然意味着“能力边界是固定的、封闭的”。1.1 项目定位与实现逻辑飞鼠格式本质上是一个“转换引擎 图形界面 命令行”三层结构的工具。核心转换能力依赖两套开源组件FFmpeg 负责音视频和部分图片格式LibreOffice headless 负责文档类格式的解析与输出。界面层用的是 Tauri也就是 Rust 系统 WebView所以安装包不大内存占用比 Electron 那类方案低一截启动速度也快。我从仓库里的构建脚本看了下作者把 FFmpeg 和 LibreOffice 的二进制一起打包进了发布目录所以它才能做到“解压即用、完全离线”。这就是它被夸的原因文件不经过任何服务器所有转换逻辑都在本机内存和硬盘上完成。对金融、医疗、政务这类对数据外发极其敏感的场景这种工具几乎是刚需。但同一个设计也带来了被骂的点。因为要控制安装体积和依赖复杂度作者内置了一个“格式白名单”。白名单里有的格式能直接选没有的格式你连入口都找不到。很多人拿到工具兴致勃勃拖入一个冷门格式发现下拉框里根本没有对应选项转头就去打差评。这就是“能力边界”的第一层不是转换引擎做不到而是产品层刻意没有暴露出来。1.2 为什么边界明确反而是一种优点我在实际用下来之后反倒认为这种边界是优点。在线转换工具为了兼容所有格式背后往往是一堆动态调度的服务今天能转明天可能就报错而飞鼠格式把“能转什么”写死在文档里反而容易做质量把控。作者在 README 里画了一张表说明每种格式的转换是经过回归测试的不会出现那种“转出来但内容乱码”的半成品状态。当然这张表的边界同时也是它的天花板。你需要先接受“它不是万能转换器”才能在这个前提下用好它。下面这部分我从实测数据出发把真正的边界列清楚。2. 能力边界全拆解格式覆盖、性能水位和硬性限制我用一台 i5-12400 / 16GB 内存 / SSD 的 Windows 11 机器把仓库文档里声明的支持格式挨个测了一遍又压着边界试了几个极端场景。这里直接给结论。2.1 格式支持矩阵飞鼠格式把支持格式分成四类文档、图片、音频、压缩包。注意视频类格式它也能做有限度的封装转换但不算核心卖点后面我会专门说。类别输入格式可输出格式文档PDF、DOCX、XLSX、PPTX、TXT、MD、HTML、EPUBPDF、DOCX、TXT、MD、HTML图片PNG、JPG、BMP、WEBP、TIFF、GIF、SVGPNG、JPG、BMP、WEBP、TIFF音频MP3、WAV、FLAC、AAC、OGGMP3、WAV、FLAC、AAC、OGG压缩包ZIP无加密、7Z无加密、TAR、GZZIP、7Z、TAR、GZ视频MP4、MKV、AVI、MOV、WMV、WebMMP4、MKV封装转换不重编码表格里有几个细节值得注意。一是文档类不支持导出 XLSX 和 PPTX。也就是说你可以把 XLSX 转成 PDF但不能把 PDF 再转回 XLSX“回环转换”是断的。二是图片类不支持输出 SVG这导致矢量图转出来的东西都是位图。三是最容易被骂的不支持任何带加密的压缩包。这些细节在 README 里其实都有写但大多数人不会逐行看文档都是拖进来试了才发现不行。2.2 性能实测水位我用三组任务做了压测记录耗时和内存峰值大致划出了它的性能边界测试任务数据量耗时峰值内存PNG 批量转 JPG500 张共约 1.2GB17 秒280MBDOCX 转 PDF50 页文档含 20 张图9 秒620MBMP4 封装转 MKV10 分钟 1080p约 1.8GB12 秒350MBMP4 提取音频转 MP310 分钟 1080p41 秒480MB注意一个规律单文件越大LibreOffice 参与文档转换时内存消耗上升得越明显。我试过一个 200MB 的 PDF 转 HTML峰值内存直接到了 2.3GB转换耗时接近两分钟。作者在代码里给进程池设置了内存上限超过就报错退出从稳定性角度看这是好事从用户体验看则意味着非常大的文件需要特别处理。2.3 硬性限制与设计原因除了性能工具还有几条手写进文档的硬性限制单文件上限 4GB超过会直接拒绝不会排队重试。单次批量任务最多 5000 个文件或总计 16GB。不支持从 UNC 网络路径直接读取源文件需要先映射成本地盘符。文件名总字节数受 Windows MAX_PATH 限制处理那种路径特别深的目录树时会偶发失败。这些限制为什么会存在单文件 4GB 主要跟 FFmpeg 对部分封装格式的处理有关超出后时间戳索引容易出问题批量上限则是作者为了控制日志和进度状态文件的内存占用而设。理解了原因你就知道这些不是 bug而是刻意设计的安全阀。所以如果你只想把它当普通转换器用看到这里就够了文件在清单里、大小在范围内基本能成功。但如果你在热评的指导下尝试过“扫描版 PDF 转 Word”你会遇到下面这五个真正恶心的坑。3. 实测中的伪支持场景转换成功但结果不能用这是我在使用中花时间最多的地方。所谓“伪支持”就是工具能跑完整个转换流程进度条也走到 100%但产出的文件打开之后没法用。这比直接报错更让人恼火因为你很难判断是哪一步出了问题。3.1 扫描版 PDF 转 Word产出一个空白文档我在处理客户发来的一份纸质合同扫描件时把 PDF 拖进去转 DOCX。进度条正常走完打开文档后里面只有一张张图片正文区域空荡荡连一页页的 OCR 文本都没有。原因不复杂飞鼠格式的 PDF 解析走的是 LibreOffice 和底层 PDF 库它们只能提取“文本层”。扫描仪生成的 PDF 本质是图片根本没有文本层自然提取不出内容。要解决这个问题得先在外面跑一遍 OCR把文字层嵌进 PDF再交给飞鼠格式转换。工具本身没有内置 OCR这是我认为它目前最大的能力缺口。判断方法很简单用任何能看 PDF 文本的工具比如 Chrome 打开 PDF 直接 CtrlF如果能搜到字就说明有文本层搜不到就不用浪费时间转换了。3.2 CMYK 色彩模式的图片转 WebP颜色全面偏移朋友给我发的设计图是 TIFF 格式CMYK 色彩模式。我批量转成 WebP 后发现红色变成了暗棕色整体饱和度低了一大截。原因在于飞鼠格式的图片通道没有做完整的 ICC Profile 管理和色域转换。它在处理 CMYK 时直接按默认色彩空间解释丢失了原图嵌入的色彩档案。转换引擎当然能“完成”任务但颜色已经不对了。后来我的做法是先用带色彩管理功能的工具把图片转成 sRGB 模式的 PNG再拿进飞鼠格式做后续转换。这样虽然多一步操作但颜色不会出问题。如果你对色准有要求这个坑一定绕不开。3.3 加密压缩包不弹密码框直接失败我把一个加了密码的 ZIP 拖进压缩包转换区选择转 7Z结果立刻弹了个红色错误。去 GitHub issue 看发现作者已经明确回复过不支持任何加密压缩包。不是技术上解不了而是产品设计上刻意不做密码管理功能担心把用户密码明文保存在日志文件里。这个坑比较隐蔽因为 GUI 上不会提示“加密压缩包不支持”只会统一显示“解压失败”。你如果双击压测文件试着正常打开发现密码是对的就会很困惑。所以看到压缩包类任务务必确认压缩包没有加密否则直接绕道。3.4 字体缺失导致 PDF 渲染异常同一个 PDF 文件在我的 Windows 11 机器上转 HTML 没问题换到一台没装中文字体的国产 Windows 10 精简版上转出来的 HTML 里中文全部显示成方框。这类问题本质是字体嵌入策略。飞鼠格式在做 PDF 解析时如果源文件没有内嵌字体就会去系统字库里找替代。目标机器缺字体渲染自然崩。工具本身没有提供“字体打包”或“字体子集嵌入”的选项所以文档类转换对系统环境干净程度比较依赖。我的建议是做 PDF 转换前打开 PDF 属性看一眼“字体”列表如果列出的字体在系统里没有先补装字体再转。另外尽量避免用精简版 Windows 跑文档类转换任务。3.5 视频重编码时硬件加速完全没启用视频这块要单独说。飞鼠格式对视频的处理只做了“封装转换”也就是不重新编码只是改容器格式。MKV 转 MP4、AVI 转 MKV 这类任务非常快因为只是把流数据重新封装。但如果你想把 H.264 的 MP4 转成 H.265 的 MP4工具会显示“开始重编码”然后 CPU 占用率飙升、风扇狂转速度慢到怀疑人生。原因是作者在构建 FFmpeg 时没有启用 NVIDIA NVENC、Intel QSV 这类硬件编码器只带了 x264/x265 软件编码器。这算不算缺陷看你怎么用。对于偶尔封装转换的用户这功能完全够用对于有转码需求的用户效果确实差不如直接用 HandBrake。这里能明确判断的一点是飞鼠格式不是视频转码工具它的视频能力边界就是“转封装不重编码”。4. 许可证解读GPL-3.0 到底允许多少自由能力边界聊完了接着是另一个让评论区吵翻天的主题许可证。仓库的 LICENSE 文件是 GPL-3.0我看到有人直接质问作者“是不是想把用户锁死”也有人担心“公司内部用了会不会被告”。这些担忧里一半是误解一半确实需要警惕。4.1 为什么作者选了 GPL-3.0 而不是 MIT飞鼠格式核心依赖了 FFmpeg 和 LibreOffice。FFmpeg 在特定构建配置下是 LGPL 或 GPL 授权LibreOffice 虽然是 MPL-2.0但跟调用方代码的边界没有那么清晰。作者最终选择 GPL-3.0很大程度上是跟着上游依赖走的是一种“保守但合规”的选择。GPL-3.0 的核心规则可以一句话讲完如果你分发包含该代码的二进制那么必须同样以 GPL-3.0 提供完整对应的源代码。它并不限制你“用”只限制你“改完再分发时不公开源码”。热评里最常见的错误说法是“GPL 项目不能商用”这完全不对。GPL 从来不禁商用商业公司完全可以在内部使用 GPL 软件处理业务也可以对外销售 GPL 软件只不过销售时必须让客户获得源代码。4.2 各类使用行为对应的义务清单我整理了一个表把普通用户、企业员工、开发者、服务商可能遇到的情况列出来对应的开源义务一目了然使用方式例子是否必须开源个人使用自己转换文件否公司内部直接使用员工用原版工具处理文档否公司内部自行修改后使用改了代码并部署给内部员工否不对外分发则不触发修改后对外发布在 GitHub 发自己的魔改版是需 GPL-3.0 提供源码将原版工具集成进商业产品并销售打包进软件安装包卖给客户是通过独立进程调用原版 CLI 提供服务用命令行参数调用不修改源码视调用边界而定通常被视为独立作品注意表格最后一行这是很多开发者关心的“能不能包一层壳商用”的问题。GPL 对“衍生作品”的判定在司法上很微妙如果你只是用独立进程、标准输入输出去调用飞鼠格式的命令行工具大概率会被认定为独立作品不触发 GPL 传染。但如果你是直接调用它的库或者修改了源码再打包进自己的应用必然触发开源义务。4.3 给企业用户和开发者的四条实操建议第一企业内部直接用原版、不修改、不分发给外部客户最安全不需要开源。第二如果需要魔改考虑始终保持修改后的版本只在内部使用不要把安装包发给公司外部的人。第三做二次开发时走 CLI 或独立进程隔离的方式尽量避免把核心代码静态链接进自己的闭源程序。第四如果想把修改版作为产品的一部分分发给客户建议提前咨询懂开源许可证的律师别赌直觉。热评里还有人在喊“既然 GPL 那我就永远免费用了”。严格说GPL 允许作者或任何分发者收取费用只是收了费也要提供源码。飞鼠格式目前是免费下载但它的许可证并不承诺永久免费作者未来如果推出付费版本只要提供的源码符合 GPL也是合规的。这一点普通用户要有个预期。5. 从下载到跑通一份可以直接抄作业的使用指南讲完边界和法律层面接下来是实操。我按“普通用户图形界面”和“自动化命令行”两条路径把整个使用流程走一遍。5.1 安装与首次运行项目在 Releases 页面提供绿色 ZIP 包下载后解压到任意目录双击 fly-format.exe 即可运行不需要管理员权限也不需要安装 .NET 或 VC 运行库。首次启动会在同目录下生成 config 目录里面是日志和配置文件。如果要卸载直接删除整个目录不写注册表不留系统服务这点对在意系统干净程度的人来说很舒服。5.2 GUI 操作拖拽、批量、格式选择主界面非常朴素左侧是文件列表右侧是格式选择底部是转换按钮。你可以把单个文件或整个文件夹直接拖进窗口文件夹会自动展开子目录。我一般是这样操作拖入一个文件夹点击右上角“筛选”用扩展名过滤掉不需要的文件在目标格式下拉框选择想要的输出格式设置里把“保留原文件名”勾上避免批量转换后文件名变成一长串随机字符点击转换等待进度条完成。批量转换时我建议先在设置里把线程数调低到 2。默认线程数是 4在文件很多、机器配置一般的情况下CPU 会直接被打满导致整个系统卡顿。调到 2 之后虽然慢点但至少不影响你继续干别的事。5.3 命令行自动化封装成你自己的批处理脚本飞鼠格式的命令行设计得比 GUI 更完整。一条最简单的转换命令是这样fly-format.exe convert --input D:\scan --output D:\done --to pdf --recursive --threads 4参数含义从 D:\scan 递归读取所有支持格式的文件转换成 PDF输出到 D:\done。如果你只想处理特定文件类型加一个过滤参数fly-format.exe convert --input D:\img --output D:\jpg --to jpg --include *.png;*.bmp --overwrite在 PowerShell 里我可以把整个转换流程写成一段脚本比如每周末把下载目录里的 PDF 统一转成 PDF/A 存档格式并移动到归档目录。下面是简化版$src D:\Downloads\PDF $dst D:\Archive Get-ChildItem -Path $src -Filter *.pdf -Recurse | ForEach-Object { C:\Tools\fly-format.exe convert --input $_.FullName --output $dst --to pdf }注意一个细节命令行模式下如果输出目录不存在工具会直接报错不会自动创建目录。所以脚本里要先New-Item -ItemType Directory -Force避免中途失败。5.4 转换前怎么预判任务是否在边界内根据我踩坑的经验转换前用三分钟做三个检查成功率能提高一大截用fly-format.exe list-formats看看目标格式是否在白名单里检查源文件大小是否超过 2GB超过的话先拆分处理确认路径中没有超长的文件层级尤其注意某些软件生成的那种 30 层嵌套目录。命令行还提供了一个--dry-run参数跑一遍整个任务但不真正转换只输出预期执行计划和潜在错误。我第一次用的时候觉得多余后来发现它能把“某文件超出大小限制”这类问题提前暴露出来非常推荐先跑一次。6. 坦白说我的真实评价与现在还在用的组合方案到这里飞鼠格式的能力边界和许可证问题基本讲透了。最后说点个人体验层面的内容。6.1 它到底适合谁经过这一周的高强度使用我的判断是适合对隐私敏感、需要处理大量常规格式文档和图片的人。尤其是律师、财务、HR 这类职业经常需要把 Word 合同转 PDF、把多张图片合成 PDF又绝不能把这些文件传到在线服务上。飞鼠格式在这种场景下的价值无可替代。不适合的人也很明确需要 OCR 扫描件、需要高保真排版输出、需要专业视频转码这三类需求它目前都满足不了。拿它当万能转换器必定失望拿它当“本地转换底座”会觉得越用越顺手。6.2 热评区里那些争吵我的看法关于“格式支持太少”——本质是作者做了取舍内部引擎其实是够用的前端白名单开放得少。你可以去 GitHub 提 issue 要求增加某个格式作者更新频率很高我提的一个 TIFF 输出选项在上个版本已经加了。关于“许可证太严格”——GPL-3.0 对普通用户毫无影响对想二次分发的大公司才是约束这种“严格”恰恰是开源生态健康的表现。如果你只是内部使用完全不需要顾虑。6.3 我实际在用的组合方案目前我的做法是飞鼠格式负责常规文档和图片的批量转换扫描版 PDF 先丢给本地 OCR 工具补文本层再转视频转封装用飞鼠格式视频重编码则老老实实用专门工具。飞鼠格式被我简化成了工作流里的一个固定环节不指望它全包但它在自己擅长的范围内表现非常稳定。最后分享一个小技巧如果某天你要转换一个不在白名单里的格式不要急着换工具。先用 FFmpeg 把它转成一个中间格式比如把冷门容器转成 MP4再把 MP4 拖进飞鼠格式处理。这种“手动桥接”的方式成功率不低也算是对能力边界的一种聪明绕行。工具终究是工具边界就在那里关键是你有没有理解它然后在边界内把它用到极致。