格式转换器长期规划（能力版图与转换路线）

状态：长期规划未完成；八个能力区已交付首轮功能（2026-10-09）。 编写日期：2026-10-08；校对日期：2026-10-12（Asia/Shanghai）。当前进度与待办见 §16。 本文回答「最后可以变成什么样、包含哪些格式、每类具体怎么转换」。 首轮交付、原始实施建议与验收缺口另见 docs/format-converter-implementation.md。 ⚠️ 本文仍是路线图，不是支持清单：已实施的范围以能力登记表为准 （src/lib/file-converter/ 的边，status: 'live' 才出现在页面菜单里； 见 docs/architecture.md §6.17）。登记表当前只有两条 planned 边： office:html-print-pdf / office:docx-to-pdf，不进菜单；其他长期候选未必已登记。 判断「现在到底能不能转 X」，看工具页面，不要照本文推。

1. 最终产品形态

长期目标是一个覆盖日常文件处理的站内工具：拖入文件，识别真实内容，提供合理的 转换目标，说明转换会改变什么，预览结果，再下载。 用户既能按「目标格式」操作， 也能按「我要在手机播放」「我要发到网页」「我要从 PDF 取文字」这类用途操作。

它可以发展成八个能力区，使用同一套文件选择、任务队列、参数预设、错误反馈与下载：

1. 图片：普通图片、手机照片、动画、图标，以及受控的矢量图光栅化。
2. 音频：兼容播放、压缩、无压缩编辑素材、换封装与视频中的音轨提取。
3. 视频：兼容格式、换封装、压缩、短片、动图与帧序列。
4. 文档与 PDF：Office 导出、网页与 Markdown 导出、图片成 PDF、PDF 页面和文字提取。
5. 表格与结构化数据：Excel / ODS / CSV / TSV / JSON / YAML / XML 的有规则转换。
6. 文本编码与字幕：解决乱码、转字符编码、换行与 SRT / VTT / ASS 字幕格式。
7. 电子书：EPUB 制作与提取，常见无保护电子书格式的兼容转换。
8. 压缩包：批量打包、解包、换压缩容器，以及包内文件的选择性转换。

典型终态体验：

• 拖入 HEIC，看到「转 JPG，便于分享」「转 PNG，保留解码后的像素」两种用途。
• 拖入 OGG，看到「MP3，广泛兼容」「M4A，小体积」「WAV，供编辑软件使用」。
• 拖入 MKV，先探测音视频编码，再判断能否直接换成 MP4，还是需要重编码。
• 拖入 PDF，提供「按页导出图片」「提取文字」「识别扫描页」「转可编辑文档」， 四种目标各自说明保真范围。
• 拖入 XLSX，先选择工作表，再决定输出显示值、原始值或公式文本。
• 批量转换同类文件，查看部分成功结果；可分别保存，也可打包 ZIP。

界面仍保持简单：默认给推荐目标与少量重要参数，展开「高级选项」才显示采样率、 像素格式、工作表映射等专业参数。不会把所有已安装引擎的格式直接堆成下拉列表。

2. 先区分六种不同的转换

长期工具需要把这些方式明示到结果说明中。换封装可以优先节省时间与避免重编码， 但只适用于目标容器兼容的流；不满足条件时要说明需重编码的轨道。 技术依据：FFmpeg 的 streamcopy 与转码

两条共通规则：

• 支持 A → B 不意味着支持 B → A，更不意味着可还原到原文件。
• 扩展名、容器和编码分别建模。例如 .ogg 可以装 Vorbis 或 Opus，.mp4 可以装 H.264 或 HEVC，.wav 也不保证里面一定是所选 PCM 规格。

3. 能力版图与优先级

下文用「基础目标」「扩展目标」「专项候选」表示产品建设优先级：

