语言代码注销了385个，其中七成不是消失，是并进了另一门语言

摘要：把ISO语言代码的全部变更记录从2006年翻到2024年，一共1423条申请、2250行变更。截到2024年底，累计有385个语言代码被注销，其中46%是被并进了别的语言、26%是被拆开，真正判定为查无此语言的只占19%。也就是说七成以上的注销不是消失，是换了地方，机械替换会把一门语言静默换成另一门。同时在册的7921门语言里，有两位代码的只有184门，2.32%。你在hreflang里最顺手的那种写法，覆盖不到在册语言的四十分之一。

有个问题被问过太多次，答案却很少有人真的去查：挪威语在hreflang里到底该写no还是nb。

问的人一般会得到一个模棱两可的回复，大意是两个都行、看情况、随便挑一个别乱换。这个回复不算错，但它绕过了一件更根本的事——no和nb这两个代码，是被两个不同的机构、在两套不同的规则下、为了两件不同的事发出来的，它们之间的关系是被人写在一份文件里的，不是天然如此。

保哥今年秋天认真去翻了那份文件。准确说是翻了一整个库：ISO 639-3的变更申请库，从2006年这套体系上线那年开始，每一次新增、每一次改名、每一次合并、每一次拆分、每一次注销，都有一个申请编号、一份提案、一个生效日期，全部公开挂在网上。

翻完之后的感受不太好形容。你会发现自己一直当成常量在用的那串两三个字母，其实是一份有人受理、有人评议、有生效日期的行政档案。它会变，而且变过很多次。

下面这些数字全部截到2024年12月31日，口径是按结果生效日期算的，不是按申请年份。这个区别不是抠字眼——2021年提交的那份闽南语拆分申请，结果到2024年10月15日才下来，按申请年份截会把它整条丢掉。

这串语言代码到底是谁在维护？

先把角色理清楚，后面的数字才有落脚点。

ISO 639不是一份标准，是好几份

很多人把ISO 639当成一份表，其实它长期是分册的：两位字母的那一份、三位字母那一份、覆盖更全的那一份、还有语系那一份，各管各的编号规则，各有各的维护机构。

2023年这几册被整合进了同一份标准，编号规则不变，但称呼变了。注册机构自己那页讲各分册关系的说明现在写的是Set 3，不再写Part 3。

这件事对你没有任何技术影响，一个字母都不用改。但它是个很好的提醒：连这套编号体系本身的组织方式都会变，何况里面那些具体的代码。

顺带说一句，网上很多讲hreflang的文章还在按老称呼写，包括我自己早年写的那篇。称呼这种东西不影响正确性，但它能告诉你一份资料是哪年写的。

对做SEO的人来说，只需要记住一件事：你日常打交道的两位码来自其中一册，三位码来自另一册，两册的维护机构不是同一家，更新节奏也不一样。

三位代码的注册机构是一家做语言调查的机构

三位代码这一册的日常维护，交给了一家长期做少数语言田野调查的机构。它负责受理申请、组织评议、写裁决、每年发布更新后的码表。

这个安排解释了后面很多现象。受理方的知识背景是描写语言学和田野调查，所以它对一门语言够不够格的判断，几乎全部落在语言本身的证据上，跟这门语言在政治上、商业上有多重要基本无关。

它也解释了为什么这个库长这个样子：申请要写提案、要附参考文献、要接受公开评议，整个流程更像投一篇论文而不是提一个工单。

还有一点值得留意：受理方本身也在出版一份全球语言数据库，两套东西的语言划分高度一致。所以你在别的资料里看到的语言数量，很可能跟这份码表同源。

这不是问题，但它意味着你没法用那份数据库去交叉验证这份码表——它们本来就是一家出的，对上是应该的，对不上才奇怪。

一年只开一到两次门

把2250行变更按生效日期铺开，最扎眼的不是总量，是分布。2008年1月14日一天生效了409行，2012年2月3日一天231行，2013年1月23日一天202行。

再看每年有几个生效日：2019年全年只有1月25日这一天，2023年是1月20日和12月15日两天，2024年是4月3日和10月15日两天。

这意味着这张表不是随时在变的活水，而是一年开一到两次闸。你的语言代码对表工作，一年做两次就够了，做十二次是浪费。知道这一点，这件事就从一个隐忧变成了一个日程条目。

2011年更极端，全年只有5月18日一个生效日期。2019年也是，全年只有1月25日那一天。

为什么这件事值得SEO的人花半天

因为语言代码是少数几个能同时出现在你站上五六个不同位置的东西：页面的语言声明、hreflang的每一条、结构化数据里的语言字段、商品数据源的语言设置、分析报表的语言维度。

这几个位置分属不同的人维护，各自都以为自己写的是同一套东西。hreflang的完整用法那一层讲的是这些标签之间怎么互指，而这一层要回答的更靠前：你互指用的那串字符，本身还成立吗。

还有一个更实际的理由：这几处位置里，只要有一处写着已经注销的代码，排查起来的第一反应通常是怀疑代码写错了，而不是怀疑代码本身作废了。方向一错，半天就没了。

这个坑我自己踩过一次。当时一个站的某个语言版本在两个分析工具里的量差了接近一倍，查了两天配置，最后发现是其中一个工具按新代码归类、另一个还按老代码，而两个代码指的是同一批人。

