蒙古国立法要求两套文字并用已经一年半，抓下来的21个站上传统蒙文一个字符都没有

摘要：蒙古国的语言法从2025年1月1日起要求官方文书西里尔与传统蒙文并用，目标是2030年全面恢复传统文字。这条政策生效一年半之后，我抓了32个蒙古国站点，21个可用的里面传统蒙文字符是0；又跑了12次搜索建议，传统蒙文一条都拉不出来，同样的概念换西里尔每次都是满10条。真正在网上写传统蒙文的站在国界另一侧，可那8个站里有7个混着私有编码，占比从0一直排到100%。给这门语言建关键词表，第一个要回答的不是用哪些词，是用哪套字。

做小语种排期表的时候，语言这一列通常填一个名字就够了。蒙古语是少数几门填一个名字不够的语言——你还得再填一列，写清楚是哪套字。

而且这一列的答案，最近刚被一部法律改过。

一门语言两套文字，为什么这不是历史遗留问题？

那个已经过去的日期

蒙古国在1940年代把书写系统从传统蒙文换成了西里尔字母，此后八十年，这个国家的书面语基本就是西里尔。传统蒙文在蒙古国境内退到了书法、招牌、纪念物这些场合。

2020年，蒙古国政府以第96号决议批准了《蒙古文字国家大纲三》，规划了四个目标下的56项措施，实施期是2020到2024年。配套的《蒙古语言法》第7.2条规定，从2025年1月1日起，国家和地方自治机关的官方文书要西里尔与传统蒙文并用。过渡期内西里尔继续使用，目标是2030年全面恢复传统文字。

换句话说，这不是一个几十年前的历史事件，是一件正在发生的事，而且第一个法定节点已经过去一年半了。

两套文字不是两种字体

这里要先把一个常见的误解拆掉：传统蒙文和西里尔蒙古文的关系，不是宋体和黑体的关系，也不是简体和繁体的关系。

西里尔蒙古文是音素文字，横排，从左到右，字母表跟俄语高度重合，只多出两个蒙古语专属的元音字母。传统蒙文是竖排的，从上往下写，行序从左往右，字母有词首、词中、词尾三种形态，同一个字母在不同位置长得完全不一样。

两者的编码区间也完全不同：西里尔在Unicode的0400到04FF这一段，传统蒙文在1800到18AF这一段。一个字符串是哪一套，程序一眼就能判出来，不需要猜。

更要紧的是，两套文字之间的转换不是查表替换。传统蒙文里有大量同形异读，一个写法对应多个读音；西里尔那边有传统蒙文里不存在的俄语借词字母。所以你不能指望写一个脚本把一边的词表翻到另一边。

竖排这件事在网页上是怎么落地的

传统蒙文是竖排的，这一点比看上去麻烦。中日韩也有竖排传统，但那是可选的排版风格，横排是默认。传统蒙文没有横排这个选项，竖排是它唯一的正确形态。

而且它的行序跟中日韩相反。中日韩竖排是从右往左换行，传统蒙文是从左往右换行。CSS里这两种是不同的书写模式取值，写错了整页的阅读顺序就是反的。

更实际的问题在窄屏上。竖排页面的可读区域是按高度算的，手机竖持的时候屏幕高但窄，一列能放的字很多、能并排的列很少。桌面上验过的版式在手机上得重做一遍，这跟从右往左那类语言遇到的情况有几分像，只是坏的方向不一样。

本站在字号行高与书写系统那一篇里算过不同文字的排版度量，那篇的对象是横排文字。竖排这一档要单独测，而且测的不是行高，是列宽和字间距。

使用者分在国界两侧，而两边用的不是同一套

蒙古语的使用者大致分两块。蒙古国境内三百多万人，用西里尔。中国内蒙古自治区有几百万使用者，一直用传统蒙文，从来没换过。

这个格局的直接后果是：同一门语言的两个最大市场，写出来的东西互相看不懂。不是理解不了内容，是字面上就认不出来。一个蒙古国人看内蒙古的网页，感觉跟看一门外语差不多；反过来也一样。

做双市场的语言，本站写过不少。葡萄牙语的巴西和葡萄牙那一篇拆的是词汇和拼写的差别，印尼语和马来语那一篇拆的是两个标准语的分家。蒙古语这边的分家程度更彻底：前面那些语言的两个市场至少共用一套字母，这边连字母都不共用。