• 基础目标：日常用途明确，属于最值得持续建设的部分。
• 扩展目标：有成熟处理路线，但依赖更大引擎、特殊参数或更重的兼容性验收。
• 专项候选：成本或保真问题明显，按具体需求决定是否建设，不写成必做承诺。

优先级表示值得建设的方向；浏览器是否具备能力、所选二进制是否启用编码器，仍要 逐项验证。后续章节给出每个方向的处理方法和不能省略的参数。

4. 图片转换：从普通图片到照片与动画

4.1 静态位图与图标

普通静态图优先沿用浏览器原生管线，再按需引入专用 WASM 编解码器。若未来采用 服务器模式，可复用 sharp 处理常见位图；其 HEIC 编码涉及带相应编解码支持的 libvips 配置，不能默认认为项目已有 sharp 安装包就能直接输出 HEIC。 技术依据：sharp 输出与 HEIF 配置、libheif 编解码组成

SVG 光栅化是转换器自己的受控流程，不放宽本站图床或评论 / 讨论的白名单。结果 输出普通位图；源 SVG 不在本站同源页面中作为可执行文档打开。复杂字体和滤镜 的表现需要样本验收。

4.2 动画与帧序列

动画不能直接复用首版「一张图进 Canvas」的实现。帧处置、混合、调色板和时长是 动画正确性的组成部分，至少要验收透明 GIF、局部更新帧、非等时长帧和循环次数。

4.3 产品上的三个图片预设

• 便于分享：HEIC / AVIF / WebP → JPG，按目标尺寸缩放，默认不携带原始位置元数据。
• 保留透明：可接受透明源 → PNG / 无损 WebP；选 JPG 时显示背景处理。
• 网页小图：普通图片 → WebP / AVIF，限制宽度与质量，显示实际体积和输出预览。

PNG → SVG 的矢量描摹不归入普通互转。把 PNG 嵌进 SVG 容器仍是位图；真正的描摹 要推断轮廓与颜色，可能改变细节。若建设，名称和结果必须区别于 SVG 光栅化。

5. 音频转换：编码、封装与用途分别选择

5.1 常见输出的真实含义

5.2 转换方向与步骤

通用音频以 FFmpeg 适配层为主，轻量原生 / WebCodecs / 专用 WASM 路线作为经验证的 同方向替代。安装了 FFmpeg 不代表启用了所有外部库；能力表从所选构建和样本得到。 技术依据：FFmpeg 格式与编码能力、FFmpeg 编解码器文档

5.3 长期参数与验收

高级选项逐步提供码率 / VBR、采样率、位深、声道和元数据策略，预设优先显示 「兼容播放」「小体积语音」「编辑用 WAV」「保留 PCM 的无损输出」。

目标体积可用于估计或有限次尝试，不能保证任意内容在固定体积下都达到相同质量。 验收除能播放外，还要检查时长、开头 / 末尾是否截断、音高、声道顺序和采样率。 无损方向在规格一致时比较解码样本；有损方向采用容差与合成音调样本。

音频剪辑、拼接、响度归一化可以后续作为转换选项增加，但会改变内容，任务说明中 要与「仅转换格式」区别。转成 MP3 本身不意味着必须调整响度或裁掉静音。

6. 视频转换：优先辨认容器和编码

6.1 常见目标组合

兼容预设优先采用明确的编码组合。所谓「MP4 格式」不足以保证某台设备能播放： 里面的编码、profile、level、像素格式、位深和音轨都可能影响结果。

6.2 转换方向与步骤

音视频容器、轨道映射和封装条件以 FFmpeg 的格式 / 流处理能力为技术基础，所选 浏览器构建的实际支持集合可能小于原生版本。用 WebCodecs / Mediabunny 加速时， 仍保留相同的转换契约与参数，不根据某台机器的硬件能力扩大对所有用户的承诺。 技术依据：FFmpeg 格式、码流与轨道处理

6.3 三个具体决策例子