在册的7921门语言，能写成两位码的有几门？

先给你一个数字，然后再解释它为什么让人别扭。

7921门在册，184门有两位码

翻开2024年10月那次变更生效之后的在册表，一共7921门语言。按类型拆：在用的7076门、已经灭绝的602门、历史语言215门、人造语24门、另有4个特殊代码。

然后数有两位代码的那一栏：184门。2.32%。

这个比例意味着，你在hreflang里写的那种两个字母的写法，能覆盖的语言不到在册语言的四十分之一。剩下那97.68%要么写三位码，要么根本没法在你的系统里被表示。

顺便说一句，这7921门里已经灭绝的有602门。做语言优先级的时候如果你的清单是从某个全量表直接拉的，记得先把这一栏筛掉，不然会算进一批没有活人在说的语言。

184门里还有35门是宏语言

更细一层：这184门里，有35门的范围标着宏语言，只有149门是个别语言。

宏语言是什么后面有一整节，这里先说结论：你写zh、ar、ms这几个最常见的两位码时，写的其实不是一门语言，是一个装着若干门语言的口袋。

再往细看，184门按语言类型拆是174门在用、5门历史语言、5门人造语。也就是说这份最短最好用的清单里，还挤着拉丁语这类没人日常说的语言，和世界语这类被造出来的语言。

不是说它们不该有代码。只是当你拿两位码当作重要语言的近似值时，这份名单的构成会让这个近似值偏得比你想的多。

反过来看也一样成立：有两位码的149门个别语言，是这套体系里被表示得最完整的一批。它们在几乎所有系统里都能被正确处理，而这恰恰是它们跟其余七千多门语言最大的差别。

两位码短缺不是历史遗留，是设计如此

有人会觉得这是历史包袱，早晚补齐。补不齐。两位字母一共只有676个组合，扣掉保留段和已用段，剩下的位置根本装不下七千多门语言。

RFC 5646定义的语言标签规则里写得很清楚：有两位码的就用两位码，没有的用三位码。这条规则的存在本身就承认了两套编号会长期并存。

所以正确的心态不是等它补齐，而是从一开始就假定你的链路要同时吃两位码和三位码。这一点在做印度、非洲、东南亚市场时几乎必然会撞上。

这条规则还有一个不太直观的后果：同一门语言在不同的系统里可能被写成不同长度的代码，而两种写法都合规。你做数据对齐的时候，得先做一次归一化。

归一化的方向应该统一到三位码，因为三位码是全集，两位码是子集。反过来做会丢掉97.68%的语言。

这个数字对小语种选品意味着什么

做小语种优先级和成本测算的时候，有一个很少被写进模型的成本项：这门语言在你的技术栈里能不能被表示。

能不能表示不是玄学，它有具体表现——分析工具的语言维度里有没有这个选项、广告后台的定向里有没有、内容管理系统的语言下拉里有没有、翻译服务商的语言列表里有没有。

这几处的清单长度差别巨大。有的按两位码建，那你可用的就是184门；有的按三位码建，那才是七千多门那个数量级。先查你自己链路上最短的那一环，它决定了这门语言在你这里的天花板。

顺带一个观察：越是靠近内容生产端的工具，语言清单越长；越是靠近投放和分析端的工具，清单越短。所以卡住你的通常不是写不出来，是量不出来。

顺手可做的一次自查

找一个下午，把你站上所有出现过语言代码的位置列出来，逐个记下它用的是两位还是三位、允许填几位、填错会不会报错。

保哥帮一个做户外装备的独立站做过一次，一共找出七处，其中三处只接受两位码，两处三位两位都收但不做校验，还有两处的下拉框是几年前手工维护的，里面躺着两个早已注销的代码。

最后那两个代码后面会讲到，它们是这篇文章真正的主角。

这次自查还有个副产品：你会发现有几处位置压根就没有语言这个概念，比如某些老的商品导入模板。那几处不是写错了，是根本没设计过，属于另一类问题。

一个语言代码是怎么消失的？

先说结论：截到2024年底，累计有385个语言代码被注销。这个数字本身不算大，问题在注销的方式。

四种注销理由，比例完全不是直觉那样

官方的退役表把注销理由分成几类，逐条数下来：被并进别的语言177个占46%，被拆开102个占26%，判定为查无此语言72个占19%，重复登记33个占9%，另有1个是换了代码。

翻这张表之前，我估计查无此语言会占大头，理由很朴素——早年登记得粗，后来发现有些语言根本不存在或者是同一门语言的两个名字。

实测反过来了。真正判定为根本不存在的只有19%，而72%的注销属于它还在，只是换了地方。这一条打脸打得挺响，也正好是最有实际后果的一条。

这四类的比例这些年也没怎么变过。早期的注销里查无此语言的比例略高一些，后期几乎全是重新划界，符合一个逐渐成熟的登记体系应有的样子。

它还在只是换了地方，才是最难查的那种

为什么这个区别要紧？因为两种情况在你的系统里表现完全不同。

如果一个代码是因为查无此语言被注销的，你的页面拿它去声明语言，最坏结果是被当成未知语言忽略掉——难看，但不至于错到别人身上。

