为什么string.Normalize不一致取决于上下文?

rem*_*mio 16 .net c# unicode normalization unicode-normalization

我有以下代码:

string input = "ç";
string normalized = input.Normalize(NormalizationForm.FormD);
char[] chars = normalized.ToCharArray();
Run Code Online (Sandbox Code Playgroud)

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

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

  • Visual Studio单元测试:字符包含{ 231 }.
  • ReSharper:字符包含{ 231 }.
  • NCrunch:字符包含{ 99, 807 }.

msdn文档中,我找不到任何表示不同行为的信息.

那么,为什么我会得到不同的行为?对我来说,NCrunch行为是预期的行为,但我希望其他行为也是如此.

编辑: 我切换回.Net 3.5仍然有同样的问题.

eis*_*eis 7

String.Normalize(NormalizationForm)文档中,它说明了这一点

二进制表示形式是normalizationForm参数指定的规范化形式.

这意味着你将在两种情况下使用FormD规范化,因此CurrentCulture等并不重要.

唯一可以改变的是,我能想到的是"ç"字符.该字符被解释为为Visual Studio源代码文件假定或配置的字符编码.简而言之,我认为NCrunch正在假设不同的源文件编码.

基于快速搜索NCrunch论坛,提到了一些UTF-8 - > UTF-16转换,所以我会检查一下.