这篇总结，硬是拖了半年。

背景

在之前参与的业务中，因为我们一直对在线 Office 有强烈的需求，已使用的解决方案也遇到了不少问题，想要找更好的解决方案，于是进行了一次在线 Office 解决方案调研。

以下是我针对实际业务场景整理出来的需求：

需求
优先级
 备注
私有云 高 即内网部署
终端支持 高 最好是网页端，或者必须支持与网页深度交互
基础功能 高 具备 Word 基础的字体设置、字体大小、加粗、对齐、颜色、背景颜色等功能
插件支持 高 可以自定义插件来满足复杂业务场景，例如文档格式检查
二次开发 高 开放 API，支持根据业务二次开发、功能定制，甚至扩展或增强基础功能
深度定制 高 插件和二次开发也解决不了的问题，需要厂商支持对某些功能深度定制
使用体验 高 安装成本低，编辑体验需与本地 Word 高度一致
价格 高 要在预算范围内
开发者社区 中 更活跃的社区可以快速解决问题
安全与稳定性 中 数据传输安全、文件加密、文档水印等支持，无论何种场景的编辑，均不可频繁出现崩溃、卡死、数据丢失等异常情况
协同编辑 低 支持多人协同编辑、历史记录查看，文档回滚等功能
分布式部署 低 未来可能会需要，支持的产品有加分项

调研结果

调研了 Office365、Onlyoffice、可道云、WPS Office、PageOffice 等产品，以下是各产品之间的需求满足程度对比：

每个厂商都有自己的特点，针对我们的业务场景，Onlyoffice 是最符合的，大家可视情况选择。

技术方案

除了成熟的产品调研外，也调研了一些技术实现方案。

方案一：IE 中打开 Microsoft Office

这个方案关键实现如下：

1
2
3
4
5
6
7
8
9
10
11
var WordApp = null
try {
  WordApp = new ActiveXObject('Word.Application')
} catch (error) {
  console.error(error)
  alert('IE 的安全级别过高，请在 IE 的菜单栏中：工具 - INTERNET 选项 - 安全 - 本地 Intranet - 自定义级别 - 「对没有标记为安全的 activeX 控件」改为启用或提示')
  return
}
console.log(WordApp)
WordApp.Application.Visible = true
var Doc = WordApp.Documents.Open(url, true)

这个方案，文档可以打开，但后续的文档是否保存、是否关闭等行为无法掌控，且强依赖 IE。

狗听了都摇头

方案二：调用 Microsoft Office 协议

该方案实现起来挺简单的，伪代码如下：

1
2
3
4
5
// 可以打开本地文件并进行编辑
window.location.href = 'ms-word:ofe|u|file:///Users/xxx/xxx/file.docx';

// 可以打开远程文件但是属于只读模式，另存为之后可以编辑
window.location.href = 'ms-word:ofe|u|https://example.com/file.docx';

这个方案核心是使用了 Microsoft Office 开放的 URI Schemes 接口，但实现的功能也是受限于开放接口的能力。Microsoft Office URI Schemes 传送门

方案三：自定义协议 + 调用 Microsoft Office 协议

这个方案是第二个方案的升级版，自定义协议实现一个自研桌面端，然后桌面端跟 Microsoft Office 交互，通过自研桌面端补足 Microsoft Office 协议未开放的能力，比如监听文档编辑状态，交互模式跟 PageOffice 高度相似，简化版流程图如下：

不过，这个方案也需要电脑本地有个 Microsoft Office，需要额外购买版权。

或者，上一个绿色版的 Microsoft Office。

技术方案综合来看，都不太成熟，第三个会靠谱一些。不过二次开发成本也挺高的，过程中肯定会遇到不少坑，真有强烈在线 Office 需求的，建议采购适合自己的厂商。

以上~

最后，