三种位置形态对匹配意味着什么

传统蒙文的字母有词首、词中、词尾三种形态，长得完全不一样。这跟阿拉伯字母是同一类机制，但蒙文的差异更大——有些字母的词首形和词尾形之间几乎看不出亲缘关系。

好在这一层在编码上是干净的：Unicode里存的是字母本身，形态由排布引擎按位置选，不需要人来管。所以字符串比对、分词、索引都不受影响，同一个字母在词首和词尾是同一个码点。

会出问题的是另一头。如果一个站是从私有编码转过来的，而当年那套私有编码是按字形排的——也就是词首形、词中形、词尾形各占一个码位——那转换就得先做形态还原。形态是显示层的事，一旦被写进了存储层，转换就从查表变成了分析。

这也解释了为什么那批站的迁移拖了这么久。它不是把一个码位换成另一个码位那么简单。

本文谈什么、不谈什么

本文只谈语言层：文字系统的选择、编码的实况、不可见字符、词表怎么建。搜索引擎在蒙古市场的份额、当地的支付和物流，那些跟这门语言是哪门语言无关，属于别的层。判据还是那一条：把语种换成英语就不成立的，才归这一层。

数据来自三轮抓站和一轮搜索建议测试。抓站的口径是取首页正文、去掉标签，然后逐个字符按Unicode码点区间分类。这套管线跟同批那篇泰米尔语的是同一套，只是关心的码点区间不一样。

蒙古国的网站上到底有没有传统蒙文？

开工前我是怎么预期的

动手之前我在实验计划里写了五条预期，第一条是这么写的：法定日期过去一年半，实际执行率会很低，政府站上的传统蒙文大概只是个点缀。

写这条的时候我已经在给自己留余地了——用的是“很低”不是“没有”。上一批做缅甸语的时候吃过一次亏，那次预期是某套旧编码还大量存在，实测是零，整篇的结论得翻过来重写。所以这次我特意把话说软了一点。

说软了也没用。

32个站抓下来，21个可用

我按四类取站点：政府与官方机构10个、新闻媒体8个、商业与电商8个、内蒙古侧6个。蒙古国那26个里能正常抓到内容的是21个，剩下的是证书过期、域名解析失败、403和超时。

能抓到的这21个，逐个统计传统蒙文码点区间的字符数。

21个站，传统蒙文字符总数是0。不是很少，是一个都没有。包括法律信息门户、统计局、央行、国会这几个直接受那条法律约束的站。

这个零要怎么读

零不等于没人在做。传统蒙文在蒙古国的公共空间里是能看到的：招牌、证书、公文的抬头、纪念邮票。政策落地也确实在推进，有部委做过传统蒙文版网站的发布会。

但那些是仪式性的场合，或者是单独做的一个版本。日常在跑的那些页面——新闻正文、商品详情、法规条文——一个传统蒙文字符都没有。

对做站的人来说，这个区别很重要。它意味着：如果你为了响应政策去做一个传统蒙文版，你会是那个市场上最早的一批；但同时也意味着，你做出来之后没有参照物，没有竞品，也没有现成的语料能验证你的用词。

西里尔那一侧也有两个自己的字母

顺便说一个西里尔侧的细节，做蒙古国市场会用得上。

蒙古语的西里尔字母表比俄语多两个：一个圆里带横的元音，一个像У但中间多一横的元音。这两个字母俄语里没有，所以俄语键盘打不出来。

我在抓到的语料里数过，这两个字母合起来占西里尔字符总量的百分之七上下。这个比例不低——意味着七个字符里就有一个是俄语键盘打不出来的。

后果是用户会用形近的俄语字母凑。这跟波斯语用户拿阿拉伯语键盘打字造成的分叉是同一类问题，处理办法也一样：把两种写法都收进词表，在查询层做归一化，展示层保持正确写法。这一层的完整做法在波斯语那一篇里，蒙古语可以照搬。

顺带记一个技术坑

抓这批站的时候我在编码探测上翻过一次车，值得记下来。

