ORBF：参考板开放交换格式，解决创意素材跨平台迁移难题

为什么参考板需要一个开放格式

参考板（reference-board）应用在创意工作者中广泛使用——设计师、插画师、概念艺术家常用它们收集灵感图片、排布素材、添加笔记和链接。参考板的概念最早源自传统设计行业，设计师会在实体泡沫板或软木板上钉满剪报、布料样本、色卡和照片来建立视觉方向。进入数字时代后，这一工作流被 PureRef、Eagle、Milanote、Pinterest 等软件和服务所继承。目前市场上主流的参考板工具各有侧重——PureRef 免费轻量但仅限桌面端，Eagle 侧重素材管理，Figma/Miro 则从协作白板角度切入。这些工具的共同特征是支持自由画布布局、图片拖放、缩放平移以及基本的标注功能。

值得注意的是，这些工具在技术架构层面存在根本性差异。PureRef 使用 C++/Qt 构建，将画布状态序列化为自定义的 .pur 二进制文件；Eagle 采用 Electron 框架，以文件夹+JSON 元数据的方式管理素材库；Milanote 是纯 Web 应用，数据存储在云端数据库中。PureRef 使用的 Qt 框架是一个跨平台 C++ 应用开发框架，以其高性能的 2D 渲染引擎著称，适合需要流畅画布操作的工具。其 .pur 文件采用二进制序列化，虽然启动速度快，但完全不可人工阅读。Eagle 选择的 Electron 框架基于 Chromium 浏览器引擎和 Node.js，允许使用 Web 技术构建桌面应用，代价是更高的内存占用。Eagle 的文件夹+JSON 方案本质上是将每个素材作为独立文件存储，再用 metadata.json 记录标签、颜色标注等信息，这种设计虽然便于备份和版本控制，但素材库一旦膨胀到数万条目，JSON 解析和文件系统遍历的性能问题就会显现。这种架构层面的分裂——不仅是文件结构不同，连数据的存储哲学（本地文件 vs. 云端记录 vs. 混合模式）都截然不同——决定了格式统一的难度远超表面所见。

然而，一个长期困扰用户的问题是：这些参考板文件很难在不同应用之间迁移。

据一位 Reddit 开发者的提案，许多参考板应用采用私有或二进制格式，这意味着如果没有原始软件，文件内容既难以查看也难以恢复。所谓私有格式（Proprietary Format）是指文件的内部结构未公开文档化，通常采用二进制编码或加密方式存储，与之对立的是开放格式（Open Format），其规范完整公开，任何开发者都可以编写读写该格式的程序。数据锁定（Vendor Lock-in）在创意领域并非新问题——Adobe 的 PSD 格式曾长期面临类似争议，虽然逆向工程使得第三方工具能部分读取 PSD，但完整的图层效果、智能对象等高级特性仍然只有 Photoshop 能完全还原。数据锁定问题在创意软件史上反复出现：Macromedia FreeHand 的 .fh 格式在 Adobe 收购 Macromedia 后逐渐失去支持，大量设计师的历史文件变得难以打开；Quark XPress 的 .qxd 格式曾统治出版行业，但其封闭性最终被 Adobe InDesign 的更开放生态所击败；更近的案例是 Google 于 2022 年关闭 Stadia 云游戏服务，用户购买的游戏资产完全消失。这些案例共同说明：当用户的创作成果与特定软件深度绑定时，软件的商业命运直接决定了用户资产的生死。

结果就是用户被锁定在单一应用中——一旦软件停止维护、平台不兼容，或者协作伙伴使用不同系统，辛苦搭建的参考板就可能变成无法编辑的"死文件"。

这位开发者的动机非常现实：他为自己开发了一款 Apple 原生的参考板应用，因为他试用的几款应用都不支持 iPad；而他的朋友们有的只用 Windows，有的只用 Linux。三方虽然能交换原始图片，但要共享整个"参考板"，往往只能把它压平成一张图片，或者手动重建。压平的图片能看，但可编辑的布局、笔记、链接以及其他板面数据全都丢失了。

