Java Locale.forLanguageTag 怎样解析 BCP 47 语言标签

Java 里处理 zh-CN、en-US 或带脚本的 zh-Hant-TW 时，常用入口是 Locale.forLanguageTag(String)。它的重点是“把一个语言标签转换成 Locale”，而不是替你严格拒绝所有脏输入：遇到格式不完整的子标签时，方法会忽略该子标签及其后续部分；传入 null 则会抛出 NullPointerException。

官方文档：https://docs.oracle.com/en/java/javase/25/docs/api/java.base/java/util/Locale.html

如果输入来自浏览器请求头、用户配置或数据库，先决定“允许尽量解析”还是“必须严格拒绝”，再选择 forLanguageTag 或 Locale.Builder.setLanguageTag。不要把两者当成同一种校验器。

先建立两种输入处理基线

实际接入时，可以先把输入分成两类。内部常量或已经由协议层保证格式的值，通常希望尽快得到一个 Locale；外部表单、租户配置和管理后台输入，则更需要知道它是否完整合法。

这不是性能基准，而是输入契约基线：解析 API 负责产出对象，严格构造器负责把语法错误留在边界处。

用 forLanguageTag 读取语言、脚本和地区

一个 BCP 47 标签可以包含语言、脚本、地区和扩展。解析后不要只打印 toString() 判断结果，最好同时读取结构化字段，并用 toLanguageTag() 查看规范化后的标签。

import java.util.Locale;

public class LocaleTagDemo {
    public static void main(String[] args) {
        // 语言、脚本和地区都由标签中的子标签表达。
        Locale locale = Locale.forLanguageTag("zh-Hant-TW");

        // 结构化读取比直接拼接字符串更适合后续匹配和回退。
        System.out.println(locale.getLanguage()); // zh
        System.out.println(locale.getScript());   // Hant
        System.out.println(locale.getCountry());  // TW

        // 输出规范化后的 BCP 47 标签，便于记录和比较。
        System.out.println(locale.toLanguageTag()); // zh-Hant-TW
    }
}

如果只关心语言，可以读取 getLanguage()；需要区分繁体中文、拉丁脚本或地区时，再读取 getScript() 与 getCountry()。扩展字段则通过 getExtension() 或相关访问方法读取。

格式不完整时，解析会在哪里停下

forLanguageTag 的行为容易被误解成“非法输入一定抛异常”。官方定义是：如果标签含有格式不正确的子标签，会忽略第一个不正确的子标签以及后面的全部子标签。因此它更像是一个宽松转换入口，不能单独证明原始字符串完整合法。

import java.util.Locale;

public class LenientLocaleParse {
    public static void main(String[] args) {
        // bad_part 之后的内容不会继续参与 Locale 构造。
        Locale locale = Locale.forLanguageTag("zh-Hant-bad_part-TW");
        System.out.println(locale.toLanguageTag());

        // null 不是“空语言”，而是调用契约错误，应先在边界处理。
        String raw = null;
        if (raw == null) {
            System.out.println("缺少语言标签");
        }
    }
}

因此，日志里最好同时保存原始值与规范化后的值，避免把被截断的结果误当成用户完整提交的标签。对 null、空字符串和只包含空白的输入，也应在业务层先定义回退语言。

需要严格拒绝时，改用 Locale.Builder

当语言标签来自可编辑配置时，可以使用 Locale.Builder.setLanguageTag。它的语义更接近“验证后构造”：遇到不符合 BCP 47 语法的内容会抛出 IllformedLocaleException，这比静默截断更适合阻止错误配置进入运行时。

import java.util.Locale;
import java.util.Locale.Builder;
import java.util.Locale.IllformedLocaleException;

public class StrictLocaleParse {
    static Locale parseConfig(String raw) {
        try {
            // Builder 会对语言标签执行更严格的格式检查。
            return new Builder().setLanguageTag(raw).build();
        } catch (IllformedLocaleException ex) {
            // 将原始值放进业务错误中，便于定位配置来源。
            throw new IllegalArgumentException("语言标签格式错误: " + raw, ex);
        }
    }
}

严格模式也不意味着业务一定要拒绝所有未知语言。它只负责判断标签形状是否符合语法；语言是否被产品支持、没有匹配时回退到哪种 Locale，仍然要由应用策略决定。

把选择落到服务入口

可以用下面的清单收尾。请求头解析适合“尽量读取并回退”，配置加载适合“启动前失败”，内部常量则应在代码评审时保证来源可信。

• 外部语言偏好：先处理 null、空值和逗号分隔，再对单个标签使用 forLanguageTag。
• 默认语言配置：使用 Builder 严格构造，启动失败时输出配置键和原始值。
• 结果持久化：优先保存 toLanguageTag() 的规范化值，同时保留原始输入用于排错。
• 匹配逻辑：不要只比较 toString()，按语言、脚本、地区和扩展的业务需要选择字段。

记住这条边界即可：Locale.forLanguageTag 解决“从标签得到尽可能有用的 Locale”，Locale.Builder.setLanguageTag 解决“标签不合法时立即告诉调用方”。

相关问题

forLanguageTag 遇到非法标签一定抛异常吗？

不一定。格式不正确的子标签会让该位置及后续部分被忽略；只有 null 等调用契约问题才会直接抛出对应异常。

为什么不直接使用 Locale 构造器？

旧式构造器不表达完整的 BCP 47 标签语义。需要解析语言标签时，应优先使用 forLanguageTag 或 Locale.Builder。

解析成功是否代表产品支持这个语言？

不是。解析成功只说明 Java 得到了一个 Locale 对象，资源包是否存在、地区是否开放以及回退规则仍由应用自己决定。