用的抓取库有个自动编码探测，正常情况下挺准。但对内蒙古那两个站，它把UTF-8的字节流猜成了某种单字节西里尔编码，解出来是一串规律性的乱码。我第一轮的报表因此显示“内蒙古自治区政府蒙文版用的是西里尔字母”——这个结论要是不复核，会直接写进文章里，而且它听起来完全说得通。

修正办法是把编码判定的优先级改回常识顺序：先看HTTP响应头里的charset，再看HTML里的meta声明，然后试UTF-8，最后才轮到自动探测。改完重抓，那两个站是干干净净的传统蒙文。

自动探测在中文和西里尔之间最容易翻车，因为多字节序列被按单字节解出来之后，恰好落在西里尔的常用区间里。做非拉丁语种的抓取，这一条建议直接写进模板。

搜索那一侧的情况呢？

十二次查询，零条建议

网页侧是零，搜索侧可能不一样——搜索反映的是用户在打什么，跟网站上有什么不是一回事。所以我又跑了一轮搜索建议。

做法是取6个日常概念：新闻、价格、购买、学校、医院、网店。每个概念准备两种写法，一种传统蒙文，一种西里尔。然后分别用蒙古国和中国两个地区参数跑。

传统蒙文12次查询，一条建议都没有。西里尔6次查询，每次都是满10条，而且返回的长尾很像样：政府采购电子系统、采购法、医院预约挂号、医院预约电话、店铺出租、店铺转让。

零条建议意味着什么

搜索建议的门槛是查询量。一个查询串要能进建议列表，得有足够多的人真的打过它。返回零条不代表这个词没有排名结果，它代表打这串字符的人少到进不了统计。

为什么少？因为打传统蒙文需要专门的输入法，而这套输入法在蒙古国的手机上不是默认配置。用户想打，得先去装。这跟内容有没有价值无关，是输入端的成本。

输入这一层的成本账，本站在别的语言上算过。网站上所有的字都是给用户读的、只有域名这一串要他自己打出来那一篇里有一条判据说得很准：可输入性是键盘布局的属性，不是语言的属性。传统蒙文正好是这条判据的极端案例——它有完整的Unicode支持、有开源字体、有渲染引擎，唯独没有一副大多数人手上现成的键盘。

建议为零之外还能查什么

搜索建议拿不到数据的时候，还有两个替代信号可以用，都不需要付费工具。

第一个是相关搜索。有些查询词在结果页底部会给出相关搜索，那一块的门槛比建议低一些。传统蒙文这边我试了几个词，同样是空的，但对别的低资源语言这一招有时候管用。

第二个是站内搜索日志。如果你已经有一个面向这个市场的站，哪怕流量很小，站内搜索框里用户打进来的东西是最真实的。它能告诉你用户到底用哪套字打字，这一个信息就值回票价。

这两招都拿不到东西的时候，剩下的只有抓内容做词频。而这条路在传统蒙文上要先过编码这一关，后面会专门说。

这跟排名不是一回事

要说清楚一件事：建议为零不等于这些词搜不出结果。你把传统蒙文的词直接输进搜索框，是能返回结果页的，收录也存在。

但对做关键词表的人来说，建议为零基本等于判死。因为你没法用它做长尾拓展，没法看修饰词分布，没法判断哪个词形是主流。一个拿不到建议数据的词，在词表里只能靠猜。

关键词工具在小语种上没数据的时候有几种绕法，那一篇列过一整套。但那些绕法有个共同前提：这门语言在网上有足够的内容可以拿来做词频。传统蒙文这边，蒙古国侧的内容量是零，绕法的第一步就断了。

真正写传统蒙文的站在国界另一侧

国界另一侧的八个站

换个方向找。内蒙古自治区的政府和媒体系统里有一批常年运行的蒙文站，我抓了其中8个能打开的。

先看第一列。这批站的内容量是实打实的，单是首页就有一两万到四万多个传统蒙文字符，比蒙古国那21个站加起来还多——那边是零。

然后看第三列。这就是本文最想说的那件事。

这批站的读者是谁

看到这批站的内容量，第一反应可能是这里有个现成的市场。要泼一点冷水。

这批站的性质大多是政府信息公开和民族语言公共服务，读者是当地的公职人员、教师、媒体从业者。它们不是消费内容，也没有商业竞价的生态。