如果它是被并进另一门语言注销的，那这个代码背后的那批内容，从注销那天起在标准的口径下就属于另一门语言了。你还在按老代码分类、按老代码出报表、按老代码给用户匹配版本，而所有下游系统都已经按新代码理解它。

这种错不会报错。它表现为报表里某个语种的量莫名其妙掉下去、另一个语种莫名其妙涨上来，而两个数字都是对的。

更难受的是，如果你的站上有内容真的是用那门语言写的，那这批内容的语言标注从注销那天起就跟标准对不上了，而没有任何一个环节会告诉你。

三个能直接查证的例子

抽三个具体的看。第一个是Yinglish，代码yib，2007年7月18日被并进English，也就是eng。一门混合语被判定为不构成独立语言，归到了英语底下。

第二个是比利时手语，代码bvs，同一天被拆成两个：法语区的手语sfb和弗拉芒手语vgt。荷兰语和佛兰芒市场那道分界在这里以一种很直接的方式重演了一次——语言的分界跟着语言社群走，而不是跟着国界走。

第三个最狠：孟加拉国的吉大港语，代码cit，被拆成罗兴亚语rhg和吉大港语本身，而留下来的那一半也换了新代码ctg。原来那个cit现在指向空气。

这三个例子分别对应三种典型：一门混合语被归到主语言底下、一门语言按社群边界被拆成两门、一门语言拆分后两半都换了新号。你自己那几门语言大概率能对上其中一种。

拆分是唯一会让两边都失效的操作

上面第三个例子指出了一条很反直觉的规律：合并的时候，老代码至少有一个明确去向；拆分的时候，按规则老代码必须整个退役，然后给拆出来的每一部分发新代码。

也就是说，如果你的表里存着一个后来被拆分的代码，你不能简单地把它换成拆出来的任何一个——因为你根本不知道这条记录当初指的是拆出来的哪一半。

102个被拆开的代码，每一个都是这样一颗需要人工判断的地雷。批量替换脚本在合并那一类上能跑，在拆分这一类上必须停下来问人。

还有一种更麻烦的情形：拆出来的几门语言里，有一门沿用了原来的名字。你的表里如果是按语言名而不是按代码存的，这时候名字对得上，代码却已经换了，两边各自都不报错。

2024年这一年注销了几个

给个近期的量级感受：2024年全年注销的代码只有2个。2023年是14个，2022年10个，2021年9个。

最猛的一年是2008年，注销83个。2016年39个，2015年25个，2012年27个。

所以这件事的节奏是：越早期的代码越危险，因为它经历过那几个大清理年份；2015年之后进表的代码相对稳定。你的词表里那些从十几年前的老项目继承下来的语言代码，才是要优先核的。

这条对老站尤其要紧。一个跑了十年的站，它的语言配置很可能是十年前建的，而那正好是注销最密集的那几年之后不久，中间又攒了两轮变更。

为什么代码退役总是扎堆在一月？

把385个注销按生效日期铺开，会看到一个很整齐的形状。

七成的注销发生在几个特定的日子

最集中的几天：2008年1月14日一天注销75个，2009年1月16日48个，2016年1月15日39个，2012年2月3日27个，2015年1月12日25个，2020年1月23日21个。

六天加起来235个，占全部注销的六成。剩下的散落在十几个别的日期上。

原因不神秘：这个库的工作节奏是按年的，一批申请集中受理、集中评议、集中裁决、集中生效。所以对表的最佳时机是每年一月底和年中各一次，正好卡在两个生效窗口之后。

还有一个更早的高峰：2007年7月18日一天生效了149行变更，那是这套三位码体系上线之后的第一次大规模整理。今天还能查到的很多老代码，都是那一天没了的。

一次批量整理长什么样

2018年提交的那批修改申请有88行，全部在2019年1月25日同一天生效。按语系拆，其中76行是澳大利亚语系；按地区拆，79行属于太平洋地区。

这显然不是八十几个人各自提了一份申请，而是某一次针对澳大利亚原住民语言的系统性梳理，一次性提交上来。

这类批量整理的特征是：修改的是名称和指称范围，不是代码本身。也就是说代码没变，但这个代码指的是什么变了。这种变更最容易被忽略，因为你的表里那一行字符串一个都没动。

这类整理还有个特点：它们往往来自某个学术项目或某个国家的语言调查成果，一次性把某个语系的登记信息校准一遍。所以变更会高度集中在一个语系、一个地区。

对你的意义是：如果你做的市场正好在某次批量整理覆盖的范围内，那一年的变更值得逐条看；不在的话，扫一眼就行。

改名比改码更常见

把所有修改类的变更按改动的属性分：参考名占32.0%、指称范围占30.8%、附加名称占23.9%、宏语言成员关系占10.2%、范围类型占2.7%、语言类型占0.3%。

合起来看，将近九成的修改是在动名字和这个代码管多大范围这两件事。代码本身其实相当稳定，不稳定的是代码背后指的东西。

这条对做语言选择器里那些语言名怎么写的人特别要紧：你界面上那个语言名，可能在某一年被官方改过，而你的代码一个字母没变，所以没有任何机制会提醒你。

指称范围的改动最值得警惕。它的意思是这个代码涵盖哪些话语变体被重新划了一次，代码字符串一个字母没变，但它管的人群变了。

把生效日期当成版本号来用