1. MKV 内为 H.264 + AAC，用户要 MP4：先验证目标封装与时间信息；合格时换封装， 不解码重编码，结果说明写「音视频编码保持」。若有不支持的字幕，单独导出或由 用户明确选择忽略，不能静默少一条轨道。
2. MKV 内为 H.264 + 不兼容音频，用户要通用 MP4：视频可以复制，音频转 AAC。 结果说明「视频保持，音频重新编码」，不能把整个结果标为完全无损。
3. MOV 内为 HEVC HDR，用户要老设备可播放：转 H.264、选兼容像素格式，并按选定 色彩方案把 HDR 映射为 SDR。保留旋转、画面比例和所选音轨，不能直接改后缀。

6.4 大文件模式

短视频先尝试本地处理。长视频的资源限制按时长、分辨率、帧率、编码与目标一起 决定，不能只按文件字节数。浏览器能读取一个 2 GB 文件，不代表能在内存中转码它。

高级阶段可研究流式本地读写、只换封装的低成本路径，或由用户主动选择服务器 模式。服务器模式单独标明文件会上传；不能在本地失败后自动上传以「优化体验」。

7. 文档与 PDF：导出、提取和重建分开

7.1 Office 与标记文档

Office 格式的主要候选是 LibreOffice 的受控无界面转换；标记文档的主要候选是 Pandoc，按它实际支持的 reader / writer 建立方向表。Pandoc 的文档树转换与 Office 排版不同，不能把它当作复杂 Word 页面原样还原工具。 技术依据：LibreOffice 过滤器、Pandoc 输入输出与 PDF 引擎

HTML → PDF 的候选包括受控的无界面浏览器；它需要独立的服务端运行环境与字体。 浏览器本地「打印并由用户保存 PDF」可以作为早期替代，但应标为手动打印流程， 不能假装已能直接生成下载文件。

普通用户文件里的 Markdown 先按普通 Markdown 解析，不自动解引用本站的特殊 内容 token。未来若提供「站内文章导出」，明确选取站内来源，沿用当前用户的读取 权限与现有渲染管线，并独立说明资源是否随结果打包，不能混进普通文件转换。

7.2 PDF 与图片、文字

浏览器 PDF 渲染可使用 PDF.js，图片嵌入与简单 PDF 创建 / 修改可研究 pdf-lib。 OCR 可研究 Tesseract.js，但它自身不直接接收 PDF，需要先得到页面图像。OCR 返回文字也不等于已经完成 Word 布局重建或生成可搜索 PDF。 技术依据：PDF.js 渲染、pdf-lib、Tesseract.js 范围

7.3 PDF 操作如何归入同一工具

PDF 合并、拆分、重新排序、旋转和选页不是格式变化，但可复用相同页面和任务 模型，归入「PDF 处理」子面板。真正的 PDF 压缩可能重编码其中的图片，也可能只 重写结构；必须说明采取的方式、是否改变图像质量以及实际压缩结果。

保留原图像的 PDF → 图片型 Word，与重建可编辑段落的 PDF → Word 是两项能力。 不能先做了前者，就把菜单写成无条件支持「PDF 转 Word」。数字签名、交互表单、 注释与附件也不能因为显示的页面相同就宣称全部保留。

8. 表格与结构化数据：先明确映射规则

8.1 工作簿与表格文件

轻量数据转换可研究 SheetJS 等工作簿读写库，它们提供多种文件读写和行列映射。 CSV / TSV 只有一张二维表，不容纳工作簿的多页、图表和完整样式，不能让它们 静默消失而仍显示「完整保留」。复杂文档保真需要另一套验收策略。 技术依据：SheetJS 文件格式、输出约束

公式文本和计算结果是两种数据。基础 JS 读写库不应被当成完整的 Excel 计算引擎； 缓存结果可能陈旧。用户选择「导出显示值」「导出公式文本」或「由指定引擎重新 计算后导出」，结果报告哪一种发生了。 技术依据：SheetJS 公式与计算范围

