LCID-rs：一个用于 Windows 语言代码标识符和其他语言/文化信息的 Rust 库

[仓库] [文档] [包注册（crates.io）]

此包根据 [MS-LCID] Windows 语言代码标识符（LCID）参考 和 System.Globalization.CultureInfo API 提供语言代码标识符解析和信息。

以下信息被提供

• 语言代码标识符/LCID（《lcid》），以及按 LCID 查找
• 名称/IETF 语言标签（《name》），以及按名称查找
• 非本地化、可读的英语语言名称（《english_name》）
• ISO 639-1 双字母代码（《iso639_two_letter》）- 注意这不一定总是两个字母
• ISO 639-2/639-3 三字母代码（《iso639_three_letter》）
• Windows API 三字母语言代码（《windows_three_letter》）
• ANSI 字符集（《ansi_code_page》），如果可用

要使用此包，请将以下内容添加到您的 Cargo.toml

[dependencies]
lcid = "0.3"

可以使用语言代码标识符（LCID，一个32位无符号整数）、名称（一个字符串，即支持的 IETF BCP 47 语言标签）或直接引用语言标识符常量来查询语言标识符/信息

use lcid::LanguageId;
use std::convert::TryInto;

fn main() {
    let lang: &LanguageId = 1033.try_into().unwrap();
    println!("Lang is '{}'/{}/'{}'", lang.name, lang.lcid, lang.english_name);

    let lang: &LanguageId = "en-US".try_into().unwrap();
    println!("Lang is '{}'/{}/'{}'", lang.name, lang.lcid, lang.english_name);

    let lang: &LanguageId = lcid::constants::LANG_EN_US;
    println!("Lang is '{}'/{}/'{}'", lang.name, lang.lcid, lang.english_name);
}

这将为每个打印以下内容

Lang is 'en-US'/1033/'English (United States)'

项目名称和状态

我为这个项目的名称感到苦恼。"locale-info" 可能会误导（可能意味着某种 POSIX 本地化支持），或者 "culture-info" 暗示的项目范围比项目提供的更多（如日历信息）。最后，我选择了 "lcid-rs"，因为 "lcid" 是模糊的/难以搜索的，尽管我将包本身命名为 "lcid"，因为在 Rust 的上下文中，"lcid" 并不模糊。如果在这个项目模糊的上下文中（链接到仓库、博客文章等）使用 "lcid-rs"，而在 Rust 代码/配置中仅使用 "lcid"，那就很棒了。

维护状态为“现状”。我乐于接受修正的pull请求（只要它们与MS-LCID和Windows API一致），以及关于新功能的pull请求，以及未来关于新MS-LCID协议修订的pull请求。

MS-LCID协议修订

此库目前跟踪的协议修订为15.0/2021-06-25。未来的协议修订可能只会触发小版本号的升级，因此如果您需要特定修订的查找行为，请相应地锁定此crate。

变更日志

[0.3.0] - 2023-06-15

• 跟踪MS-LCID 15.0/2021-05-25协议修订
• 重大变更：由于规范不再枚举“无LCID的本地化名称”，因此不再支持这些名称
• 代码生成：排序顺序现在与MS-LCID规范中指定的一致

[0.2.1] - 2023-06-10

• 移除thiserror依赖
• MSRV是Rust 1.56
• 版本是2021
• 向AnsiCodePage和LanguageId添加PartialEq、Eq和Hash特质

[0.2.0] - 2021-06-08

• 跟踪MS-LCID 14.1/2021-04-07协议修订
• 提供ANSI代码页信息
• 将LanguageId常量移动到一个模块中，以避免污染crate命名空间（重大变更）
• 代码生成：按LCID和名称排序语言，以便生成的代码对共享LCID的语言（如0x1000）是稳定的

[0.1.0] - 2021-06-06

• 初始发布

信息是如何生成的

首先，从与跟踪的协议修订对应的MS-LCID PDF以及从相关LCID的HTML表中提取信息，然后手动清理、转换为JSON并进行比较。

在Windows Server 2022机器（构建20348，区域设置为“en-us”）和Windows 10（构建19045，区域设置为“en-us”）上运行了GetCultureInfo.ps1脚本，以根据MS-LCID中的语言ID从System.Globalization.CultureInfo API收集更多信息。API返回的值并不总是与MS-LCID中的信息一致，因此进行了一些修复。有关详细信息，请参阅lcid_gen。由于Windows Server 2022和Windows 10的输出之间存在差异，因此进行了额外的修复，以便信息匹配。其中许多都列在勘误表中。