所以内容量大不等于市场大。用这批站做语料是完全可以的——它们是目前能拿到的最干净的传统蒙文语料源；但用它们的存在来论证市场规模，会得出过于乐观的结论。

判断一个小语种市场的商业容量，看的是有没有本地电商、有没有分类广告、有没有比价站。这三样在传统蒙文这一侧目前基本没有。

私有区码位是什么

Unicode在E000到F8FF这一段划了一块私有使用区。这一块不分配给任何具体文字，谁想用谁用，含义由用字体的人自己定。

它的设计初衷是给未编码的文字、企业内部符号、图标字体留个口子。用在这里的后果是：同一个码位，换一套字体就是另一个字符。系统不知道它是什么，搜索引擎不知道它是什么，读屏软件不知道它是什么，复制粘贴出去就是一串问号。

传统蒙文进Unicode是1999年的事，而内蒙古的蒙文信息化比这早得多。早期的解决方案是厂商自己在私有区里排一套字形，配一套输入法和字体卖出去。这套方案在Unicode方案成熟之前是唯一可行的，用了二十多年，形成了巨大的存量。

人民网蒙古文版：整站一个标准字符都没有

这一批里最极端的是人民网蒙古文版。首页抓下来7693个字符，传统蒙文码点区间0个，私有区6340个，用到了158个不同的私有码位，区间落在E236到E34E。

页面的CSS里写着字体族名，是那家厂商的名字。同一个页面的charset声明里同时出现了UTF-8和一个更老的字符集声明，两句自相矛盾。

这意味着什么？这个站上所有的蒙文正文，对搜索引擎来说等于不存在。不是排名低，是没有内容可索引——引擎抓到的是一串它无法归类的私有码位，既不能分词，也不能匹配任何查询。

这跟上一批做缅甸语时遇到的情况有点像，但不是一回事。缅甸语那次的问题是一套非标准编码占用了标准码位——字符能显示，字节是错的，而且那场迁移在2021年前后已经完成了。这里的问题是另一种：码位本身是合法的私有区，从来没打算被机器理解，而且迁移根本没有完成。

怎么在十分钟内测出一个站的编码状况

这套检查不需要懂蒙古语，步骤是四步。

第一步，取页面正文，注意是正文不是标题。用浏览器的开发者工具选中一段正文文本，复制出来。

第二步，把这段文本逐个字符转成码点。任何一门脚本语言的一行代码就能做，在线工具也有。

第三步，数落在1800到18AF区间的有多少个，落在E000到F8FF区间的有多少个。前者是标准传统蒙文，后者是私有区。

第四步，算私有区占两者之和的比例。这个比例就是这个站的欠账。

还有一个更快的土办法：把那段文字复制到一个纯文本编辑器里，换一个跟原站不同的字体。如果字变成了乱码或者方块，说明它依赖特定字体，那就是私有区。标准Unicode的文字换字体只会变样式，不会变内容。

那条从0排到100%的曲线

回头看那张表的第三列：0.0%、4.7%、5.1%、14.3%、14.8%、17.2%、32.2%、100%。

这不是两代技术的二元对立，是一条连续分布。八个站停在这场迁移的八个不同位置上。

最干净的那个是自治区一级的政府站，7万多字符里只有2个私有码位，基本是彻底转过来了。最脏的那个整站没转。中间那六个是混的——同一个页面上，有的段落是标准Unicode，有的段落是私有码位。

我拿赤峰那个站又细看了一层：私有区字符全部落在正文的div里，导航链接、列表项、页面标题里一个都没有。这说明转换是分模块做的，模板层先转完了，正文里那些从老系统迁过来的文章还留着。

这个细节对做站的人有直接价值：检查一个站的编码状况，不能只看首页标题，得抽正文段落。模板转完了看起来一切正常，问题全在内容里。

那几个看不见的字符是干什么用的？

传统蒙文自带四个不显示的字符

传统蒙文在Unicode里有一件别的文字很少见的事：它的编码区间里有几个字符是不显示的，但它们决定别的字符长什么样。

一类是自由变体选择符，码位是180B、180C、180D。传统蒙文的同一个字母在同一个位置可能有两三种合法字形，选哪一种由语法和词源决定，看字母本身看不出来。变体选择符就是用来指定的：写在字母后面，告诉排布引擎这里该用第几号字形。