实操上有个很省事的做法：不要去记哪个代码变了，而是记住你上次对表是按哪个生效日期的版本对的。

官方的码表下载页提供的是纯文本的制表符分隔文件，包含在册表、宏语言成员表、退役表三份，加起来不到两兆。

把这三份文件按日期存进你的仓库，下次更新的时候做一次文本对比，变了什么一目了然。这件事的全部技术含量就是记得存上一版。

如果你的团队用版本控制系统管配置，把这三份文件直接提交进去是最省事的做法：每次更新提交一次，差异对比是现成的，还自带时间线。

被合并掉的那门语言去了哪里？

177个被并进别处的代码，去向不是随便挑的，能查得一清二楚。

177个代码指向118个不同目标

先破一个直觉。原本以为合并的方向应该是大量小语言被吸进少数几门大语言，形成几个巨大的黑洞。

实测不是。177条合并指向118个不同的目标语言，吸收最多的那一门也只吃进了9条。这不是几个黑洞，是一百多次各自独立的局部整理。

这条更新了一个很实用的判断：你不能假设某个消失的代码八成是并进了当地的主流语言。它更可能是并进了一门你同样没听说过的邻近语言。

吸收最多的那门语言是危地马拉的一门玛雅语系语言，吃进了9条，全部是它自己的地区变体。第二名6条，第三名5条。曲线掉得非常快。

奥克语那一次是最好的教材

2007年3月14日，五个代码同一天被并进奥克语oci：奥弗涅语、加斯科涅语、利穆赞语、朗格多克语，还有最有名的那个——普罗旺斯语prv。

普罗旺斯这个词在中文互联网上的知名度，比奥克语高出不知道多少倍。而在这套标准里，它从2007年起就不再是一门有独立代码的语言了。

一个代码的知名度和它的存续状态完全不相关。你凭印象觉得眼熟的代码，可能十七年前就注销了；你觉得没听说过的代码，反而是现役的那个。

这五个名字在中文世界的知名度差别也很大。加斯科涅、朗格多克这些词在旅游和红酒语境里出现得相当频繁，而它们作为语言代码已经消失了十七年。

合并的判据是什么

翻这几条的申请文档，理由几乎都是同一个模式：这几个变体之间可以互相听懂，且没有各自独立的书面标准，因此不构成不同的语言。

互相能不能听懂这条判据，在下一篇里会被拆开细讲，因为它是整个受理流程里最硬的一道闸。这里只需要记住：合并的理由是语言学上的，不是行政上的。

顺便说，这也解释了为什么合并的目标那么分散——判据是逐对比较的，比出来什么样就是什么样，没人在做全局规划。

有一个例外情形值得记住：如果几个变体之间可懂度足够高，但各自有长期存在的独立身份和成熟的书面标准，标准里另有一条通道允许它们保留各自的代码。这条通道在下一篇里是主线。

你的表里怎么处理这一类

合并这一类是四种注销里最好处理的：老代码有唯一去向，直接替换就行，历史数据也可以合并统计。

唯一要注意的是报表的连续性。如果你有一门语言的历史数据是按老代码存的，替换之后那个新代码的历史曲线会突然抬高一截，而这一截不是增长。做趋势分析的时候，代码合并的日期需要在图上标一条竖线。

见过一次因为没标这条线，团队开会讨论了半小时某个语种为什么在某个月突然增长四成。

还有一处容易漏：翻译记忆库和术语库通常也按语言代码分区。代码合并之后，两个库如果不合并，同一门语言会有两套互不相通的记忆，命中率会莫名其妙地低。

还有一种更隐蔽的合并

除了代码被整个注销，还有一种情况：代码没变，但它被划进了某个宏语言底下，成了成员之一。

这种变更在退役表里查不到，只在宏语言成员表里体现。而多数人的对表流程根本不下载那份文件。

2024年10月那次变更就是这么一个例子：两个新代码被创建出来，同时中文这个宏语言的成员清单被更新，把这两个新代码加了进去。成员表变了，在册表和退役表都毫无动静。

所以完整的对表动作是三份文件都要下载。只下在册表的人会漏掉注销，只下在册表和退役表的人会漏掉成员关系变更。

拆分为什么比合并更容易咬人？

102个被拆开的代码，是这张表里真正需要人工判断的那部分。

拆分之后原代码必须整个退役

规则是这样的：如果一个代码原本涵盖的范围被认定为两门或更多门不同的语言，那这个代码不能保留给其中任何一门，必须整体注销，然后为每一门发新代码。

吉大港语那个例子最典型：cit拆成罗兴亚语rhg和吉大港语ctg，连沿用原名的那一半都换了新号。

这个设计有它的道理——保留原码给其中一半，会让所有历史数据的含义变得含糊。但代价是：你手里那条写着老代码的记录，从此没有唯一正确的迁移目标。

这条规则背后的逻辑是：一个代码的含义必须在整个生命周期里保持稳定。宁可让所有人重新映射一次，也不允许同一个代码在不同年份指不同的东西。这个选择对档案是好事，对你的迁移是坏事。

一拆五和一拆十一都出现过

拆分的粒度差别很大。2007年南部壮语ccy被拆成五门语言，2023年泽姆语zua被拆成五个，波尔奇语plj被拆成四个。