现有格式为何不够用

JSON Canvas 的局限性分析

在寻找解决方案时，作者发现最接近的现有格式是 JSON Canvas。这是一种描述画布上文件、文本、链接、分组及其位置的开放格式，最初由 Obsidian 团队推动。JSON Canvas（文件扩展名 .canvas）于 2024 年初正式开源，采用 MIT 许可证发布。其数据模型非常简洁：顶层是一个 JSON 对象，包含 nodes（节点数组）和 edges（连线数组）。每个 node 有 id、type、x、y、width、height 等属性，type 可以是 text、file、link 或 group；edges 则描述节点之间的连接关系，支持起止锚点和颜色属性。这种极简设计使得格式容易被第三方实现（目前已有数十个兼容应用），它的优点在于开放、可读、生态较广。

JSON Canvas 规范的诞生有其特定背景。Obsidian 是一款基于本地 Markdown 文件的知识管理工具，其"Canvas"功能允许用户在无限画布上组织笔记卡片并建立视觉连接。Obsidian 团队将 Canvas 格式开源的动机是强化其"数据属于用户"的品牌定位。目前兼容 JSON Canvas 的应用主要集中在知识管理和思维导图领域，如 Kinopio、Scrintal 等，而非视觉创作领域。这种生态分布恰恰揭示了格式设计与使用场景之间的张力——一个为知识节点连接设计的格式，天然缺乏图形变换的表达能力。

但问题也很明显：JSON Canvas 的目标更宽泛，数据模型更简单，因此没有定义参考板应用真正需要的若干关键特性。由于缺乏 transform 矩阵、clip path 以及嵌入二进制资源的机制，具体缺失包括：

• 裁剪与旋转：参考板中图片常需局部裁切和角度调整。这里涉及两个图形学基础概念：Transform 矩阵（变换矩阵）是描述平移、旋转、缩放和倾斜的标准数学工具，通常表示为 2D 环境下的 3×3 仿射变换矩阵或 CSS 中的 matrix(a,b,c,d,e,f)。没有 transform 矩阵，元素只能用 x/y/width/height 描述位置和大小，无法表达旋转角度或非等比缩放。在参考板的实际使用中，仿射变换矩阵的缺失意味着什么？假设一位概念艺术家收集了一张建筑照片，将其旋转 15 度以匹配透视线，然后裁剪出窗户细节部分作为纹理参考。在支持 transform 矩阵的系统中，这些操作可以用 matrix(cos15°, sin15°, -sin15°, cos15°, tx, ty) 精确记录，且原始图片数据不会被修改——这是非破坏性编辑（Non-destructive Editing）的核心理念。而在只有 x/y/width/height 的系统中，旋转后的图片要么必须被重新光栅化（生成新像素数据），要么这一操作根本无法被保存。Clip Path（裁剪路径）则定义了一个几何形状，只有落在该形状内部的内容才会被显示——这是实现图片局部裁切的标准机制，在 SVG 和 CSS 中已是成熟的规范。
• 显式的分组归属与局部变换：明确哪些元素属于同一组，以及组内的独立变形；
• 媒体播放：支持视频、音频等动态素材；
• 嵌入式资源打包：把原始素材直接封装进文件；
• 可编辑的绘图：手绘标注、草图等矢量内容。

如果强行用私有约定去编码这些信息，产生的文件普通 JSON Canvas 读取器又无法完整理解——反而破坏了兼容性的初衷。

ORBF 的核心设计思路

定位为轻量"交换层"而非替代方案

针对上述需求，作者启动了 ORBF（Open Reference-Board Format）作为提案。它的定位很克制：不是要取代各家应用的原生格式，而是充当一个小型的交换层。