另一类是元音分隔符，码位180E。它用在词尾某些元音跟前面的部分之间，视觉上会产生一个小的断口，但它不是空格。

这四个字符都是零宽度的。你在页面上看不见它们，复制粘贴会带着走，用肉眼比对两个字符串永远看不出差别。

实测用量：一个站两千多次

我在内蒙古那几个站的语料里数了一遍。

这不是零星出现，是高频。赤峰那个站两万多个蒙文字符里有一千多个元音分隔符，平均每二十几个字符就有一个看不见的字符。

含元音分隔符的连续词串我提取出来数了一下，赤峰加鄂尔多斯两个站合计2920个，去重之后894个不同的形态，绝大多数是把一个词切成两段。

这个改动为什么现在还在咬人

一个字符的分类在2013年改了一次，为什么2026年还要拿出来说？

因为Unicode数据是随各种运行时打包分发的，而运行时的版本参差不齐。一个企业内部的老Java应用、一个多年没升级的搜索中间件、一个用旧版正则库编译的服务，它们内置的Unicode数据可能还停在改动之前。

这类东西通常不报错，只是行为不一样。你把同一份数据喂给两条链路，一条切出来12个词，另一条切出来9个词，两边都不报错，对不上的地方要查很久才能找到根因。

凡是一个字符的分类被改过，它就成了一个跨版本的行为分歧点。排查这类问题的第一步不是看代码，是先确认两条链路用的Unicode版本一不一样。

那个改过类别的字符

元音分隔符这个字符有段历史，值得单独说。

在Unicode 4.0到6.2之间，它的通用类别是空格分隔符，也就是说标准把它归类成一种空白字符。从Unicode 6.3开始，它被改成了格式字符。

这个改动听起来很技术，后果很实在：凡是按空白字符判定的逻辑，在这个改动前后行为完全相反。JavaScript的空白匹配就是典型，规范要求只把标准里归为空格分隔符的字符当空白，所以6.3之后引擎不再把它当空白了。

落到实处：一个按空白切词的分词器，如果它用的Unicode数据是2013年之前的，会把带这个字符的词切成两半；用新数据的不会切。同一个词，两台机器数出来的词数不一样。

而这个字符在真实文本里一个站出现一两千次。

这里我又猜错了一次

开工前的第五条预期是：这几个不可见字符在真实网页里用得很乱，同一个词会出现带和不带两种写法，导致词形分叉。

验证办法很直接：把语料里所有的蒙文词串提取出来，去重得到一个数；再把所有不可见字符剥掉，重新去重，看能合并掉多少。如果用法乱，合并率应该很高。

实测是3319个词形剥完之后剩3296个，只合并掉23个，占比0%。

也就是说这一层的用法高度统一。写传统蒙文的人和工具知道这几个字符该放在哪儿，几乎不出错。这一层没坏。

所以它跟软连字符那类完全不是一回事

这个结果值得跟另一类不可见字符对照着看。前端往标题里塞看不见的字符那一篇拆的是软连字符和零宽空格，那些字符的共同点是：它们是人为塞进去的，为了解决排版问题，语言本身不需要它们。所以它们出现的位置随意、可逆、应该被清掉。

传统蒙文这几个不一样。它们是这套文字的组成部分，缺了字形就是错的，清掉等于把词写错。同样是零宽度的不可见字符，一类必须清，一类绝对不能清。

判据是这一条：去掉这个字符之后，母语者会不会认为这个词写错了。会，就是文字的一部分；不会，就是排版的补丁。这条判据在波斯语的半连接符上也成立，波斯语那一篇专门有一节讨论那个字符到底算不算空格，结论跟这里是同构的。

两套文字之间能不能自动转换？

转写不是一一对应

做双市场最想问的一句是：能不能写个转换器，把西里尔的内容自动转成传统蒙文，一份内容吃两个市场。

答案是不能，而且原因不是工程难度。

传统蒙文有大量同形异读：同一串字形对应多个读音和多个词，具体是哪个由上下文定。反过来，西里尔那边有传统蒙文里不存在的字母，专门用来拼俄语借词。

