怎麼去實現一個簡單文本編輯器？

如何去實現一個具有複製，粘貼，刪除的簡單的文本編輯器呢？

我想從比較底層的地方開始編寫一個簡單的文本編輯器，比如游標，文字選擇，分行都由自己實現的，現在遇到的問題是不知道如何去管理（處理）這些文字數據（應該屬於數據結構的範疇），比如說刪除某行的幾個字元或者插入字元後，內部數據怎麼處理，是怎樣一種演算法？

我現在對如何去實現這樣一個東西，完全不知道如何下手？求各位答主大神支招！！！

---

這是一個大坑... 跳坑多年仍然沒出來.

The craft of text editing 講得比較全了, 我再補充一些.

編輯器大致分為源代碼編輯器和富文本兩種.

源代碼編輯器為了省事可以設置相同的行高方便計算, 不過現在多數支持變化行高了可以從富文本編輯器開始做.

首先, 挑一個 GUI 框架

跨平台的 GUI 通常很吸引人, 例如 Fox, FLTK, Tk, GTK+, Qt, WxWidgets 等, 大部分都有一個編輯源代碼的控制項, 而這個控制項基本是 Scintilla 之上的包裝 (再研究 Scintilla 你會發現其實各種 GUI 框架的編程模型包裝都不需要, 按照 Scintilla 的設計去用就可以了). 學習下來你會發現各個 GUI 框架都自帶一個特別的觀感: Fox 的游標是個不可改變的巨型鐵軌截面, wxWidgets 盡量模仿原生組件 (E-texteditor 就是用 wxWidgets 做的), GTK 就盡量自己畫... 其編程模式實質差異並不大, 因為都是 C 和 C++ ... 最慘的是在 Windows 看著還可以, 一放到 Mac 就覺得丑爆了. 做了其他語言的綁定還是感覺在寫 C 和 C++. 當然也有做得不一樣的:

• Tcl/Tk 最簡潔

• REBOL view 最 fancy

• Paul Graham 最推崇 Arc

另一大類 GUI 框架是 XUL. 寫個 XML 界面, 然後在 XML 界面上畫東西. XHTML+JavaScript 就是一種 XUL 方案. Sun, 很小很柔軟, 摸斯拉 等等大公司都推過自家的 XUL 方案. 然而 XML 根本就不適合人類編寫, 作為 model 格式也過於巨大不好維護. 最初魔獸世界的插件也是推薦 XML 寫界面然後綁定 lua 的動作, 但由於太不靈活也沒有一個拖控制項的界面, 所以玩家開發了 Ace 系列的 UI lib, 完全不用 XML 純用 lua 寫了. 拖拽式畫界面只能騙騙小朋友, PaintCode 也比 XML 解釋器性能更好, 所以現在 XUL 基本絕跡, 連直接用 HTML 寫界面都不時髦了.

如果不跨平台, 用圖形操作系統的 GUI 框架會更能解決很多實際問題, 性能也有保證. Win32API, MFC, ATL, WinForms, WPF, Carbon, Cocoa, CGContext, CoreText ... 就是操作系統商人心狠手辣變幻無常, 一心搞個大新聞還處處夾帶私貨, 一路學來也是挺累人的. 另一方面嘛 X11 這種更難學, 我就卡在了 motif ...

雖然跨平台的 GUI 框架在慢慢衰亡, 但 OpenGL 這類更接近底層硬體的圖形庫給人類提供了新的希望. 利用 OpenGL 的成功案例就有 Sublime Text. 我覺得 Cairo, SDL 這種半 GUI 框架的高性能圖形庫是比較適合的, 就是用的人少了點.

鑒於圖形化界面的巨坑... 何不寫個純命令行的編輯器呢? 這時候我們有各種行編輯庫可以用: readline, libedit, termcap, Antirez 的輕量 linenoise ... 再用腳本語言的話, 由於內建正則語法和一些字元串處理函數, 很容易在一兩萬行內寫個功能齊全的編輯器解決戰鬥, 例如 Daikonos.

就算用 C, 如果只實現最簡單的功能, 1024 行以內也是可以的: Writing an editor in less than 1000 lines of code, just for fun