这种"交换层"的定位与 3D 图形领域的 glTF 格式高度相似。glTF（GL Transmission Format）由 Khronos Group 于 2017 年发布 2.0 版本，被称为"3D 领域的 JPEG"。glTF 的成功路径对 ORBF 具有重要参考价值：它也采用 JSON+二进制缓冲区的混合架构；它明确定位为传输格式而非创作格式（即不试图替代 Maya 的 .ma 或 Blender 的 .blend）；通过扩展（extensions）机制允许各厂商添加私有特性而不破坏基础互操作性。目前 glTF 已被 Adobe、Apple、Google、Microsoft 等数十家公司的工具支持。ORBF 如果能借鉴 glTF 的扩展机制——定义一个稳定的核心规范加上可选扩展——可能更容易被不同参考板应用接受。

应用可以有两种接入方式：

1. 保留现有的原生格式，额外增加 ORBF 的导入/导出功能；
2. 在原生数据旁边附带一份可移植的 ORBF 表示。

同时，ORBF 与 JSON Canvas 之间的相互转换仍可支持，只是在转换过程中若有特性丢失，会明确向用户报告。这种"渐进增强"的思路降低了开发者的接入门槛，也尊重了各应用已有的技术投资。

ZIP + JSON 架构：数据可恢复性优先

ORBF 的一个务实设计是：独立的 ORBF 文件本质上是一个包含 JSON 和原始媒体的 ZIP 包。这带来一个重要好处——即便没有专门的查看器，用户也能用任意压缩工具打开文件、直接取回自己的图片和数据。

将文件格式设计为 ZIP 容器并非 ORBF 的独创，这是一种经过广泛验证的设计模式。最著名的先例包括：OOXML（.docx/.xlsx/.pptx，微软 Office 文档本质上是 ZIP 包含 XML 和媒体资源）、ODF（.odt/.ods，LibreOffice 的开放文档格式）、EPUB（电子书格式，ZIP 内含 XHTML 和图片）、以及 Sketch 文件（ZIP 内含 JSON 页面描述和图片资源）。这种架构的核心优势在于：利用 ZIP 的通用压缩能力减小文件体积；保持内部文件可独立访问，即使缺少专用阅读器也能手动提取内容；通过目录结构组织不同类型的数据，实现关注点分离。

ZIP 格式内部实际上支持多种压缩算法：最常见的 DEFLATE（zlib）、不压缩存储（Store）、以及较新的扩展如 LZMA 和 Zstandard。对于参考板场景，已经过压缩的 JPEG/PNG 图片再用 DEFLATE 压缩几乎不会缩小体积，因此通常以 Store 模式存入——这也意味着 ZIP 包的大小基本等于所有素材文件的总和。Apple 的 .ipa 和 Android 的 .apk 也是 ZIP 包，它们通过 ZIP64 扩展支持超过 4GB 的文件。ORBF 规范未来需要明确是否强制要求 ZIP64 支持，因为专业创作者的参考板包含数百张 4K 图片时，4GB 的传统 ZIP 上限很容易被突破。

不过，这种设计也存在工程权衡。ZIP 格式不支持高效的随机访问——要读取包内某个文件的元数据，需要先解析中央目录记录（Central Directory）。对于包含数百张高分辨率图片的大型参考板，频繁的解压缩操作可能带来性能瓶颈。这也是为什么 Figma 选择了云端存储+增量同步而非本地 ZIP 包的原因之一。此外，ZIP 格式的时间戳精度仅为 2 秒，不支持 Unix 权限等元数据，这些在协作场景下可能成为限制。ORBF 未来可能需要在"完全解压后工作"和"流式读取"之间找到平衡点。

这一点直击"格式锁定"的痛点。对于依赖参考板长期积累素材的创作者而言，"最坏情况下我的内容不会消失"是一种关键的安全感。

项目目标与开放协作现状

让参考板真正实现跨平台流动

ORBF 的核心目标可以用一句话概括：让某人在一个平台上创建参考板，传给使用另一平台的人，并保留足够的信息让对方继续工作。这正是当前参考板生态最缺失的一环。