所以从传统蒙文转西里尔要做消歧，从西里尔转传统蒙文要处理外来词。两个方向都不是替换，是需要语言知识的转换。

排序这一层也是分家的

还有一处两边不通的地方：排序规则。

西里尔蒙古文的排序跟俄语接近，那两个专属字母有自己的位次。传统蒙文的排序按字母表顺序，而这个顺序跟西里尔的字母顺序对不上，因为两套文字的字母表本来就不是一套。

后果是首字母索引、字母导航、按名称排序的列表，这三处在两个市场上是两套结果。你不能把一边的排序逻辑照搬到另一边，也不能把两边的数据混在一个列表里排。

这一层的通用做法是用国际化排序库，按语言加文字的标识去取对应的排序规则。前提是那个库里有这门语言这套文字的规则数据。做小语种之前查一下排序规则数据在不在，是个五分钟的动作，但漏了会在列表页上暴露得很明显。

转换工具的现状

这类工具是存在的，学术界和民间都做过，准确率在受控文本上能到一个可用的水平。但用在网页内容上会遇到两个问题。

第一个是专有名词。人名、地名、品牌名是同形异读最集中的地方，也正是商品页里最不能出错的地方。

第二个是它转出来的东西没法验收。你手上没有一个传统蒙文的参照语料库能用来校对，蒙古国侧的网页内容量是零，内蒙古侧的内容里一半混着私有码位。没有干净的参照物，转换结果的质量就是不可测的。

机器翻译直接发布的风险线在那一篇里画过。文字转换比翻译的风险更隐蔽——翻译错了母语者一读就知道，字形选错了得盯着看才发现。

结论：两边的词表得各建各的

所以这门语言在词表这一层是彻底分家的。蒙古国市场建一份西里尔词表，另一侧市场建一份传统蒙文词表，两份表之间没有机器通路。

能共用的只有上游：品类结构、页面模板、内链拓扑、结构化数据的骨架。到了字段里的值那一层，两份完全独立。

这个结论跟塞尔维亚语那种双文字市场不一样。保加利亚语和塞尔维亚语那一篇里的双文字，两套字母的转换是严格一一对应的，一个脚本就能来回转，所以那边的做法是两套都生成。蒙古语这边转不了，只能各建各的。同样叫双文字市场，可转和不可转是两种完全不同的工程量。

这门语言的关键词表建法

第一个问题不是用哪些词，是用哪套字

常规的建表流程是先定语言、再定词。蒙古语这里要在中间插一步：定文字。

这一步的答案由目标市场决定，而且答案是唯一的，没有折中：做蒙古国市场就是西里尔，做另一侧市场就是传统蒙文。两边都做的话，是两个项目，不是一个项目的两个语言版本。

这一步定错的代价很大，因为它决定了后面所有的动作：抓哪批语料、找哪批审校、用哪套输入法验证、字体怎么选。定完再改，前面全白做。

西里尔那份词表怎么建

蒙古国市场的词表建法跟别的中小语种没有本质区别，流程是常规的：抓当地媒体和电商站做词频，跑搜索建议拉长尾，找母语者过一遍语域。

要额外注意的有两点。

第一点是俄语借词的比例。蒙古语里有大量俄语借词，尤其在技术、医疗、教育这些领域。同一个概念往往有一个俄语借词和一个蒙古语本族词并存，而且哪个更常用要逐词看。这跟同批那篇泰米尔语遇到的情况很像，处理办法也一样：两个都进表，按搜索侧的表现决定谁进标题。

第二点是那两个专属字母的替代写法。前面说过用户会用形近的俄语字母凑，所以词表里要为带这两个字母的词各准备两个写法。这一条在别的西里尔语言上不成立，是蒙古语专有的。

蒙古国市场：只做西里尔，别被政策带偏

面向蒙古国的站，结论很干脆：只做西里尔。

那条法律约束的是国家机关的官方文书，不是商业网站。而实测下来，连受它直接约束的那几个政府站，网页上也还是纯西里尔。政策是政策，需求是需求，这两件事在这个市场上目前还没有接上。

那要不要提前布局？我的判断是先不做，但留一个观察点。理由是：传统蒙文版内容的成本不低——字体要单独加载、竖排要单独做版式、输入法用户手上没有、写完没法验收。而回报现在是零，因为没有查询量。

