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

背景

在之前参与的业务中,因为我们一直对在线 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 需求的,建议采购适合自己的厂商。

以上~

最后,