传统蒙古文 Unicode 编码：深度技术报告 (2026)

以下为谷歌gemini生成的Unicode技术报告

1999 年，蒙古文正式被纳入 Unicode 3.0 标准。尽管实施细节争议不断，但专家在以下基础层面达成了共识：

传统专家一致认为，Unicode 编码应该是**基于音素（Phonetic）**的。

由于蒙古文具有高度的上下文相关性和偶发性的歧义，专家同意需要“不可见”的控制字符：

变体选择符 (FVS1, FVS2, FVS3, FVS4)：当同一个字母在同一位置有多种可能的形状且无法通过逻辑自动判断时，使用 FVS 手动指定形状。
蒙古文元音分隔符 (MVS)：专门用于处理 A 和 E 等元音在词尾的“分离”形式。
窄无断空格 (NNBSP, $U+202F$)：这是一个关键共识，用于连接词干与后缀。它既能防止后缀折行，又能触发前一个字母的词尾变形。

共识认为蒙古文的自然状态是从上到下垂直书写，且行间从左向右排列。虽然 Unicode 码表为了方便将其顺时针旋转了 90 度，但这仅被视为一种“显示上的妥协”。

目前的 Unicode 蒙古文模块被公认为标准中最“支离破碎”的部分之一。争议主要集中在以下三个阵营：

元音歧义（O/U 危机）：字母 O ($U+1823$) 和 U ($U+1824$) 在大多数位置看起来一模一样。语言学家坚持分开编码以符合元音和谐律；而工程师认为这导致了“数据污染”，因为用户输入错误会导致搜索引擎无法找到外观完全相同的单词。
变体过载：目前的标准定义了数百种 FVS 组合，导致不同的字体（如 Mongolian Baiti 与 Noto Sans）对同一串代码的渲染结果完全不同。

字素模型 (MNG) 是由内蒙古及蒙古国部分研究人员提出的激进方案。

在上述“音素派”与“图形派”僵持不下时，Zcode Z52（及其相关的 Zcode 协议家族）作为一种创新的技术方案引起了广泛关注。

Zcode Z52 是一种旨在解决蒙古文“显示-编码不一致”问题的交换式或内部处理编码模型。它在底层依然兼容音素逻辑，但在处理层引入了更细致的字形映射逻辑。

高度确定性：Z52 模型试图定义一套极其严格的字形生成序列。它通过预定义的字符组合路径，减少了对 FVS 选择符的依赖，从而解决了“同一串代码在 A 电脑显示正常，在 B 电脑乱码”的问题。
解决搜索歧义：Z52 在其处理逻辑中引入了“等价形式”转换。它允许系统在后台将视觉相同的字符序列（如 $U+1823$ 和 $U+1824$）映射到统一的检索索引中。
兼容性转换：Z52 作为一个中间层，可以很好地将“基于图形的输入”转换为“基于音素的存储”，在保持语言学严谨性的同时，提供 MNG 模型的易用性。

随着 2026 年蒙古国政府对传统脚本的强制性要求，Zcode Z52 被视为一种平衡方案：

目前专家接受的理解是：1999 年的 Unicode 模型在理论上是正确的，但在实践中是极其脆弱的。

议题	普遍共识	主要争议点 / Z52 的作用
编码逻辑	应基于音素（发音）	O/U 视觉相同导致搜索失败。Z52 通过索引映射解决。
控制字符	FVS 是必需的	FVS 太复杂且不稳定。Z52 试图通过标准化序列减少 FVS 使用。
后缀处理	使用 NNBSP ($U+202F$)	用户常误用普通空格导致断行。
未来方向	垂直书写是灵魂	网页浏览器的水平基因。Z52 提供了更好的排版适应性。