而2024年10月那次闽南语的申请，一口气提出要拆成十一门，最后只通过了其中两门。这条在下一篇里是主角。

拆得越碎，你的迁移工作越没法自动化。判据很简单：拆出来超过两个，这批数据就只能靠人按内容判断，脚本能做的只有把它们挑出来。

拆分申请的通过率也随粒度下降。粗粒度的拆分（一分为二、一分为三）通过率明显更高，一口气拆成十来门的申请，多半会被砍掉大部分。

拆分的高发地带在哪里

把139行拆分类的变更按地区看，太平洋、东南亚、非洲三块占了大头。原因很好理解：这几个区域当年登记得粗，一个代码常常涵盖了一大片方言连续体。

这对做东南亚三国那一层语言差异和非洲市场语种选择的人是个提醒：你在这两个区域用到的语言代码，被后续拆分的概率显著高于欧洲和美洲。

欧洲那边拆分很少，但驳回率极高，原因完全是另一回事，下一篇会讲。

反过来，如果你的市场在南美或南亚，拆分的风险相对低。这两个区域早年的登记工作做得比较细，后来需要重新划界的情况少。

拆分留下的痕迹要去哪里找

退役表里，拆分那一类不填合并去向那一栏，改填一段文字说明，写清楚拆成了哪几个。比如泽姆语那条写的就是拆成图莱语等五门语言，并把新代码逐个列出来。

这段文字是纯文本，格式不统一，没法直接解析成结构化数据。想批量处理拆分类的注销，第一步得先接受你要读一遍这102行字。

好消息是102行读完不到二十分钟，而且读完之后你对自己业务涉及的那几门语言会有一个非常具体的印象。

读的时候有个小技巧：先按你自己业务涉及的语系筛一遍，通常一百多行里跟你有关的不超过五行。剩下的可以直接跳过。

宏语言是语言学概念，还是给旧系统留的台阶？

这一节是整篇文章里最想让人记住的一段，也是翻这个库最大的一次意外收获。

宏语言到底是什么

在册表里有63个代码被标为宏语言，底下登记了459条成员关系。成员最多的是萨波特克语59个，其次是克丘亚语44个、马来语37个、阿拉伯语30个、苗语26个、中文19个、壮语18个。

另一头，只有两个成员的宏语言有26个之多。挪威语就是其中之一：no这个两位码指的是宏语言，底下挂着书面挪威语nb和新挪威语nn两门个别语言。

回到开头那个问题。no和nb不是同义词，也不是新旧两种写法，它们是口袋和口袋里的一件东西。你写no，说的是挪威语这个整体；你写nb，说的是其中一种书面形式。这两句话在语义上根本不等价，只是在多数系统的实现里被当成了等价。

官方对宏语言的定义大意是：某些情况下，多门个别语言在使用中被当成一个整体对待，需要一个代码来指代这个整体。听起来像个语言学分类。往下看就知道不是。

加泰罗尼亚语那次，泄露了这个机制的用途

2006年有一份编号2006-129的申请，请求把加泰罗尼亚语拆成两个代码，一个给瓦伦西亚语，一个给不含瓦伦西亚的加泰罗尼亚语。

这份申请的公开文档里有一段几乎是自白的话。注册机构说，按标准的管理规则，这样拆意味着原代码要退役、要发两个新代码，而这会让所有已经在用这个代码的应用面对大量拆分工作，对应的两位码含义也会变得含糊；考虑到这个代码已有的存量应用规模，简单地拆成两个新代码不是一个可接受的处理方案。

注意这句话说了什么：存量规模本身，被当成了不批准拆分的一条理由。这跟这两个变体在语言学上是什么关系没有任何关系。

然后注册机构做了一件更有意思的事——它提出了一个折中方案：把加泰罗尼亚语重新定义成宏语言，同时为两个具体变体各发一个新代码。这个方案被公开征求意见。

但这份申请最后还是被驳回了

一开始我以为故事到这里就结束了，宏语言这个机制就是这么被逼出来的。翻到文件末尾才发现不是——最终的裁决是不批准，加泰罗尼亚语至今仍然是个别语言，不是宏语言。

驳回的理由回到了那条唯一的硬判据：互不相通。文件里写得很直接，连支持这份申请的评议人自己都承认两者可懂度很高，而区域外的语言学者一致把它看成一门语言；这里的差别更多关系到可接受性，而不是可懂度。

这句话值得抄下来贴在墙上。可接受性不是判据，可懂度才是。一门语言的使用者觉得自己说的是另一门语言，这个感受在这套体系里不产生任何效力。

顺带一提，瓦伦西亚语最后拿到的不是一个语言代码，而是一个地区子标签，写法是ca-valencia，由语言标签的登记表授权。标准这一层不给你新代码的时候，标签那一层可能给你一个子标签。这条对做地区变体的人是个非常实际的出路。

同一句话在十七年后又出现了一次，这次通过了

如果只有一个案例，可以说是特例。但2023年12月15日生效的那份梵语申请，把同样的逻辑又说了一遍，而且这次走通了。

那份申请原本只是请求为吠陀梵语创建代码。注册机构采纳了，但做了修改：同时创建古典梵语的代码，并把梵语本身升格为宏语言，底下挂这两门历史语言。