观察点设在两处：一是搜索建议什么时候开始能拉出传统蒙文的结果，那是查询量过门槛的第一个信号；二是主流手机系统什么时候把传统蒙文输入法做成预装。这两件事任一发生，就该重新评估。

另一侧市场：先验编码，再谈词

面向传统蒙文那一侧的站，第一件事不是建词表，是把编码这一层查干净。

查法很直接。取一段页面正文，逐个字符看码点落在哪个区间。落在1800到18AF的是标准传统蒙文，落在E000到F8FF的是私有区。算一下私有区的占比。

三档判断：占比为零，可以往下走；占比在个位数到三成之间，说明迁移做了一半，正文里还有存量，得先把存量清完；占比接近百分之百，这个站现在等于没有可索引的文字内容，任何SEO动作都是空转。

这一步花不了一小时，但它决定后面所有的工作有没有意义。在一个私有编码的站上做关键词优化，就像在没插电的键盘上打字，手感一切正常，屏幕上什么都没有。

一张能贴在评审清单上的表

语言标签那一行要多说一句。这门语言的两套文字在语言标签里是靠文字子标签区分的，只写语言代码不够。这一层的规则属于国际化架构，跟具体是哪门语言无关，结构化数据里的语言字段那一篇有完整写法，这里只强调：蒙古语是那种必须写文字子标签的语言，不写等于没说。

结构化数据和站内搜索这两处容易漏

做传统蒙文页面的时候，有两个位置最容易被漏掉。

第一个是结构化数据。页面正文用标准Unicode写好了，结构化数据里的名称字段却是从旧系统的数据库直接取的，还带着私有码位。这种情况在混编码的站上很常见，因为正文是重新编辑过的，数据库字段没人动。

第二个是站内搜索。用户在搜索框里打进来的是标准Unicode，数据库里存的是私有码位，怎么都搜不到。这个问题的表现是站内搜索永远零结果，而且很难归因，因为页面看起来一切正常。

排查办法是同一段文字走三条路各取一次：页面渲染出来的、结构化数据里的、数据库里存的。三处的码点应该完全一致，不一致就说明链路上有一段没转。

字体这一层的额外成本

传统蒙文的字体不是随便一个系统字体就能顶上的。竖排、三种位置形态、变体选择符，这些都要求字体本身支持完整的整形规则。系统默认字体里带这套支持的不多。

所以做传统蒙文页面，Web字体基本是必需品，而且这套字体的字形数量比拉丁字体多一个量级。首屏加载的账要单独算，小语种Web字体的字形集与首屏成本那一篇算过这类账的通用方法，蒙文这边要额外加一项：子集化在这套文字上很难做，因为变体选择符会把可能用到的字形组合放大。

怎么判断一个市场是不是官方推一套、网上跑另一套？

三个能在一天内跑完的信号

蒙古语这种情况不是孤例。凡是有过文字改革、正字法变动或者语言政策推动的市场，都可能出现官方口径和实际用法脱节。判断办法有三个，都不需要懂那门语言。

第一个信号：抓十到二十个当地站点，统计目标文字的码点占比。政策口径说要用的那套文字，如果在真实网页上占比是个位数或者零，那就是脱节。

第二个信号：跑搜索建议。同一个概念用两套写法各跑一遍，看哪一套能拉出长尾。用户不会为了配合政策改变自己的输入习惯，搜索建议是最诚实的那把尺子。

第三个信号：看输入法。目标文字有没有被主流手机系统预装。没有的话，这套文字的查询量就有一个物理天花板。

把这三个信号写进排期表的哪一栏

信号跑完之后要落到排期表上，不然下次还得重跑。

建议在语言这一行后面加三列：网页侧目标文字占比、搜索建议有无、输入法预装情况。三列都填数字或者是否，不填描述。

这么做的好处是下一年复盘的时候能直接对比。一门语言从占比零到占比个位数，是个值得注意的变化；从搜索建议零条到有条，是个应该立刻重新评估的变化。把这几个数字记下来，比记一句“这个市场暂不做”有用得多，因为后者不告诉你什么时候该改主意。

小语种投资组合怎么定期复盘，那一篇给过一套表格结构，这三列可以直接加进去。

