新丰美酒与咸阳游侠的意气之饮，及富文本编辑的现状探讨
短序列信丰酒斗万人，咸阳游侠长年住。
当我们见面时，我们会为你喝酒。我们会把马拴在高楼和垂柳上。
我们相聚的时光总是短暂而美好，开放无限制的分享，尽快结束，对下一次的相聚充满期待。生活中有很多波折，但我们总需要聚在一起，冲淡挫败感，获得信心，原谅我的这一点。波涛汇聚的后遗症，诸多感叹叹息，我赵越天又回来了，与代码喝酒，老天爷没有生下我赵越天，代码的世界如长夜。
如今，追求外观而忽视应用的解决方案层出不穷。其中很多只是划痕，应该足够了。举一个我现在认为是常识问题的场景。富文本编辑侧重于档案和常规文档中的标题描述。这应该是一个很常见的问题，但是市面上很少有编辑考虑到这种情况。据我观察，这方面没有交互设计。
富文本发展历史时间表
时间线
事件
里程碑
1983-2013
文字处理应用程序
单词
文件格式 二进制文件格式
内部加密格式[非公开]
1988年5月至1989年9月
WPS是求伯君开发的
垄断市场转变为2选1
2013-2018
信息化建设与改造
由程序exe矢量->网页
古尔文档
- 应用程序
2018年至今
协同办公领域井喷
钉钉、飞书、腾讯文档
历史变迁背景
https://gimg2.baidu.com/image_search/src=http%3A%2F%2Fss2.meipian.me%2Fusers%2F12672449%2F9548e965fbda86b80f766bbbf910093a.jpg%3Fmeipian-raw%2Fbucket%2Fivwen%2Fkey%2FdXNlcnMvMTI2NzI0NDkvOTU0OGU5NjVmYmRhODZiODBmNzY2YmJiZjkxMDA5M2EuanBn%2Fsign%2Fb953801f8309db1b8bbc12836155835e.jpg&refer=http%3A%2F%2Fss2.meipian.me&app=2002&size=f9999,10000&q=a80&n=0&g=0n&fmt=auto?sec=1734044763&t=342bd66b1b156602b0366b38f9999553
Word 是 的文字处理应用程序。它最初是在 1983 年为运行 DOS 的 IBM 计算机编写的。后续版本在 Apple (1984)、SCO UNIX 和 (1989) 上运行，并成为 .
Word为用户提供了创建专业、优雅文档的工具，帮助用户节省时间并获得优雅、美观的结果。 Word一直是最流行的文字处理程序
从1988年5月到1989年9月，求伯君用了整整一年的时间完成了WPS的研发。这开启了在国内市场开拓证件领域的可能性，也开启了漫长的斗争与妥协之旅。
从Word 97到Word 2003的Word文件格式都是二进制文件格式。微软宣布他们将使用基于XML的文件格式作为他们的办公软件套件的格式。 Word 2003 提供的选项。这是丹麦政府和其他机构认可的开放 XML 文件格式。 Word 2003专业版可以直接处理非微软文件规范。
web--oline也被迫出现，一定程度上缓解了上网问题。但由于其产品特性，基本上不可能进行大刀阔斧的改变。而实际应用并不是将离线功能复制到线上功能。这么简单，最关键的问题就是消耗服务器资源太多。 64G内存的服务器无法处理500M的文件，更不用说并发量很大的时候了。
窗帘是另一个突破点。它以其大纲、演示文稿和快捷方式等功能迅速吸引了一波流行。最终被飞书收购，飞书堪称作者的巅峰之作。
2019年的疫情是协同办公领域的一次机遇，开启了文档协同的蓬勃发展。 OKR的管理理论压倒了KPI，势不可挡。他们调侃KPI：人扔飞盘，狗捡起来； OKR：狗自己扔飞盘，自己捡
发展
编辑器硬编码了文档的结构规范，难以定制。像粗体和斜体这样的结构是开箱即用的，但是评论、嵌入内容和更多定制需求呢？
文档的编程转换非常复杂。用户的书写体验可能很好，但在执行程序化更改时却不必要地复杂，这对于构建高级编辑行为至关重要。
对 HTML 等的序列化支持似乎是事后的想法。这是一个很常见的使用场景，但是将文档转换为 HTML 或者每个简单的功能都需要编写大量的模板代码。
重新学习新的视图层效率低下且限制性很大。各种编辑器正在重新发明视图层的轮子，而不是使用像 React 这样的现有技术解决方案。你必须学习一个有自由限制和陷阱的新系统。
没有预先设计的协作编辑支持。编辑器内的数据结构使其无法在不重写编辑器的情况下用于实时协作编辑场景。
代码存储库是整体的、不小且可重用的。许多编辑器没有公开应该被开发人员重用的内部工具，因此他们不得不重新发明轮子。
现代协作文档分析
商业应用
✊文档协作的需求非常强烈。同时，文档的核心目的实际上是保存记录，因此格式和文件至关重要。在满足这个前提的前提下，深挖业务、定制工具，是企业员工和管理体系共同努力的指引。
✊显示层采用块结构进行选择、渲染、交互，编辑权限控制最终转化为标准的渲染结构
✊可以根据业务方向定制标注区域，并提取和准备其相关数据，最终转换为文本片段、图表、表格等结果。
轻应用
与富文本编辑不同的是，格式要求没那么强，最终的显示效果可以多种多样，不需要协调。
其实这不能说是比较，只能说本质诉求不同。
现代应用
这是一个扭转局面的举动。我认为历史文献编辑的形式已经跟不上潮流了。我们需要抛弃以往word文档的历史包袱，轻装上阵。
但总而言之，现实还没有达到那个地步，还为时过早。
深加工
https://pic1.zhimg.com/100/v2-6ede41d8d51be4db493619f90afa4cc4_r.jpg
非结构化文档碎片化处理在企业中非常普遍。例如，特定的手动修订数据最终出现在文档中，很难挖掘。此外，还有数百GB和TB的专业数据。归档和备份是一件极其痛苦的事情。制度与人性之间的冲突
一般来说，数百兆字节的文件很常见。如何解决预览等问题是一个长期存在的问题。 PDF的开放格式可以同时读取和解析，因此不存在性能问题。即使是Word的格式，也无法实现这种机制，主要是因为分析必须完全读取，即加载到内存中，才能实现进一步的分析，所以需要特殊的手段来处理。
经程序验证：docx是压缩流（将.docx重命名为rar来观察）
实际读取正常的1.2g doc文档时消耗的处理内存至少有16G，如果作为并发多实例运行的服务，基本无法支持运行。通过压缩文档流来删除图像文件可能是有效的。节省处理内存，处理转换时间由原来的124秒缩短为16秒，每小时效率提升6倍。内存消耗率为12G+/1g-约12倍。按单页重组，保证文档格式恢复，缩小每页字数，保证图像重新加载回单页文档恢复，预览时灵活加载图像数据
结论：该方案运行实施完全可行，具有一定的优化空间。最终完整处理可保证1G文档30秒内快速响应。因此100M的文档可以实现秒级响应，并且可以通过前端加载。优化允许近乎即时的响应
解决方案
上传与读取的联动，上传时将doc转为docx，解析并取出媒体图片资源，按页解析并保存，如果结合分片存储更好，可以保证最小化读取，1G->几十K可能，解析预览时使用Apose.words。
自定义流加载并预留分片读取规则，保证读取内存优化
渲染显示，为了保证格式的绝对还原，可以处理为图片或者pdf（docx-前端预览方案其实就是解析并适配样式，但是格式还是会乱）
至此，解决方案其实已经很明确了。如果1G的文件包含解析，我在电脑上测试过。处理大约需要 124 秒。最终整体处理时间差不多是16秒。如果缓存的话，性能和内容都能得到保证。
返回目录
推荐的多平台博客工具
全栈终结者——把nuxt扔进垃圾桶与seo发生化学反应
ol与Vue室内定位模式设计
二十多年的时间就像一场梦，虽然这具身体处于震惊之中。我悠闲地爬上小亭看看新气象。古今发生了多少事，渔民唱三更
Tauri操作实践（一）-环境准备
代码生成代码
vue之vue-cli-升级指南（三）
vue之vue-cli-升级指南（二）
vue之vue-cli-升级指南（一）
又一波情绪
聊天相对随意，八卦与科技交织在一起。希望阅读不要那么枯燥晦涩，勉强能读懂，让分享和互动成为常态。最后，请大家注意！ ！
页:
[1]