缺字解決方案牽動漢籍全文資料庫的內部結構和程式工具。首先面臨的問題是究竟組字式應該原封不動的擺進資料庫，還是加以變形？慮及組字式並非唯一，又長度不定、格式稍顯複雜，對緇銖必計的檢索效率略有不利，決定將它轉換成定長的編碼，名為組字碼，格式如下：

<組字碼標><字形資料庫字號>

構字碼標佔一位元組(byte)，它的值有別於中文內碼任一位元組的值，也有別於 ASCII 內碼，以資區分。以五大碼環境論，可定其值為 255。字形資料庫字號佔三個位元組，考慮照CCCII 的做法，每個位元組只用 ASCII 有形(printable)字碼的值，計 94 個，而三個位元組能供應的值多達 830，584 個(94*94*94)，應足敷已知、未知的全部中文字之需。既然字形資料庫是集中管理的，每個字的字號自屬固定，所以構字碼雖是內部所用，仍有交換共享的潛力。

漢籍全文資料庫的程式工具，以資料庫建製子系統及資料庫檢索子系統為核心。這些工具需具備組字式和構字碼的處理能力。此外，如實載錄異體字形的難題，已因組字式而徹底達成。倒是存真之後，同樣的詞夾含不同異體字的情形更普遍，增加檢索的複雜度。譬如：雖是檢索「煙葉」，應將「菸葉」和「火�穧]葉」一道帶出。可惜異體字的判準並非一成不變的，在周延的擘畫出現以前，暫將大體上完全通同的字合為一組，叫作通同字組，並用它來解決部分問題。

資料庫建製子系統讀取標誌過的資料檔，經對照表把組字式轉化為組字碼或內碼，建成全文資料庫，並產生索引來加速檢索。組字碼對索引建構是有影響的。這個索引採用完全逐字反轉架構，記有每個中文、外文字在資料庫內的位址。常用中文內碼的結構固定、總數有限，有別於外文字的長度變動不一、總數不明，所以分開處理。構字碼的長度雖固定、而總數未明，宜比照外文字處理。至於異體字方面，宜把通同字組的位址叢聚在一起，以便循序快速讀取整組字的位址。

資料庫檢索子系統接受使用者的檢索條件、實施檢索並輸出符合條件的資料，組字式對輸入、檢索、輸出三者都有衝擊。在輸入方面，遇到使用者下達的指令含有組字式，便轉為組字碼或內碼。不過，組字式的部件、運算符號有那些? 如何輸入? 對多數使用人而言當屬陌生，需要一種組字式的輸入輔助介面，詳列部件與運算符號，供使用者揀選而組成組字式。再者，組字式無效，必須採缺字序號時，也應有相關的輸入機制。

檢索子系統有兩種檢索機制：經索引檢索或逐字搜尋。前者怎樣因組字式調整，已概略提及。後者若要同步搜尋異體字，可將一詞展開為各種異體字組合，如把「煙葉」展成「煙葉」、「菸葉」、「火�穧]葉」三詞，再做多詞搜尋。

有的同義字幾乎在甚麼場合都互通，像「饑」與「飢」；有的只在特定場合中通同，像「煙」與「菸」出了「煙草」的範圍就不通了。通同字組純就字的範疇考量，難免不周，然而勝於沒有。大體上，凡是檢索兩個字以上的詞彙，就能發揮很好的效果，鮮少副作用。例如：搜尋「煙囪」，檢索機制連著「火�穧]囪」、「菸囪」都找並無妨，「菸囪」本不存在，找不到就是了，而該找的「火�穧]囪」並未遺漏。現階段宜讓使用者調整通同字組，滿足個別需求。