语言、文字与书写系统

「中文」是语言，「汉字」是文字，「从左往右」是方向。日常说话时这三件事搅在一起没关系，一落到代码里就得出事：lang 属性填的是语言，字体按文字分组，而方向是另一套属性。

三个词，三件事#

它们不是一一对应的，这正是麻烦所在：

• 一种语言可以用两种文字写：塞尔维亚语用西里尔（српски）也可以写拉丁（srpski）；汉语有简体与繁体两套写法；
• 一种文字服务很多语言：拉丁字母撑着西欧大半个语族，阿拉伯字母服务阿拉伯语、波斯语、乌尔都语；
• 同一个文字里方向也可能变：中文古书竖排，现代网页横排（见 书写方向）。

语言标记：zh-CN 到底在说什么#

网页上写语言用的是 BCP 47（RFC 5646）定义的语言标记。结构是固定顺序的几段：

language [-script] [-region] [-variant…]
  zh         -CN
  zh        -Hans  -CN
  sr        -Latn  -RS

大小写只是书写习惯：BCP 47 规定匹配时不分大小写，zh-cn 与 zh-CN 等价。但请按习惯写，因为人读代码时靠这个区分「这一位是文字还是地区」。

几个常见标记：

zh-CN 与 zh-Hans 的区别值得记住：前者说「哪个地区」，后者说「哪种写法」。两者经常一致，但新加坡的 zh-SG 用简体、马来西亚的 zh-MY 也用简体，「地区」和「文字」并不是同一件事。

那些「长得像但不是它」的写法#

同一个语言，在不同系统里有好几种拼法。你在配置文件里见到的多半不是 BCP 47：

两条实用结论：

1. 要跟标准打交道（lang、Accept-Language、搜索引擎、JSON-LD）就走 BCP 47，其余场合先看清楚对方要什么；
2. 别对 zhCN 这种写法做前缀匹配——它没有规范定义，谁也不知道下一家 SDK 会不会写成 zh-cn、zh_CN 或 zhHansCN。要做匹配就先把它们归一化成 BCP 47。

文字代码：ISO 15924 的四位码#

文字也有编号，是 ISO 15924 的四位字母（首字母大写）：

有两条容易看漏：

• Jpan / Kore / Hrkt 是「组合别名」：Jpan 的定义就是“汉字 + 平假名 + 片假名”，Kore 是“谚文 + 汉字”。日文不是一种字符，而是几套字符的组合——这解释了为什么「按文字选字体」在日文上格外难；
• Hans / Hant 在 ISO 15924 里是独立代码，但在 Unicode 的 Script 属性里没有。一个简体汉字和一个繁体汉字的 Script 都是 Hani。想区分简繁，Script 帮不上忙。

一对多与多对一#

所以「这个字体支不支持中文」这种问法，严格来说要拆成两问：它有没有汉字的接口字形（cmap 覆盖），以及它有没有按 zh-Hans / zh-Hant / ja 提供对应的字形变体（locl 特性）。前者看覆盖率，后者看特性表。

汉字的三种「不同」#

中文口语里都叫「异体字」，实际上混着几件机制完全不同的事。分清它们，才知道该换字体、该加变体选择符，还是该换码位。

一、同一个码位，按语言换字形#

同一个码位，中日韩三地各有各的惯例写法。浏览器会按元素的 lang 去挑字形——下面是同一串字符，只有 lang 不同：

lang="ja"

骨直草者

lang="zh-CN"

骨直草者

lang="zh-HK"

骨直草者

几处常被举到的差别：草（U+8349）的草字头，繁体中文习惯四笔（⺿），简体中文与日文习惯三笔（⺾）；骨 里那个框在某些地区写法里像镜像；者 有的写法多一笔、有的少一笔。这些差别看着很小，对本地读者却是「这不是我的字」的信号。

它们都是一个码位，靠字体的 locl 特性按语言系统挑字形。所以「这个字体支持中文」并不等于「它画得对」——覆盖了码位，不等于给你这套惯例。

繁体内部也不是一块：台湾与香港各有一套字形参考（前者是国字标准字体，后者是常用字字形表），所以有的字上 zh-Hant-TW 与 zh-Hant-HK 也会分家。而标 lang 只是发出请求——能不能兑现，取决于这台机器上有没有字体愿意接。

⚠️ 上面那张图其实混着两件事：lang 挑的首先是字体，不是字形。不同语言能用的字体未必来自同一个家族，风格、笔形、字面大小都可能不同，所以你看到的「有差别」里，一部分是字形惯例，另一部分是两个字体本身的差别。真要比较字形惯例，得用同一家族的字体——像 Source Han / Noto CJK 那样一个家族内部按 locl 切简繁日韩港的，才只剩字形差异。

二、Unicode 里就是两个码位#