8.2 JSON、YAML、XML 与行式数据

JSON → XML 不存在一个适合所有业务的天然映射。工具提供固定、可预览的规则， 只有在同一规则内才讨论可逆；不能宣称任意 XML 与 JSON 都能无损互转。 JSON 大整数也不能先经过丢精度的普通 Number 再输出；必要时按精确数值或字符串处理。

8.3 用户可理解的预览

先显示前若干行和推断类型：例如账号 00123 是文本，金额是数值，日期是明确 格式的日期。用户可以改列类型再转换，避免前导零、长订单号和跨地区日期含义改变。

导出 CSV 时区分精确保留数据与适合表格软件直接打开的策略；若兼容策略对疑似 公式单元格加前缀，必须说明这个变换，不暗中改掉原数据。转换器本身不执行导入 文件的宏、脚本或外部链接。

9. 文本编码与字幕

9.1 字符编码与普通文本

浏览器 TextEncoder 只提供 UTF-8 编码输出；其他目标编码需要经过验证的编码库， 例如研究 iconv-lite 的浏览器适配或专用 WASM。编码探测是候选判断，预览、允许 用户指定源编码和不可编码字符报告，才是解决乱码的必要功能。 技术依据：TextEncoder、iconv-lite 编码范围

本站已有 Base、Hex、URL、HTML 编码工具。文件转换器可链接到这些工具，但不重复 实现另一套不同口径的 Base64 / HTML 转义。把文件编码成 Base64 属于数据表示， 不会把其媒体格式从 JPG 变成 PNG。

9.2 字幕转换

普通字幕转换可用受限解析器 / writer；容器内字幕提取可复用 FFmpeg 的轨道探测。 字幕「烧录进视频」是渲染字幕再重新编码视频，「外挂字幕格式互转」是文本轨 转换，两者在菜单中分开，不因支持 SRT 就宣称能任意抽取画面里的字幕。

10. 电子书：内容重排与阅读器兼容

EPUB 制作可研究 Pandoc，已有电子书格式兼容可研究 Calibre 的 ebook-convert。 输入与输出支持是两个方向的能力，需要检查所选版本的插件与参数；不预先把 所有 ebook 后缀列为双向支持。 技术依据：Pandoc EPUB、Calibre 转换入口

正文重排可以改善手机阅读，但也可能改变段落、脚注、公式和图片位置。电子书 验收使用至少一种阅读器打开，检查章节顺序、目录、封面、链接与中文字符； 能解开 ZIP 容器不等于生成了正确的 EPUB。

11. 压缩包：保持包内内容再换容器

11.1 常见方向

ZIP 浏览器处理可研究 zip.js；更广的包格式可研究经裁剪的 WASM 或受控服务器 7-Zip。7-Zip 的格式表将 RAR 列为解包能力，不能由「能读 RAR」推导出「能写 RAR」。 技术依据：zip.js、7-Zip 格式范围

11.2 包处理自己的正确性边界

转换前显示成员数量、总解压体积和目录结构。还必须限制实际解压量、成员数量、 嵌套深度和压缩比；仅检查外层 ZIP 很小不足以控制成本。首批不递归展开包内包。

浏览器只在受控内存 / 本地临时环境处理成员；服务器解包不得让包内路径越出任务 目录。绝对路径、上级目录、链接、重名和不支持的加密有固定处理规则。原文件内容 用校验值验证，成员权限、时间和加密有变化时写进结果报告。

加密包由用户主动提供密码后处理，密码不存任务历史或日志。分卷需要用户同时 选齐文件再执行；遇到缺卷、错误密码或损坏包，不能导出一个少文件的「成功」包。

12. 统一架构：转换能力是一张有方向的图

12.1 格式与能力登记

建议在现有客户端词表之上逐步形成一份能力登记表，每条可执行转换记录：

