首个文档编辑器：简单却冒险的选择

在 ONLYOFFICE 今年七月迎来 16 周年之际，我们回顾了塑造产品的决定。这个决定是在名称、开源许可证和 2100 万用户之前做出的。它来自一个感到沮丧团队，以至于创建了没人试着做过的产品。

在编辑器之前，存在一个问题

那是2010年。Ascensio System SIA 的团队当时正在开发一个名为 TeamLab 的协作平台，他们需要让用户可以在产品中处理文档。该平台具备项目管理、CRM 工具、维基、博客和共享文件空间。但当有人需要编辑 Word 文档时，工作流程，可以说是相当不方便。

第一个添加的文档编辑选项简直是个噩梦。当你按下打开文件时，一个 exe 文件被下载到你的电脑上。它是带有预安装插件的 OpenOffice。门户中的文档在 OpenOffice 中打开，编辑后保存回云端。

这就是2010年网络文档编辑的工作方式。你离开浏览器。你打开一个桌面应用程序。你进行编辑。你再保存回来。你回到原来正在做的事情。每个步骤都充满摩擦。每个步骤都是潜在的失败点：错误的版本、错误的格式、错误的副本。

团队对此感到厌恶。不只是以轻微的、专业的“我们可以改进这个”的方式，而是以一种直观的、每天都感到痛苦的态度。因此，他们做出了决定，要么定义一个公司，要么摧毁它：他们决定自己编写一个编辑器。

赌注：HTML5 Canvas

在2010年，在浏览器中构建一个文档编辑器并不是一个合理的事情。Google Docs 在2006年推出，并成为显而易见的参考点，但它的工作方式是让浏览器使用标准 HTML 渲染文档。这意味着你打印的输出看起来与屏幕上看到的不同。格式在不同浏览器之间不一致。复杂的布局崩溃。网络根本无法准确复制桌面文字处理器的精度。

ONLYOFFICE 团队选择了一种根本不同的方法。他们不请求浏览器来渲染文档，而是自己渲染，直接使用 HTML5 Canvas元 素绘制每个像素。

Canvas 是 HTML5 的一部分，它允许动态、可脚本化地渲染 2D 形状和位图图像。该技术以保持初始格式而闻名，而不受浏览器或操作系统的影响。

这一点影响深远。如果逐像素绘制文档，就可以完全控制显示效果，无论是在哪个浏览器、哪个操作系统上，无论是显示在屏幕上、导出为 PDF，还是发送到打印机。输入始终与输出相同：处理后的文件保持相同的样式、段落、符号和行间距。你看到的文档就是你得到的文档。

但技术风险真实存在。HTML5 Canvas 并不是为文档编辑设计的。之前没有人这样做。团队并不是在适应现有的方法；他们是在构建一种新方法。如果它未能达到真实办公套件所需的规模和性能水平，花费两年的工程工作将会白费。

有趣的事实：Canvas 并不是第一次尝试。在最终确定为 HTML5 Canvas 之前，团队尝试过 CKEditor ——一个基于标准 HTML 渲染的成熟浏览器富文本编辑器。由于与 Google Docs 方法的不足相同，它失败了：普通 HTML 根本无法提供团队所需的格式精度和跨浏览器一致性。

团队并没有忽视这一讽刺：“Google 和微软都转向了我们所使用的相同技术，或许是受到我们的启发。”是否巧合或趋同，行业最终达成了 ONLYOFFICE 团队在2010年得到的相同结论。只是团队最先到达那里。

事实：在 ONLYOFFICE 在 CeBIT 首次亮相近十年后的2021年5月，Google 宣布 Google Docs 将从基于 HTML 的渲染迁移到基于 Canvas 的渲染，称这能提高性能和跨平台一致性。ONLYOFFICE 在2010年所下注的方式，已成为行业标准，至少对于市场上两个最大参与者之一来说。

CeBIT 2012：首次公开亮相

在2012年3月，团队将他们的赌注公之于众。在汉诺威的 CeBIT 上，全球最大的科技贸易展之一，TeamLab 介绍了首个基于 HTML5 的文档编辑器。测试的 beta 版本可在 html5.teamlab.com 上使用。

TeamLab 将第一个基于 HTML5 的文档编辑器引入办公软件。借助这种新技术，TeamLab 可以在任何浏览器、任何操作系统下正确显示文件，即便在打印或导入时。此外，它还提供了强大的表格处理、行间距、多级编号以及文本和标题样式的选项。

在这一阶段，产品仅是一个文档编辑器。没有电子表格，也没有演示编辑器。只有文本编辑器，建立在 Canvas 之上，展示了这种方法是有效的。

团队还明白，协作并不是一个附加功能；这是构建基于浏览器的编辑器的整个目的。一个在每个屏幕上看起来完全相同的文档，只有在多人可以共同合作的情况下才有用。于是他们添加了严格协作模式，允许用户锁定正在编辑的文档部分，其他人无法看到你在输入的内容，直到你点击保存。这个模式是为需要同时在文档上工作的团队设计的，以免覆盖彼此的更改。