有些变体在编码阶段就分了家：

后果很实在：字数不一样、搜索不一样、比较也不一样。'內' === '内' 是 false，indexOf 找不到，数据库去重去不掉。所以做跨地区文本处理时，「什么算同一个字」得先定下来——Unicode 不会给你一个通用的答案，它只保证后面那类兼容汉字的等价。

三、兼容汉字：同一个字、两个码位，而且强制等价#

CJK 兼容汉字区（U+F900–FAFF）里有一批字，是为了跟老编码逐字节往返才加的副本：

它们有规范分解（见 字符属性）：U+F902 分解成 U+8ECA。所以任何形式的 normalize() 都会把它们合并回本位那个。

⚠️ 但不 normalize 的字符串比较里它们是两个字符——老系统导出的文本、从 PDF 复制出来的文本里经常能碰到。处理用户输入时先 normalize('NFC')，这类问题自动消失。

四、要明确指定时：变体选择符#

一个码位对应多个字形，而又必须明确说「我要这个写法」（人名、古籍、商标）时，用变体选择符：码位后面跟 U+FE00–FE0F 或 U+E0100–E01EF。字体要在 cmap 的变体序列表里声明支持哪些组合，这套机制叫 IVS（Ideographic Variation Sequence）。

也就是 码位与平面 里说过的同一个东西，只是汉字这边用得最多。

从一段文本推断书写系统#

经常需要「拿到一句用户输入，猜它是什么文字」——为了选字体、为了决定断行规则、为了给排版预览挑样例。直接读 Unicode 的 Script 属性（Scripts.txt）是最省事的第一步：

1. 每个码位取 Script 值；
2. 丢掉 Zyyy（数字、空格、标点）与 Zinh（组合标记）——它们对「这是什么文字」没有信息量；
3. 剩下的里面取占比最大的那个。

这套办法能用，但有三件事它做不到：

• 分不出简繁：Script 里没有 Hans / Hant，简体繁体都是 Hani；
• 分不出中日韩：纯汉字的句子，中文、日文、韩文都是 Hani。日文有假名、韩文有谚文时可以靠它们判出来，但「漢字」两个字的句子照样分不出；
• 分不出同一文字下的语言：一串拉丁字母可以是英语、法语、德语、土耳其语；一串西里尔同样跨着俄语、乌克兰语、保加利亚语。

还有一层：有些字符的 Script 是 Common，但它明确属于某几种文字。比如长音符 ー（U+30FC）在 Scripts.txt 里是 Common，要看 ScriptExtensions.txt 才知道它同时属于平假名与片假名；天城文的句号 ।（U+0964）也属于一大票印度系文字。所以「丢掉所有 Zyyy」会连这类字符一起丢掉——要不要用 Script_Extensions，取决于你猜的是「大概是什么文字」还是「这段文本能交给哪种字体」。

要做到「猜语言」而不只是「猜文字」，得换数据。 唯一有区分力的东西是各语言的常用字符集：同样一个汉字，在中文常用字表里出现，在日文常用字表里没出现，这件事比它的 Script 值有用得多。CLDR 的 exemplarCharacters 就是这份表（由各语言的本地化社区维护），拿它比对「这段文本的字落在谁的表里」，才能把 zh-Hans / zh-Hant / ja / ko 分开。

西里尔那种情况还有个小技巧：单个语言的字母表彼此不通用（俄语没有 ў，乌克兰语有；保加利亚语没有 ы），所以可以取多个西里尔语言的交集当「核心西里尔集」，落在核心集里就算，边角字母再单独判断。

⚠️ 这些都只是「推断」：短文本、专有名词、混排（中文里夹英文品牌名）随时会翻车。推断结果要能显示出来、并且允许用户改，别默默按它去换字体。

前端能控制什么#

本站怎么用这两个概念#

• 样本图按书写系统出：字体详情页除了几门有样句的语言（中文、日文、英文……），还会按书写系统各出一行字，让泰文、阿拉伯文这类字体不至于拿一张拉丁字母图当封面；
• 语言标记只用标准的 BCP 47 写法：<html lang> 写 zh-CN，JSON-LD 的 inLanguage 写 zh-CN / en——都是能与外部工具对上的那种拼法；
• 文档中心的正文语言只看路径（/docs 英文、/zh/docs 中文），不跟 cookie：那是内容，不是界面偏好。代价是界面语言和正文语言可以对不上，这是有意接受的。

延伸阅读#

• BCP 47（RFC 5646，语言标记）、RFC 4647（匹配与前缀回退）
• ISO 15924（文字代码表，unicode.org/iso15924/）
• UAX #24（Unicode Script Property）、Scripts.txt / ScriptExtensions.txt
• CLDR 的 exemplarCharacters（各语言的常用字符集）
• 本站：字符属性（script 作为字符属性）、书写方向