这份裁决书里的原话是：这个方案在既有应用继续使用单一代码的需要，和学界把古典梵语与吠陀梵语当作不同语言的要求之间，取得了平衡。

两次独立的案例，相隔十七年，一次没通过一次通过了，但注册机构用来描述宏语言这个工具的说辞是同一套。到这里可以下结论了。

更有意思的是，宏语言这个身份还能被撤销

前面提到2007年3月14日有五个代码被并进奥克语。那次动作的完整版本还有后半句：奥克语本身的范围，同时从宏语言改回了个别语言。

也就是说，一门语言可以在某一年被升格成宏语言、底下挂几个成员，几年后又被降格回个别语言、成员代码全部退役。这不是理论可能，是已经发生过的事。

在册表里今天查oci，范围那一栏写的是个别语言。而那六个曾经存在过的变体代码，只留在退役表里。

这条推翻了一个很自然的假设：宏语言是一个更稳定的、更上层的分类。它不是层级，它是一次判断，而判断会被推翻。

结论：宏语言是兼容层，不是语言学概念

把三条案例串起来：存量规模能当驳回理由；升格宏语言被明写成对既有应用的照顾；宏语言身份可以被撤销。

宏语言不是一个语言学概念，是为了不打断已经在用这个代码的系统而设的向后兼容层。

这一条直接解释了几件长期让人困惑的事。为什么中文一个代码底下挂着十九门语言；为什么阿拉伯语底下挂着三十门；为什么印尼语和马来语算不算一门语言这个问题在标准里的答案那么别扭。

答案是：标准并没有回答这个问题。它提供了一个中间层，让不想回答的人可以继续不回答。

这对你的实操意味着什么

三条。第一，看到宏语言代码要下钻一层：写zh的时候问自己到底指哪一门，写ar的时候更要问，因为标准阿拉伯语和各地方言之间的差距比你想的大。

第二，宏语言的成员清单会无声地变。上面说过，2024年10月中文那个宏语言就多了两个成员，退役表里查不到，在册表里也只是多了两行。

第三，如果你的系统必须在宏语言和成员语言之间二选一，页面上选宏语言更安全，因为兼容层的设计目的就是兜住不确定性。但报表要按成员语言拆，不然你会永远看不见增长发生在哪一半。

还有一个隐藏的坑：塞尔维亚-克罗地亚语这个宏语言，两位码是sh，在语言标签的登记表里已经被标为不推荐使用，替代值指向具体的三门语言。做塞尔维亚语和保加利亚语市场的时候，如果你的老系统里还留着sh，那是一处需要主动清理的地方。

这个库这十八年在忙的是什么？

把2250行变更按年份铺开，能看出一条挺清楚的弧线。

新建量的曲线已经压平了

按生效年算新建的语言代码数：2008年145个是峰值，2012年137个，2013年125个，然后一路下滑，2019年只有16个，2024年14个。

累计下来，这十八年一共新建了944个代码。前六年就占掉了六成。

这个库已经从造语言转成了改名字。这个转变对你有个直接好处：你现在维护的这份代码表，未来几年被新增项冲击的概率很低，真正的变数在改名和调整范围那一侧。

这条也解释了为什么这些年新出现的语言代码，你多半没见过。它们集中在非洲和太平洋那些原本登记就粗的区域，而不是你的目标市场。

申请量的谷底在哪一年

按申请年份数，2007年是峰值258条，2011年166条，2012年151条。然后逐年下滑，2022年34条，2023年只有5条。

2023年那个数字低得有点异常。合理的解释是那一年标准本身在修订，很多事情在等结果。

2024年提交的申请回升到了十九条，但到这一年年底，这十九条一条都还没生效——从提交到出结果的滞后大约是一年，慢的能拖到三年以上。

有个细节值得留意：申请量的谷底跟变更行数的谷底不在同一年。行数最少的年份是2024年，只有29行；而申请数最少的是2023年。两个数之间隔着一年左右的处理周期。

一份申请要等多久

说到等，这个库里等得最久的那几份值得单独拎出来。

2006年提交的一份关于中古希腊语的申请，2023年12月15日才有结果，整整十七年。2009年提交的两份希腊语相关申请，也是同一天出结果，等了十四年。2011年那份梵语申请等了十二年。

这几份为什么等这么久，裁决书里写了：它们涉及历史语言能不能被当成宏语言拆分这个先例问题，而这个问题在ISO 639整套标准的修订过程中一直悬着。它们等的不是评审，是标准本身。

对你的实际含义是：你不能指望通过盯着申请队列来预判变更。队列里躺着的东西可能十年不动，而真正影响你的那些变更往往来自一次批量整理，压根不在你关注的名单上。

修改类变更在改什么

前面提过修改的属性分布，这里补一个更有用的角度：修改类变更的驳回率只有6.5%，而新建是25.3%、拆分是25.9%。

换句话说，想改一门已有语言的属性很容易过，想把一门语言立起来要难四倍。

这条判据在下一篇里会被展开成一整篇文章的主线，因为它背后藏着这套体系真正的价值取向。

还有一个数字值得记住：合并的驳回率是9.8%，注销是8.4%，都不高。也就是说，减少一门语言比增加一门语言容易得多。

这件事怎么落到你的站和你的报表上？

前面全是背景，这一节是能直接抄走的部分。

