c# - ¿Por qué no es string.Normalize consistente según el contexto?

.net unicode

Question

Tengo el siguiente código:

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

Construyo este código con Visual Studio 2010, .net4, en una ventana de 64 bits 7.

Lo ejecuto en un proyecto de pruebas unitarias (plataforma: cualquier CPU) en dos contextos y verifico el contenido de los chars :

• Pruebas unitarias de Visual Studio: los caracteres contienen { 231 } .
• ReSharper : chars contiene { 231 } .
• NCrunch : los caracteres contienen { 99, 807 } .

En la documentación de msdn , no pude encontrar ninguna información que presentara diferentes comportamientos.

Entonces, ¿por qué tengo diferentes comportamientos? Para mí, el comportamiento NCrunch es el esperado, pero yo esperaría lo mismo para otros.

Edición: Cambié de nuevo a .Net 3.5 y todavía tengo el mismo problema.

Answer 1

En la documentación de String.Normalize (NormalizationForm) dice que

La representación binaria está en la forma de normalización especificada por el parámetro normalizationForm.

lo que significa que estaría usando la normalización de FormD en ambos casos, por lo que CurrentCulture y eso no deberían importar.

Lo único que podría cambiar, entonces, en lo que puedo pensar es en el carácter "ç". Ese carácter se interpreta según la codificación de caracteres que se supone o está configurada para los archivos de código fuente de Visual Studio. En resumen, creo que NCrunch está asumiendo una codificación de archivo fuente diferente a las otras.

Sobre la base de la búsqueda rápida en el foro de NCrunch, hubo una mención de algunas conversiones UTF-8 -> UTF-16, así que lo comprobaría.