解析dotnet/runtime中Apple移动平台全球化测试失败问题

在dotnet/runtime项目中，最近发现了一个与Apple移动平台全球化功能相关的测试失败问题。这个问题涉及到CultureInfo构造函数在处理未确定语言标签时的行为异常，特别是在处理带有扩展的语言标签时表现不符合预期。

问题背景

全球化功能是.NET框架中处理多语言和区域设置的核心组件。CultureInfo类负责封装与特定区域相关的信息，包括语言、日期格式、数字格式等。在Apple移动平台(iOS、tvOS和MacCatalyst)上，全球化功能的实现依赖于ICU库(International Components for Unicode)。

问题表现

测试用例CtorUndeterminedLanguageTag在以下两种情况下失败：

1. 当传入"und-es-u-co-phoneb"语言标签时，预期文化名称为"und-ES"，实际得到"und-ES-u-co-phoneb"
2. 当传入"und-es-t-something"语言标签时，预期文化名称为"und-ES"，实际得到"und-ES-t-something"

技术分析

问题的根源在于ICU库的uloc_getName函数会自动去除"und"前缀，而项目中的修复代码虽然恢复了"und"前缀，但没有正确处理语言标签中的扩展部分。

在全球化处理中，语言标签可以包含多种扩展：

• "u"扩展：表示Unicode扩展，如"-u-co-phoneb"表示使用电话簿排序规则
• "t"扩展：表示转换扩展，用于脚本转换等目的

根据设计规范，这些扩展应该：

1. 从文化名称中移除
2. 保留在排序名称中(对于"u"扩展)
3. 完全忽略(对于"t"扩展)

解决方案思路

要解决这个问题，需要在NormalizeCultureName方法中：

1. 首先识别并分离语言标签中的扩展部分
2. 处理基础文化名称(包括恢复"und"前缀)
3. 根据需要将扩展部分应用到排序名称中

对于实现细节，可以考虑：

• 使用正则表达式或字符串操作来识别扩展
• 维护一个扩展类型白名单，只处理已知的扩展
• 确保与ICU库的行为保持一致

影响范围

这个问题主要影响Apple移动平台上的全球化功能，特别是：

• 使用未确定语言标签("und")的应用程序
• 需要处理文化名称扩展的场景
• 依赖文化名称格式一致性的代码

总结

全球化功能的正确处理对于多语言应用程序至关重要。这个问题的解决不仅需要修复当前的行为差异，还需要考虑与现有系统的兼容性和未来扩展性。开发团队在处理这类问题时，需要深入理解ICU库的行为规范，并确保.NET实现与这些规范保持一致。