先把语言代码出现的位置数清楚

典型的多语言站，语言代码至少出现在这几处：页面根元素的语言声明、每一条hreflang、站点地图里的语言备用链接、结构化数据里的语言字段、商品数据源的语言与目标国家设置、分析工具的语言维度、内容管理系统的语言配置、以及翻译记忆库的语言对。

八处。结构化数据里那个语言字段该怎么填那一篇讲过其中一处的特殊要求，这里要说的是：这八处很少由同一个人维护，也很少有任何一处会校验另一处。

所以第一步不是改，是数。把这八处各自现在写着什么导出来，放进同一张表里横着看一遍。

数的时候建议连同每一处的负责人一起记下来。这份清单真正的价值不在技术，在于它把一件横跨四五个团队的事收敛成了一张能开会的表。

hreflang取值真正该对的是另一份表

有个容易搞混的点值得说清楚：hreflang里能填的值，规则并不直接来自三位码那份标准，而来自语言标签的注册表。

IANA维护的语言子标签登记表是那份实际生效的清单。它会从ISO的码表里同步，但同步有延迟，而且它对已经废弃的子标签处理方式是标注为不推荐并给出替代，不是直接删掉。

这个差别对你有利：一个在ISO那边已经注销的代码，在语言标签登记表里通常还留着，并带着一条指向替代值的说明。这条说明就是你做迁移时最可靠的依据。

所以对表的顺序应该是：先看ISO的退役表知道发生了什么，再看语言标签登记表拿到官方推荐的替代值。

这两份表还有一个结构性差别：ISO那边一个代码只有在册或注销两种状态，语言标签登记表那边还有一个中间态叫不推荐使用。中间态才是给迁移用的。

四种注销的处理方式各不相同

把动作按注销理由分开定，比一刀切省事得多。

被并进别的语言那177个：可以脚本自动替换，历史数据合并统计，图上标一条竖线。重复登记那33个：同样可以自动替换，因为本来就是同一门语言的两个号。

被判定查无此语言那72个：直接删掉这一行，同时去查你的内容库里有没有真的标着这个语言的页面，如果有，那批内容的语言标注从一开始就是错的。被拆开那102个：脚本只负责挑出来，逐条人工判断，别自动。

把这四类动作写成一份四行的处理规则，贴在对表脚本的注释里。下次换人做这件事的时候，这四行比任何文档都管用。

报表侧要防的是那种不报错的错

语言维度出问题的典型症状不是报错，是数字看着挺正常但讲不通。

常见的三种：某个语种的量在某个月阶梯式变化而内容没动过；两个语种的量此消彼长而总量不变；某个语种的转化率长期显著异常，高得或低得没有道理。

第三种最值得警惕，因为它常常是页面语言被机器认错和代码注销两个原因叠加的结果。先查代码，再查识别，顺序反了会绕很久。

还有一种更隐蔽的：某个语种在报表里从来就没出现过。这通常不是没有流量，而是这门语言的代码根本不在报表工具的维度取值里，那批访问被归到了其他一栏。

把这件事变成一年两次的日程

最后给一个具体到能贴在日历上的方案。

每年二月和十一月各做一次，每次不超过两小时。动作是：下载三份码表存进仓库；跟上一版做文本对比；把变更行按四种理由分类；对照你站上那八处位置的清单，找出交集；处理交集，其余归档。

八处位置的清单只需要建一次，后面每年复用。第一次建清单大概要半天，之后每次两小时，这是这件事的全部成本。

如果实在挤不出这两小时，退而求其次的做法是只做一件事：拿退役表跟你站上那份语言配置做一次交集。这一步五分钟，能挡住九成的问题。

我一开始猜错了哪几条？

翻这个库之前先写了一份预期清单，翻完之后逐条对账。错的比对的有意思。

猜错一：以为注销的主要理由是查无此语言

这是错得最离谱的一条，也是价值最高的一条。实测查无此语言只占19%，而它还在只是换了地方那两类加起来占72%。

猜错的根源是把注销想象成纠错。实际上这个库里绝大多数注销是重新划界，跟对错无关。

纠错和重新划界，在你的数据迁移里是完全不同的两件事：前者该删，后者该换。猜错这一条的人，会把该换的也删掉。

这条猜错还牵出一个更一般的教训：任何一份看起来在做清理的记录，先别默认它清理的是错误。它更可能是在重新划界，而划界这件事没有对错。

猜错二：以为合并会集中到少数几门大语言

实测177条合并指向118个不同目标，最多的一门只吸收9条。

这条猜错的后果是策略性的：如果合并真的集中，你只需要关注几门大语言就能覆盖大部分风险；实际情况是分散的，只能按你自己涉及的语言逐个查。

好在你涉及的语言通常不超过二十门，逐个查也就是半小时的事。

顺带修正一个相关的直觉：合并的方向也不总是小并进大。有几条合并的目标语言，使用人口比被合并掉的那门还少，判据只看语言学关系，不看规模。

猜错三：以为修改类里参考名会占四成以上

实测参考名32.0%，指称范围30.8%，两者几乎并列。

这条猜错得不算严重，但它改变了一个判断：如果改名占绝对多数，那对表主要是显示层的事；实际上指称范围的改动占了差不多同样的份额，而指称范围变了意味着这个代码管的东西变了，那是数据层的事。

