對音韻地位「分析體系」的反思，以及 v0.14 的設計變動

[syimyuzya]

上週和 @untunt 給一個《廣韻》諧聲系整理的資料表的中古音韻地位做了一遍翻新，率先用上 v0.14 對應的新版音韻地位體系（目前暫稱「v3」體系）。過程中意識到了「分析體系」及「適配」相關功能的種種問題，此處要講的設計變動也是因此而產生。

回顧 v0.13 和 v0.14 截至目前在「音韻地位體系」方面的設計

v0.13：

• 放寬 音韻地位 的建立限制，之前 v0.12 限制「等」「呼」必為 null 的場合，v0.13 不再限制
• 引入新的 nk2028 標準分析體系，稱「v2」體系，內置資料均用該體系
  • 該體系比起之前的「v1」體系，額外區分出蒸幽韻B類、陽韻A類，以及除「地」以外的其他一些端組二三等；其中蒸幽韻重紐對立，是之前幾家體系均沒有的
• 引入「v2ext」體系，基於「v2」但能與poem字音表、韻典等其他家地位各自做到一一對應，不損失對立（也能雙向互轉）。推導方案等也均限用 v2ext 體系範圍內地位

v0.14

• 調整標準體系：部分聲韻的「呼」「重紐」有改動，以及合法地位判定更加嚴格
• 取消 適配分析體系 那樣的任意體系間轉換，精簡為僅可由其他家地位轉為 ext 體系地位，再進一步轉為標準地位

發現的問題

未突出「v2」體系

除了內置資料外，並沒有在其他方面突出「v2」體系，而是把各家地位放在一起並允許互轉。

v0.14 截至目前的做法是不再支持雙向轉換，精簡為只准單向由其他家地位轉換至自家地位。但這樣仍無法解決另一個問題：

有損轉換有害

unt 最近對體系間轉換這個設計的一些意見，幾乎都直接指向從別體系轉換而來的（會缺失一些區分或者區分不當的）「偽 v3」是有害的這一點，正如「樸素的（甚至不那麼樸素的）簡轉繁方式轉來的偽繁體是有害的」一樣。從其他體系轉換，幾乎一定會受損，而且即使暫且不論其他資料因完全不分一些對立導致的混淆，有些邊緣地位，別家雖然區分但區分得不恰當的（如「爹」「打」的端知問題），更幾乎不可能簡單地處理。

事實上這樣的事已經發生一次了：切拼輸入法最初的那一版，它就是從嚴拼表直接轉換來的，該區分的（比如蒸幽重紐）沒有，或者區分方式不當（如端組二三等）。當時咱們花了不少工夫（過程中法師娘甚至搞出了一個「各家審音差異對照」的系統）才大幅修正了它的審音（並給出了轉換後同音小韻字的列表以供備考）。

新的設計

既然體系間轉換容易致使混淆，那還不如就不提供「看上去容易用」的轉換功能。音韻地位 對象就可以專用於單一的自家體系（或者換個角度說，只有標準體系音韻地位可以建立 音韻地位 對象並享受其所提供的完整功能），建立時也會用上更嚴格的合法性判定。其他體系地位（包含六要素的任意 object）則僅能獲得較受限的一些功能支持。

至於「ext」體系，它除了用於「比較各家審音差異」外，其實作用並不大，也不能達到預想的「一括包含各家對立」的目的（尤其當兩邊體系雖然都區分某項對立但分法不一樣時）¹，還並不能如實呈現那些資料中的地位面貌（如「諄」韻只能表達為「真韻合口非B類」等）。既然作用如此受限，那麼其實它可以不用包含在標準功能裡，而是額外在單獨的項目裡做（當然 Qieyun.js 這邊的 API 可以多準備準備）。至於功能更強的（比如支持多對多區分）的更靠譜的地位「轉換」或「對應」，也可以等之後有需要時再做。

這樣的話，nk2028 的各主要項目就可以在單一的音韻地位體系上建立，減少不必要的複雜性。而實在有必要處理特別的音韻地位時，再用專門的代碼去處理它就好。尤其比如推導方案，本次更新後，通常情況下推導方案將僅能用於自家體系，不能用於別的體系。當然，僅利用上面所述「受限支持」的功能，強行寫推導方案也並不那麼複雜，但需要做這種事情的代碼，以後只會越來越少，而且對標準體系地位和任意地位用不同的寫法，也能明顯地「防呆」。（甚至可以說「防呆」「防混淆」是採用單一體系且 音韻地位 更嚴格的第一原因！

按照這樣的想法，v0.14 的設計需要以下改動：

• 音韻地位 移除「導入」「正則化」等相關功能，恢復「驗證」（但 API 可以適當調整）
  • 「導入」之後會分離出去成為獨立項目
• 「驗證」會更加嚴格，不再允許「強行切」的地位
• 為非標準體系地位（包含六要素的任意 object）提供弱化版的、功能受限的「基礎驗證」「屬於」「判斷」三項功能（目前計劃僅提供這三項，而且它們不會被 doc）

Footnotes

1. 與之平行的是，異體字自動化處理領域經常被提出的「能分則不合」正字法，也受同樣的現象所困，且更嚴重 ↩