傳統蒙古文（回鶻式蒙古字母）的 Unicode 方案有哪些方面給日常應用帶來了麻煩？

01-08

Unicode 的 Mongolian block（U+1800 至 18AF）同時服務蒙文、托忒文、滿文和錫伯文。參見 13.2 Mongolian：http://www.unicode.org/versions/Unicode6.2.0/ch13.pdf
哪些是方案設計失誤？哪些是方案的設計沒有問題但實現難度較大？是否本可有更好的設計決策？

現行蒙文Unicode方案確實帶來了麻煩，但這些麻煩並非是由方案本身所造成，而是一種語文因為沒有太大的市場而不受重視造成的。

早期北大方正在解決民文排版時，都採用了大字符集的做法，其主要對象就是藏文和蒙古文，這種做法有利有弊，其利在於：

1、對於環境沒有要求，只要安裝了字體，就能正確顯示，而不會象現行方案那樣，依賴特殊的字體(如OpenType)和演繹引擎(如USP)。以目前來說，PC、手機以及其它移動終端設備的操作系統眾多，要讓這些系統都能支持，在沒有龐大的市場的情況下，是很難的。

2、藏文與回鶻蒙文有不同的地方，回鶻蒙文基本上來說仍然是各個名義字元的多種顯現形式線性排列的結果，而藏文則不是。回鶻蒙文即便要達到支持蒙古、滿、錫伯等語言的情況下，仍然不會需要大量的碼位。這就類似於在鉛字時代，排版者已經把各種變體排好，而現行Unicode方案卻是在最終演繹顯示時，再來選擇正確的變體進行編排。

其弊在於：

1、將最終演繹時的工作交給了輸入法去完成，在輸入法里必須能夠做到正確選擇變體。

2、在檢索的時候，需要通過映射表，描述名義字元與各種顯現形式的對應關係。

總的來說，無論採用哪種方案，製作字體時，所需的字元(Glyph)數量是一樣的，而現行Unicode方案需要多一道工序，通過OpenType來實現各種顯示特徵。大字符集的方案，只需要源頭上（也就是輸入上）解決了問題，便能很容易地適應各種顯示環境；而現行Unicode方案卻強列地要求顯示環境的支持。

個人認為，這就是現行Unicode方案給日常應用帶來的麻煩，但這個麻煩，並非是因為Unicode的失誤，也並非是因為實現難度的問題，其中最重要的原因，就如同開篇所提：對於廠商來說，該文種沒有太大的市場、沒有太大的經濟價值，所以遲遲得不到完美的、全方位的解決。

題外話：

微軟和蘋果較為完美地解決了藏文的輸入和顯示問題，主要是來自於不丹方面的推動。

大體來說，是編碼方案本身的根本缺陷（直接編碼語音字母而非字位字母——想像一下一個平行宇宙里英語的學術和教育界按中古英語的音位分析出英語的字母然後將這些語音字母直接編碼並用隱形字元來控制自動變形規則無法實現的那些到 ABC 字位的映射）加上編碼本身缺陷導致的複雜變形規則又缺乏系統且明確的規範。這兩個層面導致蒙文編碼從輸入的歧義（同形之下多種可能的字元串）開始就有重大問題然後字體還不完備並且廠商實現之間不兼容。

所以，的確是方案本身有嚴重問題，從字符集的設計到 OpenType 規範的制訂都有缺陷。不能把主要責任推給廠商。

多音字（如那些相同造型的原音），使用者若不按完全嚴格的要求輸入（字形上無區別），可能會在搜索中出錯。

另外因文字風格而衍生的新造型不知該如何規範，當然除了「強行和字」，是否還有更簡便的方法？