2012-05-10 22 views
16

tengo el siguiente código:¿Por qué no es coherente.Normalizar consistente según el contexto?

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

yo construir este código con Visual Studio 2010, .net4, en un 64 bits de Windows 7.

lo ejecuto en un proyecto de pruebas unitarias (plataforma: Cualquier CPU) en dos contextos y comprobar el contenido de chars:

  • pruebas unitarias de Visual Studio: caracteres contiene { 231 }.
  • ReSharper: caracteres contiene { 231 }.
  • NCrunch: caracteres contiene { 99, 807 }.

En el msdn documentation, no pude encontrar ninguna información que presentara comportamientos diferentes.

Entonces, ¿por qué obtengo comportamientos diferentes? Para mí, el comportamiento de NCrunch es el esperado, pero espero lo mismo para los demás.

Editar: que volver a ajustarse Net 3.5 y todavía tienen el mismo problema.

+0

Hmm, obtengo {99, 807} con Visual Studio ... Esto implicaría que hay algo sobre la configuración de su proyecto ... Tal vez. – zmilojko

+0

@zmilojko. Gracias por tu prueba Obtengo los mismos resultados que los tuyos en un nuevo proyecto en blanco. Por lo tanto, estoy verificando las diferencias entre los dos proyectos (winmerge en csproj), pero aún no pude encontrar relevante, razón por la cual publiqué esta pregunta: entiendo qué contexto podría inducir a un comportamiento diferente. – remio

+5

¿Qué es 'Thread.CurrentThread.CurrentCulture' en cada caso? – AakashM

Respuesta

7

En String.Normalize(NormalizationForm) documentation dice que

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

lo que significa que usaría la normalización de FormD en ambos casos, por lo que CurrentCulture y tal no deberían realmente importar.

Lo único que podría cambiar, entonces, 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 configura 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 demás.

Según la búsqueda rápida en el foro de NCrunch, se mencionaba alguna conversión UTF-8 -> UTF-16, así que lo verificaría.

+1

De hecho, sospechaba fuertemente de la codificación del carácter te 'ç' en el código fuente/tiempo de ejecución. Empecé a jugar con la codificación del archivo fuente sin suerte. Luego, traté de leer la cadena desde un archivo externo, que falló hasta que forcé su codificación a 'UTF-8'. Finalmente, actualicé mi declaración de 'input' a' string input = new string (new [] {(char) 231}); ', y ... ¡funciona! – remio

Cuestiones relacionadas