为什么 string.Normalize 不根据上下文保持一致？答案

【问题标题】：Why isn't string.Normalize consistent depending on the context?为什么 string.Normalize 不根据上下文保持一致？
【发布时间】：2012-05-18 18:25:51
【问题描述】：

我有以下代码：

string input = "ç";
string normalized = input.Normalize(NormalizationForm.FormD);
char[] chars = normalized.ToCharArray();

我在 64 位 Windows 7 上使用 Visual Studio 2010 .net4 构建此代码。

我在两个上下文中的单元测试项目（平台：任何 CPU）中运行它并检查 chars 的内容：

在msdn documentation 中，我找不到任何表现不同行为的信息。

那么，为什么我会得到不同的行为？对我来说，NCrunch 行为是预期的，但我希望其他人也是如此。

编辑： 我切换回 .Net 3.5 仍然遇到同样的问题。

【问题讨论】：

嗯，我用 Visual Studio 得到 { 99, 807 }...这意味着您的项目配置存在一些问题...也许吧。
@zmilojko。感谢您的测试。在一个空白的新项目中，我得到了与您相同的结果。所以我正在检查两个项目之间的差异（csproj 上的 winmerge），但还没有找到相关的，这就是我发布这个问题的原因：了解哪个上下文可能导致不同的行为。
Thread.CurrentThread.CurrentCulture 在每种情况下是什么？
如何'查看chars'的内容？
@MattHickford，我将鼠标轻轻移动到调试器中的 chars 变量上，然后展开 + 符号。

【解决方案1】：

在String.Normalize(NormalizationForm) documentation 中是这样说的

二进制表示采用由 normalizationForm 参数。

这意味着您将在两种情况下都使用 FormD 规范化，因此 CurrentCulture 等应该不重要。

那么，我能想到的唯一可以改变的是“ç”字符。该字符将根据为 Visual Studio 源代码文件假定或配置的字符编码进行解释。简而言之，我认为 NCrunch 假设的源文件编码与其他的不同。

根据在 NCrunch 论坛上的快速搜索，提到了一些 UTF-8 -> UTF-16 转换，所以我会检查一下。

【讨论】：

确实，我强烈怀疑源代码/运行时代码中 te ç 字符的编码。我开始玩源文件的编码，但没有运气。然后，我尝试从外部文件中读取字符串，直到我将其编码强制为UTF-8 才失败。最后，我将input 的声明更新为string input = new string(new[] { (char)231 });，并且......它起作用了！