純字元界面缺點也很多, 平滑滾動沒有, 動畫高亮沒有, 文字顯示揪細點想調個 kerning 啊 ligature 啊也沒辦法. 那就自己做一個圖形框架? Eclipse 就自掘巨坑組合 C++ 和 Awt 搞出個 SWT. 其實 Awt 和 Swing (NetBeans, IntJ 都是基於 Swing) 處理 Unicode 都有大量的坑, 我都不喜歡... 曾經有個我關注的編輯器 Redcar, 最初用 GTK 編寫, 後來轉成了 Swing, 然後逐漸就做不動了... jEdit 作者棄編輯器坑, 後來挖了個基於棧的語言新坑 Factor. 後來? 後來也不搞了...

現在 GUI 基本被 ES 的大流統治. 用 Web 做編輯器可以做出一些非常棒的用戶體驗, 現在瀏覽器引擎也優化得比幾年前好太多. Atom, Monaco Code Editor 都是在 Web 上做的成功案例. 為了容易上手估計 ES 是首選. 缺點是某些細的 UX 不好實現, 正經的優化會花掉更多時間 (例如 Monaco 為了分析性能點連 IR Hydra 都用上了).

介紹兩個 Helloworld, GUI 框架 + Scintilla 實現常見一個編輯框

基於 FxRuby 的:

require "fox16"

include Fox

app = FXApp.new
window = FXMainWindow.new app,
"My Editor",
nil, nil, DECOR_ALL, 100, 100, 710, 550

sci = FXScintilla.new window,
nil, 0, LAYOUT_FILL_X|LAYOUT_FILL_Y

app.create
window.show
app.run


基於我自己寫的 GUI 框架的就更簡單了 (誰不年少輕狂造過幾個 GUI 框架輪子?)

require "cici"
app = Cici.app "scintilla"
c = app.paint [600, 600], Cici::ZoomLayout
c.scintilla [500, 500]
app.message_loop


其實還有各種 GUI 框架的編輯器 hello world 都差不多, 但用框架就是跟著別人走, 很難做出更好的用戶體驗.

如果從更底層點的地方開始, 例如 Win32API 和 Carbon, 站穩腳跟學習圖形界面編程, 前面的道路會... 更狹窄 (公司剛裁了很多桌面程序員並對 Web 產品加大投入...). 不過你理解事件模型的實現和常見優化手段以後, 就算編輯器不成功, 也可以自己寫個遊戲引擎玩玩嘛.

然後, 挑一個 text storage 數據結構

例如 Cocoa 就自己提供了一個 NSTextStorage, 自己造大約有幾個主流選項:

• Gap buffer: 例子有 Emacs. 很簡單的數據結構, 游標前一個 buffer, 游標後一個 buffer. 能極大的減少 buffer 重新分配次數. 擴展一下變成 multi-gap buffer, 多游標編輯也很流暢.

• Chain of lines: 例子有 TextMate. 每行一個 buffer, 一行不拆散. 對壓縮的文件高亮時會比較卡. 但是可以和功能強大的正則引擎 Oniguruma 完美集成.

• Cell buffer: 例子有 Scintilla. Cell 大小固定, 如果一行超出 Cell 的固定大小, 就分拆成多個 Cell. 用過 Scite 或者 Code::Blocks 或者 Notepad++ 等會發現, 打開大文件, 高亮都還流暢, 因為 Scintilla 的 Cell buffer 和重繪計算的效率很高. 但由於拆行, 只能集成 input driven 的功能較弱的正則引擎或者 lexer, 而這會對實現很多功能帶來麻煩.

• Zipper: Immutable 的數據結構, 如果用 Haskell 做後端會非常適合. 同時還能順便實現樹形歷史.

text storage 到界面顯示之前, 需要一個排版引擎. 最簡單的排版引擎就是把顯示區域等分成很多格子, 把等寬字元直接填到格子里 -- 但是這並不好看. 一個文本框的顯示得考慮:

• 如果當前字體包含這個字元不? 是不是從別的字體里找替代?

• 這些字元組合起來佔多寬和多高? 會不會被上面和下面的行擋住? 注意字元的組合併不等於它們的寬度之和, 你要理解 kerning, ligature, baseline 等等 type setting 概念先.

• 當你排好看以後, 排版的效率往往就不能保證了... 優化也是很難的.

在瀏覽器里有一套默認的設置, 還有 font-kerning, letter-spacing 等 CSS 屬性的幫助, 處理這些問題要簡易很多.

