.NET 5中X509Certificate.GetNameInfo返回大写Unicode转义字符问题

是否属于.NET的Bug？ #

这属于.NET跨平台实现的一致性缺陷，并非严格的功能逻辑Bug。Windows环境下X509Certificate2的API依赖系统原生CryptoAPI实现，会直接返回未转义的原始Unicode字符串；而Linux环境下该API依赖OpenSSL做证书解析，.NET底层封装OpenSSL返回的ASN.1字符串时，转义逻辑存在平台差异，该问题已在.NET的官方issue库中有相关反馈记录。

为什么转义字符的u会变成大写？ #

Linux下.NET的X509处理模块的字符串转义逻辑未区分Unicode码点范围：标准转义规则中，码点小于0x10000的基本多语言平面字符应该使用小写\u加4位十六进制表示，码点大于等于0x10000的字符才需要使用大写\U加8位十六进制表示。但Linux下的实现硬编码统一使用了大写\U前缀，才导致了该问题。

临时解决方案是否合理？ #

你当前使用的方案在证书名称仅包含基本多语言平面字符（比如俄文、常用中文、英文等）的场景下是可用的，ToLowerInvariant()使用不变区域性转小写，不会影响十六进制字符的正确性，Regex.Unescape可以正确识别小写\u开头的转义序列还原为原始字符。

是否存在导致字符丢失的场景？ #

存在两类风险场景：

• 证书名称本身包含字面量\U字符串（非转义序列）时，直接全量转小写会将其转换为\u，导致Regex.Unescape误将普通内容识别为转义序列，出现内容错误。
• 证书名称包含超出基本多语言平面的字符（比如Emoji、特殊生僻汉字、古文字符等，码点>=0x10000）时，这类字符本就需要\U加8位十六进制表示，强制转小写为\u后，Regex.Unescape只会读取后4位十六进制，会将单个字符拆解为两个错误字符，导致内容损坏。

更稳妥的修复方案 #

你可以针对性替换BMP范围内的\U转义为\u，保留超出BMP范围的\U转义不处理，避免上述风险：

var rawSubjectName = x509.GetNameInfo(X509NameType.SimpleName, forIssuer: false);
// 仅匹配后面跟4位十六进制的\U转义（即BMP平面字符），替换为小写\u前缀
var processedName = Regex.Replace(rawSubjectName, @"\\U([0-9a-fA-F]{4})(?![0-9a-fA-F])", @"\u$1");
var finalSubjectName = Regex.Unescape(processedName);

内容的提问来源于stack exchange，提问作者Nikita Kalimov