附加名称那一类占23.9%，也常被忽略。它的意思是一门语言多了个别名，而别名恰恰是用户在搜索框里会打的那种写法。做词表的人应该关心这一栏。

猜对的那一条也值得说

猜对的是2018年那批修改：确实是一次批量整理，88行全部同一天生效，76行属于同一个语系。

猜对不稀奇，稀奇的是这条猜对之后引出了一个原本没想到的问题：批量整理不改代码，只改代码的含义，所以它在任何基于字符串比对的监控里都是隐身的。

换句话说，你最容易发现的变更是最不重要的那一类，最难发现的是最要紧的那一类。这个顺序不太友好，但知道了就能反过来用——对表的时候先看修改类，再看注销类。

所以更实用的对表顺序是：先看修改类里指称范围和成员关系那两栏，再看注销表，最后才扫新建。跟大多数人的直觉正好相反。

哪些相邻的问题不归这一层管？

最后划一下边界，免得把不同层的问题混着解。

代码有没有，和软件里能不能选，是两件事

一门语言在标准里有代码，不代表用户的设备能设成它。安卓、火狐、Chrome三家界面语言清单的实测那一篇量过：三家最多的一份只有181门，跟七千多门差着两个数量级。

标准这一层管的是身份，软件那一层管的是可达性。身份是可达性的前提，但远远不是充分条件。

一门语言同时具备两个条件才算真正可用：标准里有代码，且用户的设备和浏览器清单里有它。只满足前一个，你能写出合法的标签，但接不到用户。

代码有没有，和本地化数据全不全，也是两件事

拿到代码只是拿到一个编号。这门语言的日期怎么写、数字怎么分节、星期从哪天开始，属于另一套数据。本地化数据的自有率实测和非公历纪年数据的缺口两篇讲的都是那一层。

常见的错误组合是：拿到了三位码，就以为这门语言在系统里能正常显示日期和金额。那两件事之间没有任何自动关联。

判断方法很简单：拿到代码之后去查一下这门语言的本地化数据文件有多大。几百字节的多半是个空壳，真正有自有数据的文件通常在几十KB以上。

代码这一层不解决市场决策

最后一条，也是最要紧的一条。这套体系判定两个变体是不是不同的语言，用的是语言学判据，而你判定要不要为它们各做一套内容，用的是市场判据。

这两套判据经常给出相反的答案。捷克语和斯洛伐克语有两个代码但内容能大量复用，北欧三语的复用边界又跟代码数量对不上，克罗地亚语和斯洛文尼亚语更是两个方向都不成立。

标准告诉你这是几门语言，它不告诉你该做几套内容。后面那个问题，得你自己拿转化数据回答。

还有一个方向的错配同样常见：两个市场共用一个代码，但用户搜的词分叉得很厉害。乌克兰语和俄语那种双语市场是典型，代码这一层完全看不出来。

所以这两层的正确用法是：代码这一层负责把技术链路铺对，市场那一层负责决定投多少钱。前者是及格线，后者才是策略。

常见问题解答

怎么快速查一个语言代码是不是已经被注销了？

去注册机构的码表下载页拿那份退役表，是个制表符分隔的纯文本文件，一共几百行。用表格软件打开，第一列就是被注销的代码，直接搜就行。同一份下载页还有在册表和宏语言成员表，建议三份一起拿，对表的时候要交叉着看。整套动作不到五分钟。

发现代码被注销了，直接替换成新代码就行吗？

要分情况。如果注销理由是被合并进另一门语言，那有唯一的去向，可以直接替换。如果理由是被拆开，就不能自动替换，因为原来那个代码涵盖的范围现在对应两个或更多新代码，你得逐条判断这批内容具体属于哪一个。如果理由是查无此语言，那就该删，同时要回头查你为什么会有标着这门语言的内容。

hreflang里到底该写两位码还是三位码？

规则是有两位码就写两位码，没有就写三位。在册的七千多门语言里只有184门有两位码，所以做小语种基本上必然会遇到只能写三位的情况。要注意的是，判断依据应该是语言标签的登记表而不是凭印象，登记表里对每个子标签是否推荐使用都有标注。

宏语言代码和它的成员代码，该用哪一个？

页面上和hreflang里通常写宏语言代码更安全，因为它的设计目的就是兜住不确定性，下游系统对它的支持也更完整。但内部报表建议按成员语言拆开统计，否则某一门成员语言的增长会被整个口袋的数字盖住。两套并存不冲突，页面写宏语言、报表拆成员，是比较稳妥的组合。

这些代码变更会影响已经收录的页面吗？

不会直接影响收录，搜索引擎不会因为一个语言代码被注销就把页面从索引里拿掉。真正的影响在匹配环节：如果一个用户的语言偏好指向的是新代码，而你的页面声明的是老代码，两边对不上，语言协商和地区版本匹配就接不住这个用户。影响是渐进的，也因此不容易被发现。

多久对一次这张表比较合适？

一年两次足够。这个库的变更是集中生效的，多数年份只有一到两个生效日期，而且往往在年初。所以二月和十一月各做一次，正好卡在生效窗口之后。每次的动作是下载三份码表、跟上一版做文本对比、按注销理由分类处理，两小时之内能结束。