text storage (文本模型) + text container (排版引擎) + text view (顯示引擎) 是不是就夠了呢? 你還得考慮輸入法和文字方向... 這一塊光看文檔是不夠的, 自繪的文本輸入框, 連很多大廠都沒把輸入法兼容好... Windows 的 input method editor 和 Cocoa 的 NSTextInput 都能讓你抓狂很久.

然後, 考慮一下語言模型...

很多瀏覽器的文本編輯框里可以用中文詞為單位移動游標 (ctrl + 方向鍵 / opt + 方向鍵), 這是怎麼實現的呢? 有個庫叫 ICU, 裡面提供了很多邊界分析(分字分詞分句)用的函數. 瀏覽器就是用它實現的. ICU 甚至提供了多語言的排版引擎.

如果你要做智能提示和自動完成... 所謂智能提示往往並沒有那麼智能, 不如參考 vim, 用更依賴用戶主動性的設計, 把自動完成的快捷鍵分為 line complete, dictionary complete, omni complete 等等, 給程序一個更 specific 的指令, 它就能完成得更精準快捷.

但現在的主流是被動性編程, 編輯器/IDE 給你一堆選項, 讓你挨個選... 實現這類型的智能提示, 你得寫很多代碼把語法/類型/先驗知識編進去. 而提升智能的方式是, 分析當前的 skip-gram 中最高概率出現的詞, 把它排到更優先的位置去 --- 所以先學點計算語言學, 把 word2vec 玩熟吧.

------

除了上述幾個大的 design decision 以外, 還有很多很多設計和編碼的 Topic 可以講...

• 模塊和插件機制 -- 正面例子有 Atom 的插件機制, 反面例子有 Osgi...

• 協程/線程調度後台任務

• 動態編譯和 shader

• 集成腳本語言 -- 可以方便組合功能和實現插件. 例如 Emacs 有 elisp, Vim 有 vimscript/tcl/perl/python/ruby/mzscheme, Scite 有 lua. 執行腳本時要考慮隔離, 又不影響界面的重繪. 語言特性對編寫插件影響巨大, 專門設計一個語言是有很多好處的.

• ...

當初我只是想用趁手的編輯器寫篇博客而已, 好幾年過去了, 現在都還在寫腳本語言... 所以請慎重跳坑...

---

文本建議用persistent的數據結構存，一來做undo/redo方便，二來做非同步操作（例如調用外部工具）方便，不需要阻塞（望向vim/emacs等一些插件）。rope這個數據結構是個例子（Rope (data structure)）。或者這種 GitHub - martanne/vis: a vim like text editor，另外這個項目其實是不錯的參考，純文本單窗口vim-like，C+lua，開發還算活躍。

現成的GUI組件里，我認為gtksourceview是最好的。看文檔 GtkSourceView 3 Reference Manual: GtkSourceView 3 Reference Manual ，buffer、語法高亮、自動完成等等功能都有了。感覺比scintilla要現代一些。

其中的GtkTextBuffer可以獨立拿來用。GtkTextBuffer: GTK+ 3 Reference Manual ，基本的編輯功能就有了。不過這塊不難實現，自己做可能更適合需要。

如果想自己渲染文本，可以用pango（Introduction ，一個文本排版和渲染的引擎。和gtksourceview一樣是GTK項目里出來的。配合cairo（cairographics.org）或者skia（Docs，chrome、Android、Firefox都用它）這些繪圖引擎，就可以隨便畫了。cairo和skia都自帶硬體加速，不用自己管OpenGL之類更底層的。文本排版這類問題已經有成熟的庫了，沒必要自己閉門造車。

或者直接用HarfBuzz（HarfBuzz。雖然是pango的一個後端，但似乎可以替代pango，之前沒有留意到。

還有一個方向是用webkit這類引擎做，例如atom和vscode，不過整個技術棧太高層，難免臃腫，而且也受限於web技術本身的表現力和js環境的缺陷，沒意思。

---

GacUI/GuiTextControls.h at master · vczh-libraries/GacUI · GitHub

---

挺難的，比如說，你要在一行裡面同時寫天城文和阿拉伯文，排版和游標移動的處理就能搞死你……

這麼說吧，你按一下[→]，對於複雜文種來說游標極有可能跳過不是一個字元，甚至會因為 RTL 覆蓋的緣故向前跳。

給你說個最簡單的例子吧，游標在這個位置

的時候，它究竟是在「以色列」（??????????）這個詞的前面（England 之後），還是後面（該行的末尾）？