一切的起点：电子表格

这是一个通常被时间线跳过的重要里程碑。文档编辑器获得头条，而 CeBIT 2012是正式的公开首秀。但 ONLYOFFICE 编辑器的真正起源却更奇特，且不那么线性。

项目开始并不是一个文档编辑器，而是一个电子表格编辑器，并且还没有使用 Canvas。初始版本在服务器上计算公式，这带来了自己的一系列性能问题。在文档编辑器甚至还未完成时，该项目就被完全关闭。正如开发负责人亚历克斯所回忆的：“到此为止，我们不再在上面工作。”

接下来发生的事情是官方历史中被抹去的细节。团队在幕后悄然继续工作，修复了导致项目被放弃的 Bug。最终，他们重新启动了项目。只有在此之后，文档编辑器才出现，成为后续一切的中心产品。

对 Canvas 的赌注是大胆的。但背后的故事包括一个开始、一个暂停、一个悄然的延续，以及一次大多数行业人士从未听说过的重新启动。这是关于 ONLYOFFICE 编辑器如何实际存在的较不显眼的版本。

当编辑器首次发布时，ONLYOFFICE 的营销团队使用了一句比任何产品规格更好地捕捉定位的线：“如果 Google Docs 和 Microsoft Office 有了孩子？那它会叫 TeamLab。”

这对 Canvas 方法实际交付的内容进行了有益的压缩：Google Docs 的协作的、基于浏览器的特性与 Microsoft Office 的格式精度相结合。单独的任何一种方式都不足够。HTML5 Canvas 的赌注正是试图一次性获得两者。

2013：告别专有格式

Canvas 的赌注是技术性的。而2013年的赌注与兼容性有关，在某种程度上更具影响力。

当时，ONLYOFFICE 使用自己的内部格式（.doct，.xlst，.pptt）。在2013年，团队完全放弃了这些格式，并承诺采用 OOXML，即 DOCX、XLSX 和 PPTX 背后的 Office open XML 标准。

这并不是显而易见的选择。采用微软的格式意味着接受其复杂性：文档中每种极端情况，十年历史的 Word 文档中每个晦涩的 Excel 公式，每个 PowerPoint 动画都必须正确渲染，因为用户会带来在 Microsoft Office 中创建的文件，并期望它们能够打开。但另一种选择是要求用户转换自己的文件，这是一条死胡同。整个世界都在使用 DOCX 和 XLSX，而 ONLYOFFICE 必须与用户已经拥有的文档共同工作。

这一决定的原因是，TechCrunch 在2014年1月的报道中写道，TeamLab “声称将 Google 在线协作功能的优势与 Microsoft Word 的高质量格式结合起来”，而该产品的标题则写道“想要让 Microsoft Office 365 重回设计阶段”。

2014：开源决策与新名称

到2014年中，团队已经拥有了一个完整的办公套件：文档、电子表格和演示文稿，能在浏览器中运行，兼容 Microsoft Office 格式，具备实时协作编辑功能。从首次挫败性的决定重启，已经经过四年时间。

在2014年7月，TeamLab Office 更名为 ONLYOFFICE，并在 GitHub 和 SourceForge 上按照 AGPLv3 发布了源代码。这个名称反映了关注点：只关注办公软件。源代码的发布将一个专有的赌注转变为一个开放的、透明的和安全的选择，任何人都可以审查它。

这一决定也令人深思，在事后看来，成为后续一切的基础。所有的40多个集成连接器、Moodle 插件、Confluence 连接器和协作空间 MCP 服务器，都可以追溯到代码公开的那一天。

鲜有人提及的服务器重写

Canvas 的赌注获得了大多数关注。但在同一时期，还有一个第二个技术决策，在某种意义上，同样具有激进性。

当团队开始在浏览器中构建协作编辑时，出现了一个新问题，在讲述编辑器故事时很容易被忽视。原始的文档服务器运行在 .NET 上，和 TeamLab 其他部分使用相同的技术栈。对于一个需要实时协作编辑要求的基于浏览器的协作产品，这种架构是无法支持的。

因此在2014年，团队废弃了他们开发了四年的整个服务器，并在 Node.js 中从零开始重新编写。当时，Node.js 几乎不为生产使用所知。正如开发负责人亚历克斯所描述的：“选择 Node.js 就像选择 Canvas 一样奇怪。没有人会用它来写任何高负载的应用。”重写由一位工程师在四个月内完成。团队注意到，他们用的 Node.js 版本是 0.10-0.12，在这个版本中，正如他们用标志性的低调口吻所述，“0意味着‘别指望有什么严肃的事情，伙计们。’”

两个非常规的技术赌注，在同一年，由一个对传统选择已经失去耐心的团队下定决心。

2016：快速协作编辑与桌面编辑器

又两个重要的里程碑完成了编辑器故事的第一篇章。

快速协作编辑方法在2016年出现，目标是为所有用户提供真正有效的文档协作。严格模式在你输入时锁定段落，仅在保存时显示变更，而快速模式则实时显示变更，这是大多数用户现在与文档协同编辑相关联的行为。ONLYOFFICE 现在两个都拥有：一种有意识、受控的编辑模式和一种实时、同时的模式。选择取决于团队的工作流程，而不是技术的限制。