识别输入后，只展示这张有方向的图里满足条件的目标。不存在的边不靠改后缀补上， 也不随意拼一条会丢失内容的长链路。例如 PDF → PNG → OCR → Word 有明显损失， 只能作为明确命名的重建方案，不作为隐藏的 PDF → Word 默认实现。

12.2 引擎分工

这里列的是职责和候选，不要求安装全部引擎。每增加一项，先核对许可、实际能力、 下载体积与维护成本，再由方向登记表引用。页首不一次加载全部库或 OCR 语言数据。

12.3 本地与服务器模式的产品契约

本地模式继续匿名可用，默认不上传文件。服务器模式只有在明确有需求、资源方案 和部署条件时建设，操作按钮明确写出「上传并转换」，用户知道处理位置。 不因本地失败而悄悄上传，也不因某种格式只能服务器处理而继续写「文件从不上传」。

服务器路线沿用本站唯一 Next 部署单元与统一调度，可按需调用受控的本机二进制 子进程；这属于新的运行时依赖与资源模型，不能把当前进程内架构说明原样当作已 满足要求。没有必要预先拆微服务，也不默认引入外部付费转换 API。

上线服务器模式前，要设计独立的排队、并发 / CPU / 内存 / 超时、断开后的任务状态、 访问控制、结果领取和临时数据生命周期。转换子进程不在 SQLite 事务里运行。 任务业务记录遵循本站软删除；临时文件与永久用户内容分开定义，不能让转换结果 默认进入图床或音频床，也不能把现有永久存储目录当临时工作目录。

如果设置账号档位，页面与接口各自执行同一档位判定，入口依本站约定处理。 是否登录、配额与收费不在本规划锁死；这些是服务器资源方案里的独立产品决定。

12.4 可组合工作流

长期可在转换任务上增加「配方」：用户先看见每一步，再执行有界的流程。例如：

一组 HEIC → JPG（统一宽度与背景）→ 按原名编号 → ZIP
视频 → 选一条音轨 → MP3 → 下载
多张照片 → 按用户顺序 → A4 PDF → 下载
扫描 PDF → 选择页码 → 页面图 → 中文 OCR → 可校对 TXT
XLSX → 选工作表 → 按列类型映射 → JSONL → GZIP
EPUB → 读取章节顺序 → Markdown + 图片资源包 → ZIP

配方复用已验收的转换边，并计算累计资源和损失；中间结果按生命周期回收。 首批提供固定配方即可，不建设任意脚本执行器或无限工作流编辑器。

13. 建设阶段：逐步到达长期形态

阶段表示依赖与投入顺序，不是年份或固定上线月份。R2 / R3 里的单项能力可按实际 需求调整先后；无需等整个阶段结束才能交付一个经过验证的转换方向。

长期目标建议先到达 R3 的多数日常能力，形成一个真正好用的本地文件工具集。 R4 / R5 按本站资源与真实使用需求建设，避免为了格式数量堆上长期无人维护的引擎。 总工作量应按每条转换方向与验收设备估算，不能沿用首版的 5–9 人日覆盖整个版图。

14. 具体用途预设与完整流程

这些预设组合已建设的能力，不是另起十三套转换代码。用户改目标格式或参数时， 预设名称随实际策略更新，不能仍显示「保留原质量」而实际已经重编码。

15. 长期承诺、限制与站内集成

15.1 可以长期坚持的承诺

• 能力清单来自真实通过的方向，精确到容器、编码、参数和运行模式。
• 小任务本地优先，位置与上传行为透明，用户能预览输出和看到损失说明。
• 支持批量、部分成功、取消与重试，各类别共用一套可靠的任务模型。
• 不将错误扩展名、非空结果或浏览器能预览当成唯一成功判据。
• 不默默改变文件语义：工作表、声道、动画、轨道、元数据和文字编码有固定规则。
• 已有工具、权限、图床 / 音频床配额与存储规则保持各自权威，不被转换器绕过。