目前 ORBF 还处于实验性的 0.1 提案阶段，尚未有其他应用确认支持。其代码仓库采用 MIT 许可证，包含草案规范、schema、示例包和验证 fixture——这是一套相对完整的起步材料，表明作者在认真推动标准化，而非只抛出一个想法。其中，Schema 在此语境下通常指 JSON Schema，它是一种用 JSON 编写的声明性规范，可以精确定义 JSON 数据的结构、字段类型、必填项、取值范围等约束条件。开发者可以用 JSON Schema 验证器自动检查一个 ORBF 文件是否符合规范，而不需要人工逐字段核对。Fixture（测试夹具）则是预先构造好的标准测试文件，包含各种边界情况——比如空画布、包含特殊字符的笔记、超大尺寸图片引用等。多个实现者使用同一套 fixture 进行测试，是确保互操作性的关键实践，类似于 Web 浏览器领域的 Web Platform Tests（WPT）项目。

开放标准面临的经典难题

你可能没注意到，作者在提案末尾坦诚自己没有做过协作式文件格式，并向社区求助两个经典问题：

• 如何把其他实现者引入到制定过程中？
• 如何避免格式被第一个应用的实现过度塑形（over-fitting）？

这两个问题恰恰是所有开放标准的成败关键。历史上不乏"看似开放、实则由单一厂商主导"的格式，最终难以被广泛采纳。开放标准的成功案例（如 HTML/CSS、SVG、PDF、glTF）通常具备几个共同特征：由多个独立实现者共同参与制定、有明确的治理组织（如 W3C、Khronos Group）、以及经过严格的互操作性测试。反面案例同样不少——XMPP（即时通讯协议）虽然开放，但因 Google、Facebook 等大厂先采纳后放弃而碎片化；WebSQL 因只有单一实现（SQLite）而被 W3C 放弃。

ORBF 面临的治理问题有几种可能的解决路径。一种是"仁慈独裁者"模式（BDFL），如 Python 语言早期由 Guido van Rossum 主导决策；一种是成立正式的标准化组织或加入现有组织（如向 Khronos Group 或 W3C 提交）；还有一种是类似 Markdown 的"事实标准"路径——虽然 John Gruber 的原始 Markdown 从未正式标准化，但 CommonMark 规范通过严格的测试套件实现了实际上的互操作性。考虑到参考板工具市场的碎片化和各厂商的规模差异，ORBF 可能更适合 CommonMark 路径：以详尽的测试套件和参考实现来驱动一致性，而非依赖正式的组织治理。

对于 ORBF 这样的社区驱动提案，关键的里程碑是获得至少两个独立的、非作者本人开发的兼容实现——这通常被称为"双重实现原则"（Two Independent Implementations），是 W3C 将规范从草案推进到推荐标准的硬性要求。ORBF 能否成功，很大程度上取决于能否在早期就吸引到独立的第二、第三方实现，通过实际互操作测试来打磨规范。

结语：小格式背后的大意义

ORBF 目前只是个人开发者提出的早期提案，前途未卜。但它触及了一个被长期忽视的真实需求：创意工具之间的数据主权与可迁移性。

数据主权（Data Sovereignty）和数据可迁移性（Data Portability）的讨论近年来已从云计算和社交媒体领域扩展到创意工具领域。欧盟《数字市场法案》（DMA）和《数据法案》（Data Act）明确要求"守门人"平台提供数据导出能力。在创意行业，Adobe 2022 年宣布收购 Figma（后因监管原因终止）曾引发广泛的数据可迁移性讨论——如果一家公司控制了从设计到交付的全链路，用户的创作资产是否真正属于自己？参考板作为创意流程的上游环节（灵感收集→概念设计→执行），其数据的可迁移性直接影响创作者能否自由选择下游工具链。

在 AI 生成素材爆发、跨平台协作成为常态的今天，参考板作为创意工作流的重要一环，理应拥有一个开放、可检查、可恢复的交换格式。ORBF 未必是最终答案，但它提出的问题——如何在尊重现有生态的前提下建立互操作性——值得整个创意软件领域认真思考。

核心要点

核心要点

核心要点