新豐美酒鬥十千，鹹陽遊俠多少年。相逢意氣為君飲，系馬高樓垂柳邊。

相聚的時光總是短暫而美好、敞亮沒有拘束的分享,點到即止的收尾，滿懷期待地下次相聚,生活的波折困苦一大堆,總要以相聚來淡化挫敗,拾取信心，原諒我這波相聚後遺症,感慨啰嗦一堆，我趙曰天又回來了，代碼下酒,天不生我趙曰天，碼界萬古如長夜。

現在這種追求顔值，忽略應用的方案層出不窮,很多都是蜻蜓點水，适可而止，就拿我現在想來是一個常識性問題的場景來說，富文本的編輯針對題注的說明，在歸檔、常規文檔本應是個很常見的問題，但是市面上的編輯器鮮有考慮到這個情況的，據我觀察也就ckeditor5有這方面的交互設計

富文本發展史時間線

時間線	事件	裡程碑
1983年-2013年	文字處理器應用程序Microsoft Office Word	文件格式二進制文件格式内部加密格式【非公開】
1988年5月到1989年9月	WPS被求伯君開發出來	壟斷市場轉變為2選1
2013年-2018年	信息化建設轉化	載體由程序exe->為網頁goole-docoffice-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秒，如果經過緩存的話,性能和内容都能保障

往期目錄

多平台博客工具推薦全棧終結者-把nuxt扔進垃圾桶、Blazor與seo的化學反應ol與Vue室内定位模式設計二十餘年如一夢，此身雖在堪驚。閑登小閣看新晴。古今多少事，漁唱起三更Tauri操作實戰（1）-環境準備代碼生成代碼webpack5 針對vue vue-cli-service 升級指南（三）webpack5 針對vue vue-cli-service 升級指南（二）webpack5 針對vue vue-cli-service 升級指南（一）

又是一波感慨

聊的比較散，閑話夾雜着技術，希望讀着沒那麼生澀晦暗，勉強一觀，讓分享和互動成為常态，最後求波關注！！

以待後續繼續分享。

,

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!

查看全部