考慮調整資料規格，減少重複資訊
danny0838 opened this issue · comments
目前 Cangjie5.txt、Cangjie5_SC.txt 等碼表有太多重複資料，冗餘度高，修改時要維護多個檔案可能會比較麻煩。
既然現在已經用腳本管理格式化輸出，或許可以考慮調整碼表格式，搭配程式自動驗證，提高效率。
主碼表可維持原狀，註解可考慮統一改用行首 # 開頭，方便程式處理。可考慮統一用 Unicode 排序（另外加一個 Cangjie_Main.txt 定義原 Cangjie5.txt 的排序）。x 開頭的重碼可全部刪除，由 build scripts 自動產生（甚至做成選項決定是否產生，或者不同的重碼選字方式）。
Cangjie5_TC.txt 等檔案只列出有重碼字的部分以定義不同排序，也可以省略標註。格式可考慮改成類似：
a 日 曰
的形式，省得每個字重複輸入相同編碼。
並且用程式自動檢查，確保每個 Cangjie5.txt 的重碼都有定義到，並且每個碼對應的輸出字的集合相等。然後 build script 自動根據主碼表 Cangjie5.txt 及 Cangjie5_XXX.txt 的排序定義輸出最終碼表。
檢查一般可分為報錯型和自動修正型。個人較偏好後者，比較懶人，缺點是程式自動修正時可能把部分寫好的東西蓋掉導致要重寫，不過這只要修改後先 commit 再執行檢查程式和 diff 即可解決，最後再 rebase 整理版本即可。
這樣改碼、改標註時只要不涉及重碼就只要改一個表，應該會比較輕鬆。涉及重碼時，如果是刪除重碼字，可完全交給程式自動處理，如果是增加重碼字，就預設自動加到最後，有需要再個別修改子表。
不過規格改變可能要出 4.0 了。XD
如果有想要這樣做，我可以協助 PR 簡單的腳本 demo。
Cangjie5*.txt幾個檔案是用腳本生成的，我本地有一個數據庫，所以我自己修改的話其實只要改一處。
然後分成幾個txt上傳是為了方便diff（以及原始數據庫存了很多有用没用的標註，相當混亂XD）。
至於scripts裡的腳本，我想以「已有一個完整的txt碼表」為基礎，進行處理。這樣也可以適應補完計劃之外的碼表。
原來已經有在用了XD
如果主資料表也能開源，會比較有利於其他協作者修改碼表或提PR，增進交流上的便利。
至於diff之類，想解決的話其實不難，只要更改主資料表時執行 script 輸出完整碼表至特定路徑即可，甚至可以寫到 pre-commit hook 做自動化處理。同理其他 build script 也是抓前面輸出的完整碼表處理即可。
簡單來說就是像這樣的架構： 主碼表+排序碼表 ==腳本==> 數個完整碼表 ==腳本==> RIME等平台的碼表
不過，當然，是否開源還是取決於你。
Binary file很難版本管理。多人協作的場景下，有人修改了db的內容，其他人完全看不出是甚麼改動（改動未必立即反映在輸出的txt檔）。
覺得GitHub上的內容還是以txt為起點會比較好。
我覺得還是要看實際目的，如果不是像架伺服器有隨機、頻繁、即時存取的需求，且資料量大，DBMS 相比文字檔不見得有明顯優勢，那其實是可以考慮直接用 tsv 或 csv 之類的格式，可以直接當文字檔編輯或用 Excel 或 LibreOffice 當表格編輯。其實上面提的格式基本上就差不多是 tsv 或 csv 了。
如果還是需要直接操作資料庫，可考慮雙軌並行，就是寫個可以無損匯入匯出資料庫的腳本，把匯出的資料放進版本庫。只是每次操作要記得重新匯入、匯出。