15.2 不作无条件承诺的能力

15.3 与本站其他能力协作

后续可以在用户主动选择时，将合格转换结果交给本站图床 / 音频床，或生成适合 博客编辑器插入的文件；上传仍调用既有接口、按角色与配额执行。转换器能生成 某个格式，不代表图床 / 音频床就必须接受该格式。相关契约见 docs/architecture.md §6.6/§6.15。

站内编辑器导出、图片 / 音频资源选择和普通文件转换共用底层能力，但保留用途 边界。后台重任务的引入要遵循 SQLite 事务和单部署单元约束，不能为本规划恢复 已删除的其他框架实现。

15.4 持续更新方式

本规划是能力地图，首轮实施记录保存原始步骤与交付证据。实际开发后逐项登记：已支持 方向、引擎 / 构建、目标设备、验证样本、损失说明与已知限制，再修改用户可见菜单。 上线一类能力时增加相应指南与故障排查，按 docs/README.md 的规则登记与互指。

技术依据以本文链接的官方文档为主，选型时核对所选版本的代码、许可与构建； 不把上游原生程序的全部支持列表照搬成本站浏览器构建的菜单，也不把这些候选 链接当成已经安装的依赖。

16. 当前进度与剩余工作（2026-10-12 校对）

16.1 已交付的基线

八个能力区与共享任务队列已经存在，能力定义在 src/lib/file-converter/categories/， 聚合入口为 categories/index.ts，可用性由 registry.ts 按状态与设备能力过滤。 图片缩放与更多格式、更多音频输出、视频提音频、PDF 页面处理 / OCR、表格映射、 字幕与编码、简单 EPUB、压缩包与成功结果 ZIP 打包都已有实现；用途预设与固定配方 也已交付。它们不再作为从零建设的待办，具体方向与限制看登记表及 docs/guide/格式转换器使用指南.md。

§13 的 R1–R5 表保留为建设顺序，不是当前验收状态：R1 的功能已经交付，但原计划 真机与性能验收未完成；R2 / R3 / R5 均已有部分能力，不能按编号认为整阶段已完成。 R4 服务器转换尚未实施。原始范围、历史验证与偏差见 docs/format-converter-implementation.md §12.1/§12.2/§12.3。

16.2 未完成验收与已知功能缺口

以上验收缺口是对原计划的核对结果，并非宣称当前转换边都不可用。本次没有重跑引擎、 全量 e2e 或真机测试，也不将历史通过数当成当前版本的新证据。

16.3 可选候选与有意推迟项

• 轻量媒体引擎对比：Mediabunny 对比未做；如开展优化，应有界比较当前 FFmpeg 方案的实际样本、设备、载荷与行为，不把替换引擎当成既定结论。
• 登记表证据结构化：§12.1 的引擎版本与逐边验收证据尚未单独建字段；当前以 引擎文件头、锁文件、资产脚本和实施记录承载。这是有意推迟项，有维护需求再补。
• 高级图片 / 媒体：HEIC 输出、摄影 RAW、JPEG XL、专业色彩、HDR、多声道与复杂 编辑属于候选，不因已有八个标签页而算完成。
• 复杂文档 / 电子书重建：Office / EPUB 的服务器排版、可编辑 PDF 重建、旧阅读器 格式与专业布局按真实需求进入；OCR、图片型 DOCX / PPTX 与结构重建分别验收。
• 站内资源集成与多步流程：§15.3 的图床 / 音频床上传集成及 §12.4 超出现有 「转换 + 打包」的多步配方仍为候选，需单独确认范围和资源生命周期。

开展服务器候选前按 §12.3 设计上传契约、统一调度、并发与临时数据生命周期； 不改变单部署单元与 SQLite 事务内不得进行 HTTP 的约束。候选不是排期，实施后再登记 具体通过的方向、设备与限制。