調整詞典規格為 `輸入詞\t輸出詞1\t輸出詞2\t...` 以支援含有空格的轉換詞

[danny0838]

目前的規格主要是輸入詞\t輸出詞1 輸出詞2 輸出詞3 ...，這樣的格式導致輸出詞不能含有空格，否則會被判定為二個輸出詞而截斷。

這導致使用者無法自訂含有空格詞組，降低 OpenCC 作為通用性工具的能力。

含有空格的詞組可能在以下情況被使用：

1. 含空格外文語+中文詞，例如：

   • Visual Studio插件 → Visual Studio擴充組件
   • 3C Weekly资讯电子周刊 → 3C Weekly 資訊電子周刊
   • 二維碼 → QR Code (增加新词条，内容带空格，转换后结果不对 #376)
     由於不支援空格，只能用不精確且容易出錯的 Studio插件 → Studio擴充組件 等等。

2. 含有簡單數字或英文的詞，如：

   • B 型肝炎 → 乙型肝炎
   • 1 只鸟 → 1 隻鳥
     目前寫法只支援 B型肝炎 → 乙型肝炎，對於中英文之間有插入空格的文本就無法正確處理。官方詞典不一定要有含空格的詞條，使用者可以透過腳本自動補上含有空格的詞條，但目前會受限於 OpenCC 的架構而無效。

3. 某些含有空格的中文文本，例如：

   • XXX 著 → XXX 著 (單字「著」的繁簡轉換 #963)

建議把規格改成標準的 TSV，即 輸入詞\t輸出詞1\t輸出詞2\t輸出詞3\t...，應該就能有效解決此問題，缺點是會犧牲向下相容。

也可以考慮支援 TSV 常用的 " 及 "" 脫義格式以支援全字元，但如果引進了上述更新，需要處理的特殊字元應該只剩下 \t、\r、\n，這些都不是一般預期文本會使用的字元，反而引進 " 跳脫會導致語法解析更複雜且導致含有 " 的詞不易編寫，可再商榷。

[frankslin]

近期和 @BYVoid 讨论得出两个结论：

1. OpenCC 项目作为一些输入法项目的上游，如果改 txt 字典格式，可能会破坏下游使用方式，故需要非常审慎；
2. 大部分贡献者修改内容仅限单行词库，为避免出错，算法改动也要格外谨慎，避免引入破坏兼容性的复杂格式要求。

[danny0838]

能否像以前引進 .ocd2 時一樣，讓 dict maker 增加支援一種 .txt2 的格式（甚至也可以加上 .txt3 支援 " 脫義），對於直接呼叫 OpenCC 轉換 API 的程式，反正都是直接讀取 config，應該不會有影響；而且 config 目前都是用 ocd2，即使官方 dictionary 更改 txt 格式應該也不太容易造成影響。

會讓使用者自訂詞典的專案，使用原本的呼叫方式也還是當 txt 讀取。

[frankslin]

我想，最大的问题还是这个「新格式」解决的问题（支持带空格的中文词汇）是不是值得引入一个 breaking change，这是一个见仁见智的问题。还要说服下游的社区，统一换用新格式来维护词典/词表（否则任何提交到 OpenCC 的改动都需要改两遍）。

如果真的要引入新文件格式，并且允许不考虑 backward-compatibility 的话，可以激进一点直接直接用一个更严格的格式（例如 JSON，也可以考虑 YAML），会比「txt2」的描述性更强。

当然，对于 private fork 而言，怎么改都无所谓了。

[danny0838]

所以我說可以考慮用新增格式的方式處理，這就不會是 breaking change，只要 config 沒特別指定 type=txt2，或者 make dict 不用新參數指定 txt2，就還是照現有規則進行。

可能造成 breaking change 的應該是官方詞典全面改成 txt2 格式，我想其他專案自訂 config 引用官方 txt 詞典的可能性應該不大（大多會引用 ocd2），比較麻煩的應該是如果做了這改動，現有的 PR 都要重寫成用新格式，如果擔心的話這部分可以暫緩。

以上是假定 ocd 和 ocd2 能支援含有空白的轉換詞，如果不行，那就可能要再搞個 ocd3 了。

至於 json 和 yaml 其實我之前就有建議過可以增加支援，可以提高與其他專案的互用性，但是和現有格式差異較大，要改寫 sort, merge 等腳本支援也不容易，可能當做另一個 bonus feature 比較適合。

[danny0838]

進一步分析幾個方案：

text2 （\t 分隔）：

• opencc_dict 的 --from 增加支援 text2 格式
• data/config/*.json 增加支援 text2 格式
• data/scripts/*.py: sort.py 等腳本增加參數指定輸入格式，或要求 text2 格式一律用 .txt2 然後根據副檔名自動辨識（補充：目前 sort_all.py 只會辨識 .txt，但其他腳本沒有）

text3 （\t 分隔並支援 " 脫義，" 本身用 "" 表示）：

• 大體上同 text2，但解析較複雜，可能需要引進依賴專門的 CSV/TSV parser
• data/scripts/*.py 等腳本要支援註解處理會很挑戰，而且註解和含有多行內容的轉換詞混排其實也不友善

json （{"輸入詞1": ["輸出詞11", "輸出詞12"], "輸入詞2": ["輸出詞21"], ...}）:

• opencc_dict 的 --from 增加支援 json 格式

• data/config/*.json 增加支援 json 格式

• data/scripts/*.py: 可能無法支援。一是 JSON 本身不支援註解，二是一般 serializer 輸出會變成這樣：

  {
    "輸入詞1": [
      "輸出詞11",
      "輸出詞12"
    ],
    "輸入詞2": [
      "輸出詞21"
    ]
  }

  要處理成對人比較友好的：

  {
    "輸入詞1": ["輸出詞11", "輸出詞12"],
    "輸入詞2": ["輸出詞21"]
  }

  需要比較複雜的處理。

yaml （{輸入詞1: [輸出詞11, 輸出詞12], 輸入詞2: [輸出詞21], ...}）:

• opencc_dict 的 --from 增加支援 yaml 格式

• data/config/*.json 增加支援 yaml 格式

• data/scripts/*.py: 可能無法支援，理由和 JSON 一樣是處理後要友善輸出不容易，此外需要安裝第三方 yaml 庫。

  一般 serializer 輸出會變成這樣：

  輸入詞1:
  - 輸出詞11
  - 輸出詞12
  輸入詞2:
  - 輸出詞21

---

綜上所述，個人比較建議的方案：

1. 增加支援 text2 格式為主
   • 官方詞典可暫不更改，等評估好相容性衝擊後再決定是否更動
2. 可以也增加支援 json 和 yaml，但大概就純粹給使用者自行處理資料，不提供自動排序等維護工具，官方詞典也不需要使用此格式。
3. text3 複雜性偏高且實用性偏低，很想支援此類狀況又不想引進 json/yaml 再考慮

[danny0838]

查了一下，opencc 安裝時只會建立 config json 及引用的 ocd2 檔案，並不包含 txt。既然不會有下游的專案直接引用官方的 txt 詞典，即使官方詞典全部改成 text2 格式，也不太會造成影響（只要不更動 。

而 data/scripts/*.py 也不會在安裝後使用，如果純粹視為維護內部資料檔的腳本而並非公共 API，如果官方詞典全面改成 text2 格式，這些腳本也可以直接改成只支援 text2 格式就好。