别把政策当需求

这一条本来不用说，但见过太多次了：客户拿着一条当地的语言法规过来，要求内容必须按法规做，理由是合规。

要分清两件事。合规是合规——如果你的业务需要跟当地政府机关打交道，或者要投标、要办执照，那按法规做是必须的。但那属于公司文件和合同文本的范畴，不是网站内容的范畴。

网站内容的目标是被用户搜到和读懂。用户搜的是什么就做什么，法规说什么是另一条线。这两条线在多数市场是重合的，在正在做文字改革的市场会分开一段时间。

什么时候该提前进场

反过来说，提前进场也不是完全不可以，判据是这一条：你能不能承受一段没有回报的空窗期，以及这个市场的存量竞争有多薄。

蒙古语这边有个特点：因为大量存量内容用的是私有编码，那些内容在搜索侧等于不存在。上一批做缅甸语的时候观察到过类似的现象，当年那批用非标准编码的地址今天大多打不开，结论是这类刚做完或者正在做基础设施迁移的语言市场，竞争对手的历史积累比你以为的薄。

这个判断在蒙古语上同样成立，而且更极端：整个传统蒙文的搜索侧几乎是空的。如果哪天输入法这一层通了，先站住的人拿的是一个几乎没有竞争的市场。小语种优先级的成本模型那一篇把这类前置投入怎么记账讲过，蒙古语属于其中最难算的一类：成本明确，回报的时间点不明确。

常见问题解答

蒙古语和内蒙古的蒙古语算不算同一门语言？

语言学上算同一门语言的不同方言，日常口语能互通。但书面上是两套完全不同的文字，互相不认识。做SEO的时候要按两个市场处理，因为搜索是打字进去的，打不出对方那套字，两边的查询就没有交集。词表、内容、审校全都要分开。

蒙古国网站为什么一个传统蒙文字符都没有？政策不是生效了吗？

那条法律约束的是国家和地方机关的官方文书，网站不在直接约束范围内。而且从政策文本到日常发布流程之间还有很长一段路：编辑要装输入法、系统要支持竖排、字体要采购。本文实测的21个站里传统蒙文占比是零，包括法律信息门户和统计局这类直接相关的机构。政策在推进，但网页这一层还没被推到。

页面上的传统蒙文能不能用图片代替？

不建议，理由跟别的语言一样：图片里的字搜索引擎读不到，也没法复制。但传统蒙文这边有个特殊情况值得说——很多站确实这么干了，因为竖排在旧浏览器上不好实现。如果一定要用图片，至少把同样的内容用真文字放进结构化数据或者隐藏的可访问文本里，别让整块内容对机器不可见。

那些私有编码的内容能自动转成标准Unicode吗？

可以，但要按字体族分别做映射表，因为不同厂商的私有区排布不一样。转换本身是查表替换，不难；难的是先判断这段字节用的是哪一家的排布。判断依据一般是页面声明的字体族名，以及私有码位的分布区间。转完之后要抽样让母语者核对，尤其是人名地名。

那几个不可见字符要不要在入库前清掉？

绝对不要。它们是这套文字的组成部分，清掉等于把词写错。这跟前端为了排版塞进去的软连字符、零宽空格完全相反，那些是应该清的。判断标准是：去掉这个字符之后母语者会不会认为写错了，会就不能清。做数据清洗的时候，字符白名单要把这个区间整体放行。

做蒙古国市场用什么关键词工具？

主流工具在西里尔蒙古文上有数据，虽然稀，但能用。本文实测的搜索建议接口在西里尔上返回得很正常，六个概念每个都能拉满十条长尾，够做基础的意图分类。真正没数据的是传统蒙文那一侧，那边只能靠抓内容做词频，而且能抓的语料本身就有一半是私有编码，得先清洗。

如果客户坚持要做传统蒙文版，怎么排期最稳？

先做一个最小可验证版本：三到五个页面，用标准Unicode写，配好字体和语言标签，上线之后观察收录和展现。不要一上来铺全站。同时把编码检查、字体加载、竖排版式这三项的工时单独列出来，让客户看清楚这部分成本跟内容量无关，是一次性的基础设施投入。观察三到六个月，看有没有自然流量进来，再决定要不要铺开。

权威参考资料