---

https://github.com/jonathanslenders/pyvim

pyvim

---

這有什麼數據結構的……不就是從字元串當中刪掉一個子串嗎……

content = content[:sel_start] + content[sel_end:]

除非你這個編輯器編輯的內容非常大，比如說有好幾個GB，才需要考慮效率問題。

---

首先，非常贊成你選取這個課題進行研究，因為一個好的文本編輯器需要非常好的模塊規劃以及局部的性能追求。

文本編輯器的核心，並不在於文字本身，而在於對密集且大小不確定元素的排版。

無論是顯示，還是你說的字元刪除操作，核心都在於，高效，準確的排版。

開發的大概思路：

1，「密集且大小不確定元素的排版」，把這個定為開發目標的基礎，這樣可以在不增加開發成本的情況下將後續工作提升一個功能性的檔次。

2，基於我們的目標基礎，核心功能應當圍繞，準確，高效的排版開展。

3，結合1,2點先寫出一個可以正確排版顯示元素的基礎，這裡需要注意，一切高效率的操作離不開合理的緩存，這一步你要考慮好如何緩存，才能方便排版，以及後續的交互判斷。

4，逐步加入點擊，拖拽選取，視圖滾動（滾動條）的交互處理。

5，最後再加入你上面說的，刪除，複製等功能。

* 不要小看百八十個字，高效布局不容易。

*我覺得，初學者實現一個，比看懂一個要容易。。。

大致是這樣的，如果你在學習階段，強烈推薦你一定把這個課題做透，你會受益匪淺的。

並且，記住這個課題，過些日子，再寫一遍，你會有更多收穫：）

---

本軟體為了提高用戶體驗，需要要在最壞的情況下依然能快速響應，必須提高軟體的運算效率。為了達到此目的，先粗略進行一些數值上的估計。現以&<&<三國演義&>&>作為例子，該小說大概有80萬字。如果按每行平均30個字元來計算，小說不到30000行。如果用普通數組表示這篇小說的文本，在小說頭部添加和刪除一個字元的話，則需要移動80萬個字元，因此必須採用分塊處理的方式來減少數據移動。如果其他抽象不變，僅把文本表示由普通數組改為按1000字每塊進行分塊，則小說文本可以分成800塊，添加和刪除只在塊上進行。在小說頭部添加和刪除一個字元，僅需要對前面少數幾塊進行數據移動操作，後面的數據塊只需要改變塊的在文本中位置下標索引。這樣減少了大量的數據移動操作，而代價僅是額外少量的內存代價以及少量的形式變換。

文本按行進行布局後如果又發生了變化，則不影響發生變化的地方前一行之前的文本的布局，也不影響發生變化的地方的下一個段落之後的文本的布局，而僅需要改變行的行號以及在文本中的位置。且常見的文章都是按照段落組織文章的，因此這個優化相當有用。

以分塊組織文本，文本變化後僅進行局部布局，進行這兩步優化後雖然依然剩下不少的計算量，但是實際測試中發現已經完全夠用，就沒有繼續優化。

自己搞的簡單的文本編輯器的設計思想。

但也有他的局限性

本軟體僅處理較簡單的常規布局，即較長文本分為多行排列，行內字元從左至右排列，行高固定，行與行之間由上到下排列（與Windows里的Notepad選中「自動換行」後的布局一致）。

---

Lab 5 | CS 61B Spring 2016

Project 2 | CS 61B Spring 2016

可以參考上面這個指導文檔，你需要的功能都有說明。該怎麼實現也說的很清楚，你只需要寫代碼。

---

文本編輯器一向是比較難啃的骨頭。基本上，modern 一點的文本編輯器架構基本是由 View、Storage、LayoutManager組成的，如果只考慮純文本的話，也就是像記事本那樣的程序，Storage 基本就可以直接由 String 代替了，因為不涉及到格式化和大文本的問題。富文本拍版我沒有研究過，但是對於純文本來說，布局相對容易很多了。所以簡單說說純文本。

首先，數據結構就不建議你自己造輪子了，字元串類就可以用。但是 String 一般是 immutable 的，所以頻繁操作會有性能問題，不過初期時問題不大，建議這塊留出介面後期再優化。

