我正在参与掘金技术社区创作者签约计划招募活动，点击链接报名投稿。

短序

新丰美酒斗十千，咸阳游侠多少年。
相逢意气为君饮，系马高楼垂柳边。

🐹相聚的时光总是短暂而美好、敞亮没有拘束的分享,点到即止的收尾，满怀期待地下次相聚,生活的波折困苦一大堆,总要以相聚来淡化挫败,拾取信心，原谅我这波相聚后遗症,感慨啰嗦一堆，我赵曰天又回来了，代码下酒,天不生我赵曰天，码界万古如长夜。

🐹现在这种追求颜值，忽略应用的方案层出不穷,很多都是蜻蜓点水，适可而止，就拿我现在想来是一个常识性问题的场景来说，富文本的编辑针对题注的说明，在归档、常规文档本应是个很常见的问题，但是市面上的编辑器鲜有考虑到这个情况的，据我观察也就ckeditor5有这方面的交互设计

富文本发展史

时间线

时间线	事件	里程碑
1983年-2013年	文字处理器应用程序 Microsoft Office Word	文件格式二进制文件格式内部加密格式【非公开】
1988年5月到1989年9月	WPS被求伯君开发出来	垄断市场转变为2选1
2013年-2018年	信息化建设转化	载体由程序exe->为网页 goole-doc office-online-app
2018年-至今	协同办公领域井喷	钉钉、飞书、腾讯文档

变迁史

背景

🥩Microsoft Office Word是微软公司的一个文字处理器应用程序。它最初是由Richard Brodie为了运行DOS的IBM计算机而在1983年编写的。随后的版本可运行于Apple Macintosh (1984年)、SCO UNIX和Microsoft Windows (1989年)，并成为了Microsoft Office的一部分。
Word给用户提供了用于创建专业而优雅的文档工具，帮助用户节省时间，并得到优雅美观的结果。一直以来，Microsoft Office Word 都是最流行的文字处理程序

🥩从1988年5月到1989年9月，求伯君花了整整一年的时间完成了WPS的研发，国内市场文档领域有了开拓的可能，同时也开启了漫长的斗争妥协之旅

🥩Microsoft office Word 97到Microsoft office Word 2003之前的Word文件格式都是二进制文件格式。微软声明他们接下来将以XML为基础的档案格式作为他们办公室套装软件的格式。Word 2003提供WordprocessingML的选项。这是一种公开的XML档案格式，由丹麦政府等机构背书支持。Word 2003的专业版能够直接处理非微软的档案规格。

🥩web-office-oline 也算是被倒逼出现,一定程度上缓解了线上问题,但因其产品特性，想要大刀阔斧地改造基本没有可能，而实际应用,并不是从线下功能复刻到线上那么简单，最关键的问题是太消耗服务器资源,64G内存的服务器500M的文件也遭不住，更遑论并发量大的时候

🥩幕布是另外一个突破口,以提纲，演示文稿，快捷方式等特色很快吸引了一波人气，最终被飞书收购，也算是幕布作者的巅峰了

🥩2019年疫情,是协同办公领域的契机，开启了文档协同的蓬勃发展，OKR的管理理论压倒KPI，铺天盖地，调侃个体外话Kpi: 人扔飞盘，狗去捡回来;okr：狗自己扔飞盘，并且自己捡回来

发展

🍺在被doc格式被加密的时代,解决方案有3种
🐹 word转pdf，通过不pdf预览插件保证格式以及内容安全性。
🐹 通过ocx插件打开exe保证编辑与深度化定制与控制（永中,等早期方案）
🐹 通过ms-doc转化为html渲染显示,格式及分页的问题无法有效保证,对保真度比较高的应用,没有实际效能
🍺信息化建设的进度加深,文档编辑预览诉求明显
🐹 web office online 微软自提供网页应用参考163邮件
🐹 百度富文本编辑器uediter,ckeditor,常年霸榜
🐹 网页端导出,即转为mhtml,特殊处理图片问题，能够保证导出的doc，图片资源的正常显示。
🍺线上内容协作探索
🐹业务上比较明显的一个矛盾点是，用word工具已经能很好地处理，线上能带给用户什么？
🐹 由矛盾点引发了两个争端，一个就是个性化专业,一个是协同
其实也就是钉钉文档和飞书文档的立论依据，一个保证基础格式的同时深挖协作能力，一个强调文档应用属性,强化呼出工具的强化，同时对非结构化文档片建立引用关系
🐹Wps线上版本，算是技术领先型 走的是基础线路,toB为企业私有化部署服务，就以用的层级来说，解决了协同,格式，线下归档留底等问题，关于其分页等格式还原度，绝对是富文本编辑领域的翘楚了
🍺开源作者的探索
🐹自从H5开启了美的探索,ueditor的丑，开始深入人心,开源作者们打着颜值更高的口号，出现了一批次的编辑器
🐹另外一个就是复刻完成后,办公协同的论调和市场很大，又忙着技术架构转型，Slate 是一个完全可定制的富文本编辑框架。

