文档技术连载 1/4：探秘钉钉文档编辑器的前世今生

随着互联网的普及和办公方式的变革，钉钉文档编辑器作为一款强大的文档编辑工具，逐渐受到越来越多企业和个人的青睐。然而，钉钉文档编辑器的前世今生却鲜为人知。它的诞生和发展历程有着怎样的曲折故事？它又是如何在短时间内迅速崛起并赢得用户的信赖？本文将带您一探究竟，揭开钉钉文档编辑器的神秘面纱，探寻其背后的技术奥秘。

一、Web 编辑器简史

在和大家分享编辑器技术之前，想和大家来介绍下 Web 编辑器的简史，因为在编辑器这个领域，作为人机交互最复杂的场景之一，我们了解它的“前世”，能够更清晰找到编辑器的现在一些设计的根源。

打字机时代

编辑器满足的最初需求，就是输入（Input）和输出（Output），我们在人机交互的极简版本时期，可以从打字机上找到它的一些特点，而这些特点，直接影响且继承至今。

键盘操作

在打字机上，键盘的排布和我们现在用的键盘几乎差不多。实际上我们在编辑输入时候，除了 26 个字母之外，常用的“Enter”、“Shift”、“Space”等实体按键，以及它们点按之后交互反馈一直沿用至今。这些交互反馈，可以用一个比较实际的测试用例描述来标识，例如：

光标

打字机有一个很明显的特点，就是打字的时候，在纸上会有一个游标在右移。在打字机时代这个游标，就成为我们后来的光标了。它用于定位，可以在那里落笔。

WYSIWYG

当我们在打字机上敲下一个按键的时候，白纸上的游标位置处，就会输出黑色的字符。这是一个所见即所得的过程。而现在很多的编辑器，也正是为了满足所见即所得的产物。

文本编辑器时代

随着计算机的普及和演进，我们可以看到在屏幕上进行文本编辑成为最基础的诉求。而文本编辑器时代，它和打字机时代最大的区别在于下面几点：

查找替换：能够基于编辑器的内容，进行批量的“查找”和“替换”CCP：内容之间的输入，不再局限于字符的一个个输入，还支持了拷贝、粘贴、复制Undo & Redo：当你输入之后，你可以反悔，还能反悔你的反悔 -- undo & redoSyntax highlighting：同时，文本编辑器时代，你输入的文本样式，就不再局限于白纸黑字，部分的内容还可以支持不同的颜色（高亮）富文本编辑器时代

富文本编辑器，丰富在格式。我们可以看到它和纯文本之间，又多了一些特性：

支持最基础的文本格式（加粗、斜体、删除线...）支持基于整个段落的样式设置（背景颜色、字体大小...）支持非文本的类型（图片、音视频、代码块...）

而正是越来越多丰富的格式，增加了在不同终端上实现 WYSIWYG 的难度。要想保持在不同的媒介之前输入的内容，能够一致的输出（特别是电子屏到纸质的打印），富文本时代无疑增加了不少门槛。

Web 编辑器时代

如何定义 Web 编辑器呢？最基本的特征就是基于浏览器的编辑器。在浏览器里编写文字，我们最常用的就是使用 Textarea 或者 Input 了，但编写富文本内容的话，则需要依赖富文本编辑器的能力。于是，Web 编辑器时代，还有一个特点，就是编辑器输出的内容，往往会和 HTML 的结构性匹配，以便于在浏览器端去消费输出的数据。

Web 编辑器时代和我们的关系最为密切，例如这篇文档，便是在语雀的编辑器中编辑操作完成。那么回顾下整个富文本编辑器的历史，我们可以大概划分为几个小阶段：

阶段一

在这个阶段中，有不少优秀的编辑器萌芽和得到推广：

这一个阶段的开源编辑器，依赖浏览器特性，主要是使用到了 designMode、ContentEditable、webkit-user-modify、**execCommand **等特性。早期的编辑器都采用这种方案，但可定制的空间有限。

阶段二

这一个阶段的编辑器，部分使用浏览器的特性、DOM 的 API 来自主实现 Selection、Range、Element、**TextNode **等，具备一定的可扩展性，但也会有很多难以解决的问题。

二、Web 编辑器时代之难

当我们基于浏览器来设计和开发编辑器的时候，实际上是凌驾于编辑器去开发一个高阶的输入组件。本应该由 HTML 标准来定义的富文本编辑能力，却在不同的浏览器厂商中有不同的实现方法。标准化一直比较模糊，是导致富文本编辑器成为天坑的原因之一。

当然这个原因，很多人已经在 www.zhihu.com/question/38… 中有所耳闻。这里也不再细说。我们且从所见即所得谈起。

WYSIWYG

这是来自 **Wikipedia **的介绍，我们抽出其中的关键词：content（text and graphics）以及 printed、displayed 来看下，富文本编辑器的价值在于能够输入内容且满足在不同终端下的显示一致性。

三个定理

而为了满足这个要求，如何才能做到 WYSIWYG 呢？

即：

DOM 内容和可视化（Visible）内容能够很好地进行映射。DOM 选择和可视化（Visible）选择能够很好地进行映射。所有的可视化编辑都能够映射到一个从代数上来说封闭的和完整的可视化内容集合上面。

DOM 是我们能在 HTML 中表述的所有网页页面的集合，而编辑器要处理的行为和 DOM 之间的关系在于能够让用户输入的内容，正确地在 DOM 中表示出来；用户选中的区域，也能在 DOM 中显示出来。在这个过程中，编辑器一般会有一个内存模型的概念，用于处理用户行为的整理，再驱动 DOM 的更新。

ContentEditable is Terrible

我们在实现所见即所得的编辑器的时候，除了使用** Canvas** 来完全绘制之外，还有另外一种方案就是使用 **ContentEditable **来实现内容的可编辑。但这个属性，并不是那么友好。主要表现在两个方面：

其一，HTML 本身就是非常自由嵌套组合的，用于描述一个样式“粗体斜体”，会有很多种不同的表达方法。例如要实现下面的这一句话：

HTML 的嵌套关系将会有多种实现方案，大致如下：

详见 UAX#29 www.unicode.org/reports/tr29/#Grapheme_Cluster_Boundaries

但是，当你深入去了解完这些计算机基础知识之后，也就豁然开朗了 -- 原来写编辑器，还可以这么有趣，学到了不少东西。

五、结语

在本次的分享中，暂时也就摘取了我们在编辑器过程中的 4 个有趣的案例，其实我们还有很多很多，也有很多是未曾挖掘出来的。

很多人和我说，编辑器太难了，自己可能无法胜任。其实，我只想说：编辑器虽然是一个天坑，但并没有现象的那么难。我们刚好有这样的一个氛围 -- 愿意去挖掘和挑战这一个难以标准化的领域，会去追溯其原理本质，探索其中的奥秘，乐于其中。

作者：前端早早聊
链接：https://juejin.im/post/5f0518fbe51d45346d30eca5
来源：掘金
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。