然後說渲染部分，Key points 就是測量每個字元，計算出一行的長度，然後進行分行，如果考慮自動換行會複雜些。分好行後直接拿到繪圖 API 中 drawString 即可，對於選中的文本，你可能還要用反色去再 drawString 一遍。基本就是這樣，當然性能問題也會有，對於不在 viewport 里的行，需要計算出來然後跳過那部分的 drawing。

---

好像答錯了問題……語文沒有學好啊

答案還是留著吧，也算我這個學期沒白學vb，留個紀念吧，

我這個學期學的vb對於做這個文字編輯器很容易，

1，下個vb軟體，（大概是vb6就好）

2，找幾個控制項放進工程里，像text啊，按鈕啊，要是想複雜一下自己可以設置，多學習一下就可以了…

3，運行程序，

end

vb很簡單的，比c語言簡單多了！！

---

剛畢業的時候接手過一個帶各種工程符號的文本編輯器。

富文本，undo、redo，回頭想想，那時候還是很有耐心的，1萬多行代碼折騰了半年多

---

@Zete 大大大而全地解釋了做一個文本編輯器的outline，讓我大開眼界，我就說說如何在瀏覽器裡面實現一個類似ACE Editor或者CodeMirror之類的編輯器吧。

首先還是要選一種數據結構吧，我個人建議還是Chains of lines數據結構，因為實現起來還是很簡單的(VSCode, CodeMirror都用)，當然有升級版本，參見CodeMirror的數據結構：CodeMirror"s document representation，另外Rope也不錯。

話說第一次看到CodeMirror這種在瀏覽器裡面實現的編輯器是感覺簡直驚艷，因為我沒想到瀏覽器居然提供了這麼豐富的API，後來下載源碼一看，發現原來不是用API實現的，而是自己畫了一個出來模擬的。也就是說，游標，滑條，都是畫出來的，不是瀏覽器原生的。

當你在CodeMirror輸入的時候，其實是下面有一個隱藏Textarea跟著你的游標一直走，然後實時把textarea的內容更新到數據結構，再通過Lexer或者Parser上色渲染到Html頁面上。當你在html上點擊的時候，用Js計算出對應的位置，然後把游標移動到那個位置，你所看到的游標其實就是一個黑色的div。這種思路同樣也很有趣啊（VSCode也是這樣實現的），不過在瀏覽器這種這麼樸素的API下面，要模擬出來也不是一件簡單的事情，比如你要處理輸入法的問題，選擇區域的問題，瀏覽器不支持的事件你要做臟檢查，滑動的時候要實時渲染要展示的內容從而避免文件過大的時候佔用過大資源……詳細內容參見Marijn Haverbeke大大的文章：

Faking an editable control in browser JavaScript

另外奉上中文版：blog.diverse.space 的頁面（小弟不才）

還有一篇

Cursor motion bi-directional text

讀完大大的文章，應該也可以在瀏覽器擼一個編輯器應該就不是難事了，我也擼了一個，但是仍然有一大堆坑等著我去填，特別是面對不同瀏覽器不同的（文明）API的時候。用瀏覽器或者類似的技術實現一個文本編輯器有一個好處就是不用管排版引擎，可能在和用戶交互方面要考慮得多一點。其實隨著Web技術得發展，用html配套得技術實現文本編輯器已經變得越來越簡單，比如輸入法的問題可以通過composition相關的API來解決，不用再去做臟檢查，擔心瀏覽器不觸發相應的事件。其實CodeMirror為了兼容不同瀏覽器做了很多工夫，甚至犧牲了一些效率。當我們在實現自己得編輯器的時候，我們可以只針對最新版本得瀏覽器，這樣就可以省下不少工夫。

---

沒那麼難。自己作為練習，寫過一個，同時支持文本編輯和二進位編輯，代碼高亮摺疊，undo/redo，選定拖等，簡要說下。

第一，破除神秘性。看到的可編輯界面其實是完全不存在編輯的。直接就死內部數據結構畫在編輯區的。用戶的編輯操作觸發對內部數據結構的更新，然後重繪編輯區就行。為了避免閃爍，需要仔細考慮那裡需要重繪。

第二，對於普通的文本文件，按行來存儲就行，直接對應到編輯區的一行。所以一個文件對應到內存結構就是一個簡單的字元串數組。如果想支持超大文件編輯，考慮的就多了。如果是要語法高亮，需要先定義高亮規則，然後根據規則解析每一行，生成輔助信息。繪製每一行的時候就需要一塊一塊來。

