# General Translation Knowledge Base: 什么是区域设置代码（例如 en-US 和 en-GB）？
URL: https://generaltranslation.com/zh/kb/locale-codes.mdx
Docs index: https://generaltranslation.com/llms.txt
Description: 区域设置代码用于标识一种语言，并在必要时标识其文字体系和地区，例如 en-US 表示美国英语，zh-Hant-TW 表示台湾地区使用的繁体中文。大多数软件使用由 ISO 代码组合而成的 BCP 47 标签。General Translation 在 gt.config.json 中使用 BCP 47 代码来指定源区域设置和目标区域设置。
Category: 按区域设置格式化
Last updated: 2026-10-28
Authors: General Translation Team
Published: 2026-10-28

区域设置代码用于指明一种语言，并在必要时指明书写该语言所用的文字体系及其使用地区。`en-US` 表示美国英语，`en-GB` 表示英国英语，`zh-Hant-TW` 则表示台湾地区使用的繁体中文。浏览器、HTTP、HTML 以及 JavaScript 的 `Intl` API 都遵循同一套代码标准，即 BCP 47。因此，你选择的代码将决定用户看到的翻译、日期格式以及适用的复数规则。

## BCP 47 标签的构成

[BCP 47](https://www.rfc-editor.org/info/bcp47) 是 IETF 制定的语言标签标准。它由两份文档组成：定义语法的 [RFC 5646](https://www.rfc-editor.org/rfc/rfc5646.html)，以及定义标签匹配方式的 [RFC 4647](https://www.rfc-editor.org/rfc/rfc4647.html)。一个标签由若干以连字符分隔的子标签组成，且始终遵循以下顺序：

| 子标签      | 形式                       | 来源                           | 示例                          |
| -------- | ------------------------ | ---------------------------- | --------------------------- |
| 语言 (必填)  | 2 或 3 个字母                | ISO 639，取最短的可用代码             | `en`、`zh`、`gsw`             |
| 文字体系     | 4 个字母                    | ISO 15924                    | `Hant`、`Hans`、`Latn`、`Cyrl` |
| 地区       | 2 个字母或 3 位数字             | ISO 3166-1 alpha-2 或 UN M.49 | `GB`、`BR`、`419`             |
| 变体       | 5 到 8 个字符，或 1 位数字加 3 个字符 | 在 IANA 注册                    | `de-1901` (传统德语拼写)          |
| 扩展       | 单个字母，后接其子标签              | `u` 由 Unicode 定义             | `ar-EG-u-nu-latn`           |
| 私有用途     | `x`，后接自定义子标签             | 由你自行定义                       | `en-CA-x-ca`                |

所有有效的子标签都收录在 [IANA Language Subtag Registry](https://www.iana.org/assignments/language-subtag-registry/language-subtag-registry) 中，查询代码只需参考这一处。其 2026 年 9 月版共收录 8,276 个语言子标签和 305 个地区子标签，并为已停用的代码标注了对应的替代代码。

将这些子标签组合起来，就能准确表达你想要的含义。`sr-Latn-RS` 表示塞尔维亚使用的、以拉丁字母书写的塞尔维亚语。`es-419` 表示拉丁美洲及加勒比地区使用的西班牙语，其中 `419` 是表示多国地区的 UN M.49 代码。RFC 5646 还给出了一个更细微的例子：`de-CH` 表示瑞士使用的德语 (瑞士标准德语) ，而瑞士德语 (Schweizerdeutsch) 则是另一种语言，有自己的代码 `gsw-CH`。

### 扩展改变的是格式化，而非语言

`-u-` 扩展由 [RFC 6067](https://www.rfc-editor.org/rfc/rfc6067.html) 定义，其键列于 [Unicode 的 LDML 规范](https://unicode.org/reports/tr35/)中，用于携带格式化偏好。`-u-nu-` 指定数字系统，`-u-hc-` 指定小时制，`-u-ca-` 指定历法，`-u-co-` 指定排序规则。`en-US-u-hc-h23` 仍然是美式英语，只不过显示为 `14:05`，而不是 `2:05 PM`。下文的示例会同时展示这两种效果。

## 大小写、连字符和下划线

标签不区分大小写，因此 `EN-gb` 和 `en-GB` 含义相同。不过，RFC 5646 仍[推荐了一种约定写法](https://www.rfc-editor.org/rfc/rfc5646.html#section-2.1.1)：语言小写，文字体系首字母大写，地区大写，例如 `zh-Hant-TW`。在文件名或 URL 中使用代码之前，请先将其规范化为这种形式，以免 `/en-gb/` 和 `/en-GB/` 变成两个不同的路径。

BCP 47 使用连字符分隔子标签。部分平台有各自的格式，因此请在系统边界处进行转换：

| 系统                                                                                                 | 格式                                                  | 示例                                 |
| -------------------------------------------------------------------------------------------------- | --------------------------------------------------- | ---------------------------------- |
| Web (HTML `lang`、`hreflang`、`Accept-Language`、`Intl`)                                              | 使用连字符的 BCP 47                                       | `en-US`, `zh-Hant-TW`              |
| [POSIX](https://pubs.opengroup.org/onlinepubs/9799919799/basedefs/V1_chap08.html) (`LANG`、`LC_*`)  | `language[_territory][.codeset][@modifier]`         | `en_US.UTF-8`                      |
| [Unicode CLDR](https://unicode.org/reports/tr35/) 和 ICU 区域设置 ID                                    | 使用下划线；也接受连字符                                        | `en_US`                            |
| [Java](https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/util/Locale.html)         | `toString()` 返回下划线形式，`toLanguageTag()` 返回 BCP 47 形式 | `en_US`, `en-US`                   |
| [Android 资源](https://developer.android.com/guide/topics/resources/providing-resources)             | 在地区前加 `r`，或对 BCP 47 标签使用 `b+` (Android 7.0 及更高版本)   | `values-en-rUS`, `values-b+es+419` |

JavaScript 不接受下划线形式：`Intl.getCanonicalLocales('en_US')` 会抛出 `RangeError` 异常。

## 常见错误

* **用 `en-UK` 代替 `en-GB`。** 英国的 ISO 地区代码是 `GB`，`UK` 并不在 IANA 注册表中。Unicode CLDR 将 `UK` 视为别名，因此 JavaScript 会悄悄把 `en-UK` 转换为 `en-GB`，但 [Google 会忽略](https://developers.google.com/search/docs/specialty/international/localized-versions) hreflang 中的 `UK`。请使用 `en-GB`。
* **在语言位置填了国家代码。** `jp`、`cn`、`gr`、`dk` 和 `cz` 都不是语言代码：日语是 `ja`，中文是 `zh`，希腊语是 `el`，丹麦语是 `da`，捷克语是 `cs`。有些国家代码甚至对应完全不同的语言：`se` 是北萨米语 (瑞典语是 `sv`) ，`kr` 是卡努里语 (韩语是 `ko`) ，`uk` 是乌克兰语，`be` 是白俄罗斯语。`jp` 由两个字母组成，因此能通过语法检查。所以请实际查证代码，不要因为能解析就认为它正确。
* **想表示简体中文却用了 `zh-CN`。** 对中文而言，决定书面文本的是文字体系，地区只是隐含了某种文字体系：`zh-TW` 会扩展为 `zh-Hant-TW`，`zh-SG` 会扩展为 `zh-Hans-SG`。如果同一份简体翻译同时面向中国大陆和新加坡，请将其标记为 `zh-Hans`；繁体则使用 `zh-Hant`，措辞有差异时再加上地区，例如 `zh-Hant-HK`。
* **已停用的代码。** `iw` (希伯来语) 、`in` (印度尼西亚语) 和 `ji` (意第绪语) 已于 1989 年弃用，分别由 `he`、`id` 和 `yi` 取代。Java 17 之前的版本仍会生成这些旧代码，因此在较旧的数据中仍能见到它们。进行规范化即可将其替换。
* **画蛇添足的标签。** `en-Latn-US` 额外指定了文字体系，而英语几乎总是用这种文字书写。RFC 5646 [建议](https://www.rfc-editor.org/rfc/rfc5646.html#section-4.1)省略不提供区分信息的子标签，并指出在基本过滤 (basic filtering) 模式下，请求 `en-US` 不会匹配到标记为 `en-Latn-US` 的内容。
* **有效但使用方不支持的代码。** `es-419` 是有效的 BCP 47 代码，但 Google 的 hreflang 只接受 ISO 3166-1 地区，因此请将这些页面标注为 `es` 或具体国家。 (参见[什么是 hreflang？](/kb/what-is-hreflang)。)

## 通用代码还是区域代码：该用哪一种？

W3C 关于[选择语言标签](https://www.w3.org/International/questions/qa-choosing-language-tags)的建议是：标签应尽可能简短，只有当地区信息确有必要时才加上地区。据此可以为每个区域设置确定规则：

* **使用纯语言代码** (`fr`、`de`、`ja`) ：一份译文即可覆盖所有使用该语言的地区。
* **添加地区**：拼写、词汇或法律文本存在差异，且你会分别维护不同译文，例如 `en-US` 与 `en-GB`、`pt-BR` 与 `pt-PT`、`es-MX` 与 `es-ES`、`fr-CA`。
* **对于中文、塞尔维亚语等使用多种文字体系的语言，先确定文字体系**：`zh-Hans` 与 `zh-Hant`、`sr-Cyrl` 与 `sr-Latn`。
* **即使译文共用，格式化时也应使用区域代码。** 只翻译一次的 `en` 文本，仍可按访问者的 `en-GB` 格式化日期：`en-GB` 写作 28/10/2026，而 `en-US` 写作 10/28/2026。

对软件而言，纯语言代码并不等于没有地区。CLDR 的 likely-subtags 数据会补全最可能的文字体系和地区，因此 `pt` 会扩展为 `pt-Latn-BR`，`zh` 会扩展为 `zh-Hans-CN`。如果你的 `pt` 译文是欧洲葡萄牙语，请将其标记为 `pt-PT`。

当用户的区域设置不在支持范围内时，软件会执行回退。RFC 4647 的 [lookup](https://www.rfc-editor.org/rfc/rfc4647.html#section-3.4) 会从末尾逐个去掉子标签，直到找到匹配项 (`zh-Hant-HK` → `zh-Hant` → `zh`) ，其他匹配算法还会尝试同级地区。如何读取浏览器偏好以及如何在这些算法之间取舍，请参阅[如何检测用户的浏览器语言](/kb/detect-user-language)。

## 在 JavaScript 中规范化区域设置代码

[`Intl.getCanonicalLocales`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Intl/getCanonicalLocales) 会修正字母大小写，并替换已弃用的子标签或别名子标签；[`Intl.Locale`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Intl/Locale) 则可以补全最可能的文字体系和地区：

```js title="locale-codes.mjs"
const names = new Intl.DisplayNames(['en'], { type: 'language' });

for (const tag of ['EN-gb', 'zh-tw', 'iw-IL', 'en-UK', 'jp', 'es-419', 'en_US']) {
  try {
    // 规范化：修正字母大小写，并替换已弃用的子标签或别名子标签
    const [canonical] = Intl.getCanonicalLocales(tag);
    // 补充最可能的文字体系和地区
    const maximized = new Intl.Locale(canonical).maximize().toString();
    console.log(`${tag} -> ${canonical} (${maximized}): ${names.of(canonical)}`);
  } catch (error) {
    console.log(`${tag} -> ${error.name}: ${error.message}`);
  }
}

// -u- 扩展改变的是格式化方式，而非语言
const time = new Date(Date.UTC(2026, 9, 28, 14, 5));
for (const tag of ['en-US', 'en-US-u-hc-h23', 'ar-EG', 'ar-EG-u-nu-latn']) {
  const formatted = new Intl.DateTimeFormat(tag, {
    hour: 'numeric',
    minute: '2-digit',
    timeZone: 'UTC',
  }).format(time);
  console.log(`${tag}: ${formatted}`);
}
```

在 Node.js 24.19.0 上运行 `node locale-codes.mjs` 的输出结果：

```text title="Output"
EN-gb -> en-GB (en-Latn-GB): British English
zh-tw -> zh-TW (zh-Hant-TW): Chinese (Taiwan)
iw-IL -> he-IL (he-Hebr-IL): Hebrew (Israel)
en-UK -> en-GB (en-Latn-GB): British English
jp -> jp (jp): jp
es-419 -> es-419 (es-Latn-419): Latin American Spanish
en_US -> RangeError: Incorrect locale information provided
en-US: 2:05 PM
en-US-u-hc-h23: 14:05
ar-EG: ٢:٠٥ م
ar-EG-u-nu-latn: 2:05 م
```

有两行值得细看。`jp` 能通过规范化，但返回结果中没有显示名称，因为这项检查只校验语法，并不验证该语言是否真实存在。另外，`ar-EG-u-nu-latn` 会保留阿拉伯文字，但数字改用西方数字。

## General Translation 如何使用区域设置代码

General Translation 全面采用 BCP 47 代码。在 `gt.config.json` 中，[`defaultLocale`](/docs/cli/reference/config#default-locale) 指定源内容所用的区域设置 (默认为 `en`) ，[`locales`](/docs/cli/reference/config#locales) 则列出所有目标区域设置：

```json title="gt.config.json"
{
  "defaultLocale": "en-US",
  "locales": ["en-GB", "fr-CA", "pt-BR", "zh-Hant"]
}
```

CLI 在执行任何翻译之前，会先检查这些代码。遇到无效代码时，它会停止运行；当 `defaultLocale` 的范围比目标区域设置更宽泛时，它同样会停止：从 `en` 翻译到 `en-GB` 会失败，因此添加英式英语的项目应如上所示，将源设置为 `en-US`。

平台支持翻译成其[支持的语言区域](/docs/platform/dashboard/reference/supported-locales)列表中的区域设置。General Translation 通常会将等效代码视为同一个区域设置：`fr`、`fr-FR` 和 `fr-Latn-FR` 会得到相同的翻译，而 `ja` 和 `ja-JP` 更新的是同一份已存储的翻译。 (参见[理解区域设置代码](/docs/platform/core/guides/locale-codes)。) 

如需使用未注册为语言的代码 (例如在 URL 中使用 `cn`) ，可通过 General Translation 的 [`customMapping`](/docs/cli/reference/config#custom-mapping) 将其设为某个标准代码的别名 (将 `cn` 映射到 `zh`) ，还可覆盖其显示名称。至于 hreflang，[区域设置别名 SEO 指南](/docs/react/nextjs/locale-alias-seo)介绍了如何将该别名映射回 `zh`。

`generaltranslation` Core 库以独立函数的形式导出区域设置辅助函数，无需 API 密钥即可使用。以下返回值基于 `generaltranslation` 9.5.8：

```js title="check-locales.mjs"
import {
  standardizeLocale,
  isValidLocale,
  getLocaleName,
  determineLocale,
} from 'generaltranslation';

standardizeLocale('EN-gb'); // 'en-GB'
isValidLocale('en_US'); // false
isValidLocale('jp'); // false
getLocaleName('pt-BR', 'en'); // 'Brazilian Portuguese'
determineLocale(['fr-CA', 'en-US'], ['en', 'fr', 'zh-Hant']); // 'fr'
```

[`standardizeLocale`](/docs/platform/core/reference/utility-functions/locales/standardize-locale) 用于修正字母大小写；[`isValidLocale`](/docs/platform/core/reference/utility-functions/locales/is-valid-locale) 会拒绝下划线形式的代码，以及 `jp` 这类 `Intl` 会放行的代码；[`getLocaleName`](/docs/platform/core/reference/utility-functions/locales/get-locale-name) 返回可在语言选择器中展示的显示名称；[`determineLocale`](/docs/platform/core/reference/utility-functions/locales/determine-locale) 则根据用户偏好选出最匹配的受支持区域设置——在本例中，它会为使用加拿大法语的用户提供你的 `fr` 翻译。

## 常见问题

### 语言代码和区域设置代码有什么区别？

语言代码只包含一个子标签，例如 `en` 或 `pt`。区域设置代码则可以额外包含文字体系和地区，例如 `pt-BR`，因此它还会决定日期、数字和货币的格式化方式。

### 应该用 en-GB 还是 en-UK？

应该用 `en-GB`。`GB` 是英国的 ISO 3166-1 代码；而 `UK` 并不是已注册的地区子标签，Google 在处理 hreflang 时会忽略它。

### 应该使用 zh-CN 还是 zh-Hans？

如果简体中文内容面向多个地区，请使用 `zh-Hans`；只有当内容专门针对中国大陆时，才使用 `zh-CN`。两者都会解析为简体中文文字体系。

### 区域设置代码区分大小写吗？

不区分。`en-us` 和 `en-US` 是同一个标签，但建议统一写成 `en-US`，以确保文件名、URL 和键保持一致。

## 要点总结

* BCP 47 区域设置代码由一个语言子标签，加上可选的文字体系、地区、变体和扩展子标签组成，各部分按此顺序排列，以连字符分隔：`zh-Hant-TW`、`es-419`、`en-US-u-hc-h23`。
* 请到 IANA 注册表中查询代码：应使用 `en-GB` 而非 `en-UK`，`ja` 而非 `jp`，`he` 而非 `iw`。
* 标签应尽量简短，仅当内容因地区而异时才添加地区子标签；中文应优先确定文字体系。
* 在系统边界处进行格式转换：POSIX、ICU 和 Java 的 `toString()` 使用下划线，Android 则使用 `values-b+es+419` 的形式。
* General Translation 从 `gt.config.json` 的 `defaultLocale` 和 `locales` 中读取 BCP 47 代码；若源区域设置的范围比目标区域设置更宽泛，则会予以拒绝；此外还可通过 `customMapping` 支持别名。

## Related questions

- [如何检测用户的浏览器语言？](https://generaltranslation.com/zh/kb/detect-user-language.mdx): 读取浏览器提供的有序语言列表（在 JavaScript 中为 navigator.languages，在服务器端为 Accept-Language 标头），按 q 值排序，再与你支持的语言区域进行匹配，并设置后备语言区域。Safari 和 Chrome 无痕模式只会报告一种语言，而 IP 地理定位只能反映用户所在位置，无法反映其使用的语言。
- [什么是 hreflang？如何设置？](https://generaltranslation.com/zh/kb/what-is-hreflang.mdx): Hreflang 用于告诉 Google 哪些 URL 是同一页面的不同语言或区域版本，以便在搜索结果中展示正确的版本。你可以通过 HTML link 标签、HTTP Link 响应头或站点地图来添加它，确保所有链接相互指向，并使用有效的代码，例如 en-GB，而不是 en-UK。
- [国际化与本地化（i18n 与 l10n）](https://generaltranslation.com/zh/kb/internationalization-vs-localization.mdx): 国际化（i18n）是让一款产品支持多种区域设置的代码与设计工作，例如使用 Intl 格式化日期、支持从右到左的文本等。本地化（l10n）则针对某一区域设置对产品进行适配，除翻译外，还涵盖货币、日期格式、计量单位、语气和法律细节等方面。
- [如何按区域设置格式化数字、日期和货币？](https://generaltranslation.com/zh/kb/format-numbers-dates-currencies.mdx): 在页面渲染时，使用读者的区域设置和 JavaScript 的 Intl API 格式化每个值，并将值放在待翻译的句子之外。General Translation 的 `<Num>`、`<Currency>`、`<DateTime>` 和 `<RelativeTime>` 组件可在 `<T>` 内同时做到这两点，因此一份翻译即可适用于任意值。
- [多语言 SEO：子目录、子域名与 ccTLD 对比](https://generaltranslation.com/zh/kb/multilingual-url-structure.mdx): 如果同一产品共用一个站点和发布流程，请使用 example.com/de/ 这样的子目录。只有 ccTLD 能指明目标国家，子域名便于独立托管；Google 不建议使用 ?lang= 参数，并会将 .io、.ai 等个性化域名视为通用域名。

## Previous and next questions

- Previous question: [Weglot 替代方案：General Translation 与 Weglot 对比](https://generaltranslation.com/zh/kb/general-translation-vs-weglot.mdx)
- Next question: [什么是翻译记忆库？有了 AI 还需要它吗？](https://generaltranslation.com/zh/kb/what-is-translation-memory.mdx)

## Sitemap

See the [Knowledge Base sitemap](https://generaltranslation.com/zh/kb/sitemap.md) for every article.