Linux 上 .NET Core 的字符编码错误

Question

这几天让我发疯了，我终于把它归结为一个简单、可重现的问题。

我有一个 NUnit 测试项目，即 .NET Core 2.1。它引用了一个 .NET Standard 2.0 库（我们称之为“Core”）。

在我的测试项目中：

[TestCase(true, false)]
[TestCase(false, false)]
[TestCase(false, true)]
public void ShouldStartWith(bool useInternal, bool passStartsWith)
{
    var result = useInternal ? StartsWithQ("¿Que?") : StringUtilities.StartsWithQ("¿Que?", passStartsWith ? "¿" : null);
    result.ShouldBeTrue();
}

public static bool StartsWithQ(string s)
{
    return _q.Any(q => s.StartsWith(q, StringComparison.InvariantCultureIgnoreCase));
}

在Core 项目中的StringUtilities 类中：

public static bool StartsWithQ(string s, string startsWith = null)
{
    return startsWith == null
        ? _q.Any(q => s.StartsWith(q, StringComparison.InvariantCultureIgnoreCase))
        : s.StartsWith(startsWith, StringComparison.InvariantCultureIgnoreCase);
}

两个类都定义了特殊字符列表：

private static readonly List<string> _q = new List<string>
{
    "¡",
    "¿"
};

在 Windows 环境中，所有测试用例都通过。但是当同样的测试在Linux环境下运行时，测试用例ShouldStartWith(False,False)就失败了！

这意味着当测试项目中的所有内容都在运行时，字符串比较工作正常，即使您将特殊字符传递给StringUtilities 方法，比较工作也会正常进行。但是当你比较一个在 Core 项目中编译的字符串时，特殊字符不再是等价的！​​p>

有人知道这是为什么吗？这是一个 .NET 错误吗？如何解决？

Answer 1

源文件的编码很可能彼此不匹配和/或与编译器设置不匹配。

例子：

包含public void ShouldStartWith(bool useInternal, bool passStartsWith) 的源文件可以使用utf-8 编码，而带有列表的源文件使用Latin-1（或类似的东西）编码。

当我们玩这个时：

• ¿ 的 utf-8 表示形式为：0xC2 0xBF。
• ¿ 的 Latin-1 表示形式为：0xBF。

因此，当编译器将您的源文件解释为 Latin-1 时，他将在 utf-8 保存文件的情况下读取 2 个字节（并且根据 Latin-1 也是 2 个字符），因此无法匹配字符串。

正如 cmets 中所述：克服此问题的最佳方法是将源文件编码为编译器等待的编码。

将操作系统排除为错误源的另一种方法：将已编译的项目（dll 的 - 不要在其他操作系统上重新编译源）从一个操作系统复制到另一个并执行代码。您应该会在具有相同二进制编译器输出的两个操作系统上看到相同的行为。