第三，編輯點的位置可以直接根據編輯點之前的字元計算出來。儘管非等寬字元看起來不好處理，但是有庫函數可以方便調用獲取寬度，基本不用自己處理。

第四，選定的文本和非選定文本的區別就是前景色和背景色的不同，對應的可編輯操作也有差異。但是理解了第一點，其實都不是難事。

差不多就這麼多了吧。有了基本編輯操作，複雜的就是高級編輯功能的支持了，但是萬變不離其宗。

---

別看是基本應用就覺得簡單，能自己實現了文本控制項就秒殺大部分程序員了

---

工作相關，最近剛好做三維渲染引擎中的富文本編輯器。如前輩所說，這塊的坑的確挺大。從底層的數據結構到段落排版，縮進，換行斷詞等定義，到編輯插入刪除等操作，再到離散化，渲染，到國際化支持。每一塊深究都是坑坑相連。如有需要一起研究的歡迎私信交流

---

做那個幹啥呢 ？ 其實你堅持不了那麼久的 。

---

xul + Scintilla,框架可以採用他山界面開發，他山界面通過內嵌gecko v1.9~v52,實現跨平台混合開發應用，可以使用xul,xbl,html(5),css(3),js,c++/java混合開發界面，目前支持xp,win 7,8,9,10+ 32/64系統，linux, android 4.0+.OHUI v22 13MB(linux 21MB), OHUI v45 for android 23MB.

---

這是一個『巨大的』坑。

首先，恭喜你選擇這個項目主題研究，這個主題若要從頭開始寫，的確很難。

答主今年初一，從五年級開始寫一個編輯器，斷斷續續寫了三年，從Windows轉到Linux，從Turbo C轉到純C。最後，今天終於製作完成了一個功能極為簡單的Linux終端下的純C語言文本編輯器。功能只有：讀取文件，寫入文件，還有簡單的加密。

先寫一下過程：

剛開始『年少輕狂』，直接用二維數組寫，游標可以亂跑，調試了很長時間，只能編輯24行80列。後來，增加了一個加密功能（基本功能還為實現，就去加密……）。直到上個寒假，才做到300行滾動編輯。實際上，這個編輯器還不是完善的，你要是想在中間插入文字，它會覆蓋後面的字元。今天，花費總計9個小時，代碼通體改了一遍，將二維數組換為一維數組，實現了插入。但是，因為個人的水平所限，在更改設置的情況下最多只可編輯100000個字元（包含轉義符）

在總結一下經驗：

1. 不要小看VB中的文本框控制項之類的，實際上，你不依賴任何函數庫，從底層實現十分困難。

正如上面的幾位所說，你所看見的可編輯的部分是不存在的，要自己編寫，重繪屏幕。

2. 不要『發明輪子』就像答主，年少輕狂地使用二維數組，改起來頭疼那可不是一般的可怕。

3. 思路要清楚，這個不用說了

4. 要平靜，寫編輯器，你會遇到各種游標亂飛，或者在第二行輸入，卻在第三行顯示

最後，附上下載鏈接（Linux源代碼+Linux可執行文件）：https://lexuge.github.io/download/LEDIT.zip

---

首先說一句：文本編輯器是一個巨大的坑。然後慢慢填。

文本編輯器的實現從上到下可以分成三層，即應用層，負責向用戶提供菜單滑鼠鍵盤響應載入的功能入口；GUI層，負責上述功能的實現；GDI層，負責實現具體的服務。造文本編輯器主要功能在於實現後面兩項，我們一般可以把這兩部分別叫做文本控制項和文本引擎。為了我們實現的方便，我們下面從下向上開講。

=======文本引擎

文本引擎負責實現的功能有基本文本顯示，文本編輯和游標支持，以及文本剪切板。

文本顯示需要將一串由整數表示的文本轉化為屏幕上的圖像，過程包括字元串處理，字元數據的測量，文本整形處理，文本雙向處理，斷行處理和排版處理。從數據結構上講，需要有邏輯上的數據和顯示的數據以及將兩者關聯起來的中間表示數據。邏輯數據是字元串，以及將其分散處理的各種run或者item；顯示數據則包括字形ID的列表和坐標數據；中間數據則包括行，段落等等。這些數據都是數組或者用vector容器，物理實現上就和各自的實現相關了。這個數據容器的效率從數量級上確定了編輯器的性能。

---

推薦閱讀：