最后，调用lcid_gen crate生成lcid crate的代码。生成的代码已提交到存储库。这样做是为了避免在构建时依赖于JSON文件。

MS-LCID/CultureInfo勘误

协议修订15.0/2021-06-25

• 差分文件的下载链接 错误，指向了 [MS-LCID]-210625-diff.pdf；正确的链接指向 [MS-LCID]-diff.pdf。

• "quz-PE" 的语言 ID 被错误地打印为 0x0C6b。它应该是 0x0C6B，因为所有其他语言 ID 都是上档十六进制数。这不会影响 lcid-rs。

• 在某些版本（仅限 Windows 10？）中，"zh-Hans"/0x0004 的文化信息名称返回为 "zh-CHS"，而 "zh-Hant"/0x7C04 的名称返回为 "zh-CHT"。这些是旧名称。这是 一个已知问题，微软已经 承认。

  有两个文化名称与这一规则相矛盾。名为 zh-Hans 的中文（简体）和名为 zh-Hant 的中文（繁体）是中立文化。文化名称代表当前标准，除非你有理由使用旧名称 zh-CHS 和 zh-CHT，否则应使用这些名称。

  lcid-rs 使用名称 "zh-Hans"/"zh-Hant"，以及英文名称 "Chinese (Simplified)"/"Chinese (Traditional)"（不使用后缀 "Legacy"）。然而，lcid-rs 使用 Windows API 三字母语言代码 "CHT" 而不是有时使用的 "ZHH" 用于 "zh-Hant"。

• "qut"/0x0086 的文化信息相当混乱。在 Windows Server 2022 上，LCID、ISO 639 和英文名称错误或不完整。在 Windows 10 上，返回的文化信息似乎是 "quc"/0x0093，这是预留的。这也意味着文化信息名称与 MS-LCID 名称不匹配。lcid-rs v0.2 以前曾更改这一点，但 lcid-rs v0.3 使用了在构建 Windows 10 时返回的文化信息，尽管这似乎违反了 MS-LCID。

• MS-LCID 规范指定了 "ff-NG, ff-Latn-NG" 用于 0x0467。返回的文化信息名称为 "ff-Latn-NG"。lcid-rs 使用 "ff-Latn-NG"。

• "la-VA"/0x0476 的文化信息一团糟。当通过 LCID 查询时，名称为 "la-001"，而英文名称为 "Latin (World)"（而不是 "Latin (Vatican City)"）。当通过名称查询时，LCID 不正确（0x1000），有时英文名称也不正确。lcid-rs 使用 "la-VA" 和 "Latin (Vatican City)"，因为这是通过名称查询时返回的。这也与 MS-LCID 匹配，MS-LCID 没有指定 "la-001"。

• "es-ES_tradnl"/0x040A 的文化信息名称为 "es-ES"。然而，LCID、英文名称和 Windows API 三字母语言代码将与 "es-ES"/0x0C0A 不同。lcid-rs 不会更改这一点。

• "no"/0x0014 的 ISO 639 双字母和三字母语言代码令人困惑。在 Windows Server 2022 上，它们是 "no"/"nor"。在 Windows 10 上，它们似乎为 "nb"/"nob" 用于 "Bokmål"。如果你是挪威人，请发表意见。lcid-rs 使用 "nb"/"nob"。

• 一些英文名称的进一步微调记录在 lcid_gen/src/fixup.rs 中。一般来说，优先考虑了 Windows 10 返回的值。

协议修订版本 14.1/2021-04-07

• "es-CU" 被列出两次。一次作为 "Language ID" 表中的 0x5C0A，另一次在 "Locale Names without LCIDs" 表中作为 0x1000。使用了前者 LCID。
• "ff-Latn-GM" 错误地被打印为 "ff-latn-GM"（小写 "l"）。这已被纠正。
• 许多更多文化信息错误/微调。

许可协议

根据以下任一协议许可

• Apache License，版本 2.0（《LICENSE-APACHE》或http://www.apache.org/licenses/LICENSE-2.0）
• MIT 许可协议（《LICENSE-MIT》或http://opensource.org/licenses/MIT）

由您选择。

贡献

除非您明确声明，否则根据 Apache-2.0 许可证定义的任何有意提交以包含在您的工作中的贡献，将按上述方式双重许可，不附加任何额外条款或条件。