编辑器硬编码了文档的结构规范，难以定制。类似加粗和斜体的结构可以开箱即用，但评论、嵌入内容以及更多的定制性需求呢？
对文档的编程式变换非常错综复杂。用户的编写体验可能不错，但在执行编程式变更时却不必要地复杂，而这对于构建高级的编辑行为至关重要。
对 HTML、Markdown 等内容的序列化支持看起来像是事后加上的。这是一个非常常见的使用场景，但要实现将文档转换为 HTML 或 Markdown 每个简单功能都需要编写大量的模板代码。
重新学习一个新的视图层效率不高且十分受限。各种编辑器在重新发明视图层的轮子，而非使用 React 这样已有的技术方案。你必须学习一套带着自由限制和陷阱的新系统。
对协同编辑没有预先设计好的支持。编辑器内部的数据结构使其无法用于实时、协作的编辑场景中，除非重写编辑器。
代码仓库是单体的，而非小而可复用的。许多编辑器没有对外开放本应为开发者所复用的内部工具，以至于不得不重新发明轮子。

无法构建复杂而存在嵌套关系的文档。 不少编辑器是围绕简单的【扁平】文档结构设计的，这使得表格、嵌入内容和字幕等内容难以理解，有时甚至无法实现。

现代协同文档分析

🚩 业务应用
✊文档的协同诉求很强烈,同时文档的核心要义其实就是存档留底，所以格式和文件是必不可少的。在满足这个前提下,深挖业务,定制化工具才是企业员工和管理制度共力的导向

✊显示层以块结构进行选择、渲染、交互,编辑权限控制最终的转化为标准渲染结构

✊能呼出区域根据业务方向定制，对其关联性数据抽取准备,最终转化为文字片段、图、表等结果

🚩轻应用
markdown与富文本编辑的区别，对格式的要求没那么强烈,最终的显示效果可以多样，同样没有协同诉求
这个其实说不上比对，只能说是本质的诉求不同
🚩现代应用
这个属于掀桌子的举动了,认为历史文档编辑形式已经跟不上潮流，要摒弃掉之前word文档的历史包袱，轻装上路
但总结起来就是现实还没到那一步，为时过早

深度化处理

🚗非结构化的文档碎片处理，在企业里面很常见，比如具体的人工修订数据最终在文档里面，挖掘存在难度，另外就是动辄上百G,TB级的专业数据，归档备份是个极度痛苦的事情，属于制度和人文的冲突

🚗归于常规，一般几百兆的文件很常见,如何解决预览等问题是个老大难的问题,pdf开放格式，能够让边读边解析，也就不存在性能上的问题，而word即便是Openxml格式，也没法实现这种机理，主要是因为解析必须全部读取，也就是都加载到内存中，才能实现进一步解析，所以需要特殊的手段去处理。

🚗经过程序验证：docx是压缩流（重命名.docx为rar即可观察）

正常1.2g doc文档实际读取时耗费的处理内存至少在16G以上，且如果作为服务针对并发的情况多实例运行时基本无法支持操作、通过对文档流压缩流对图文件的移除、可以有效节约处理内存、同时处理转换时间由原本的124秒降低->16秒，时效率提升6倍，内存耗费率12G+/1g- 约为12倍、重新按照单页进行重新组织、即保证了文档的格式还原度、降低每页word的大小、同时通过Openxml可以重新将图装填回单页文档保证恢复、在预览时灵活的加载图数据

🚗 结论：此方案完全具备操作实施可行性、且有一定的调优空间、最终完整的处理能够保证1G文档能够在30秒内快速响应、由此百兆文档可达到秒级响应、通过前端的加载优化几乎可以实现即时响应

解决方案

🐹上传与读取的联动，上传时即转换doc为docx,解析移除media图片资源，按页解析另存，如果结合mogodb分片存储更优，能保证读取最小化，1G->几十K都可能，解析预览用的时Apose.words

🐹自定义流加载，预留分片读取规则，保证读取内存的优化

🐹渲染显示,为保证格式的绝对还原可以图或者pdf进行处理（docx-preview 前端预览方案其实就是解析openxml，适配的样式，只不过格式还是会错乱）

至此，其实解决思路已经很清晰了，1G的文件，如果包含解析，我用电脑测试过，大约124秒才能处理完，最终整体处理差不多16秒，如果经过缓存的话,性能和内容都能保障

往期目录

又是一波感慨

聊的比较散，闲话夹杂着技术，希望读着没那么生涩晦暗，勉强一观，让分享和互动成为常态，最后求波关注！！

以待后续继续分享。

GB级word文档预览方案

短序