2016年3月，ONLYOFFICE 的开发者们发布了一款桌面应用程序，ONLYOFFICE 桌面编辑器，定位为 Microsoft Office 的开源替代方案。与在浏览器中运行的相同 HTML5 Canvas 编辑器现在被打包为 Windows、Linux 和 macOS 的原生桌面应用程序。起初作为仅限网络的赌注，技术方法现在可以在各个地方运行。

移动：到处都是相同的编辑器

2016年的桌面应用程序将 Canvas 编辑器扩展到了浏览器之外。移动应用程序进一步将其扩展到更多人其实正在进行文档工作的设备上。

ONLYOFFICE 文档在 iOS 和 Android 上将相同的编辑引擎带入智能手机和平板电脑中：完整的 DOCX、XLSX 和 PPTX 编辑、实时协作编辑、变更跟踪和评论。不是一个附带基本编辑能力的简化查看器，而是相同的编辑器，适用于触控。2026年发布的9.4版本在移动端增加了对 Mistral AI 的支持、云文档的手动保存控制、Android 电子表格编辑器中的公式选项卡，以及在 iOS 上支持多图像插入。自2010年作为一个浏览器赌注开始的 Canvas 方法现在可以在用户可能实际工作在的每个平台上运行。

这场赌注究竟是什么样的

在十四年后，很容易将 HTML5 Canvas 的决策视为一种远见。事实上，那时这看起来是一个遭遇耐心耗尽的团队所采取的严重风险。

2010年可供选用的替代方案为：使用带插件的 OpenOffice（他们尝试过，不甚满意）、使用类似 Google Docs 的浏览器渲染方法（跨浏览器不一致，格式受限）、或构建一种需要桌面安装的专有产品（背离云平台的目的）。没有一种方法足够好。因此，他们建立了一个第四个尚不存在的选项。

技术风险是实质性的。基于 Canvas 的渲染计算量大。使其在真实文档编辑中快速足够，具备复杂的表格、嵌入的图像、公式和实时协作编辑，要求在性能优化上的重大工程工作，这在首次 CeBIT 演示之后多年来仍在进行。

ONLYOFFICE 开发了一种架构，确保参与者之间有轻微的实时连接，并最小化服务器负载。这种架构旨在处理同时编辑而不在服务器上产生性能瓶颈，至今仍然是 ONLYOFFICE 处理协作编辑的基础。

从单一编辑器到七个编辑器的套件

在2012年 CeBIT 上推出的唯一文档编辑器beta的团队现在提供七种编辑器类型，协调运行在 ONLYOFFICE 文档中：文档编辑器、电子表格编辑器、演示编辑器、PDF 编辑器、表单生成器、图示查看器，以及跨所有编辑器运行的基于 AI 的助手层。

该产品是使用 Canvas 构建的，Canvas 是 HTML5 的一部分，允许动态、可脚本化地渲染2D形状和位图图像。ONLYOFFICE 文档中使用的基本格式类型是 OOXML（DOCX、XLSX、PPTX）。这没有改变。2010年选择的渲染方法仍然是今天在任何浏览器、任何设备，以任意45种界面语言打开的每个文档的基础。

这一赌注很简单：构建一个在每个平台、每次都能精确渲染文档的编辑器。风险是真实的：没有人以这种方式做过，构建它耗费了多年的时间。十四年后，无论是在法国的浏览器中编辑，还是在日本的桌面上，或在肯尼亚的手机中，甚至是在德国医院地下室的服务器上打印，文档的样子都一样。

PDF 编辑器：一种本不该可编辑的格式

原始赌注中最重要的扩展之一并不是一种新的编辑器类型；而是对现有格式的转变。

PDF 格式于1993年设计为最终且固定的文件。一个文档生命周期的结束，而不是其中的一个阶段。几十年来，处理 PDF 意味着查看它、打印它或将其转换成其他格式。ONLYOFFICE 的 PDF 编辑器直言质疑了这一假设。

如今，PDF 编辑器支持无需转换的直接文本和图像编辑、带形状和印章的整页注释、敏感内容的永久删减、三种模式的电子签名、填充角色字段的可填写PDF表单、包括拖放重排在内的页面管理、对扫描文档的 OCR 识别以及实时协作注释。这不是一个附带编辑功能的查看器。它是一个针对行业认定为只读格式的完整编辑环境。

PDF 编辑器包含在 ONLYOFFICE 中，无需额外费用，不需要单独的 Adobe 许可证，也没有附加订阅。这一决定反映了与 Canvas 赌注相同的逻辑：如果存在某种文档格式，人们应该能够在与其他文件相同的环境中正确地处理它。

继续阅读

这篇文章是我们为 ONLYOFFICE 16周年生日献上的16部分系列中的第二篇。接下来，我们将了解塑造 ONLYOFFICE 的关键里程碑、产品决策和其他步骤。让我们一起回顾一下。

敬请期待第三篇文章！