archivo de proyecto de Visual Studio 2008 no se carga debido a un cambio inesperado de codificación

Question

En nuestro equipo tenemos un proyecto de base de datos en Visual Studio 2008, que está bajo control de código fuente de Team Foundation Server. Cada dos semanas más o menos, después de uno cheques compañero de trabajo en el archivo de proyecto no se cargará en las otras máquinas desarrolladores. El mensaje de error es:

  

El archivo de proyecto no se pudo cargar. Los datos a nivel de la raíz no es válida. Línea 1, posición 1.

Cuando miro el archivo de proyecto de Notepad ++, el archivo es similar al siguiente:

��<NUL?NULxNULmNULlNUL NULvNULeNULrNULsNULiNULoNULnNUL ...

y así sucesivamente (se puede ver en este <?xml version) mientras que un archivo de proyecto normales miradas como:

<?xml version="1.0" encoding="utf-16"?> ...

Así que probablemente algo está mal en la codificación del archivo. Esto es un problema para nosotros, ya que resulta ser imposible de obtener el archivo de la codificación correcta. La 'solución' es tirar el archivo de proyecto de un obtener la última versión de trabajo conocimientos de control de código fuente.

Según el expediente, la codificación debe ser UTF-16. De acuerdo con Notepad ++, el archivo dañado es en realidad UTF-8.

Mis preguntas son:

• ¿Por qué es Visual echar a perder la codificación del Estudio archivo de proyecto, al parecer, a veces al azar y por lo máquinas de azar?
• ¿Qué debemos hacer para evitar esto?
• Cuando ha sucedido, ¿hay una posibilidad de restaurar la corriente archivo en la codificación correcta en vez tirando de una versión más antigua de control de código fuente?

Como última nota:. El problema es con un archivo único proyecto, todos los otros archivos de proyecto no exponen este problema

ACTUALIZACIÓN: Gracias a la sugerencia de Jon Skeet tengo la respuesta a la pregunta número tres. Cuando se sustituye la primera de nueve bytes EF BB BF BF BD EF EF BF BD por los dos bytes FF FE, el archivo de proyecto se carga de nuevo.

Esto deja todavía la pregunta de por qué Visual Studio daña el archivo.

Answer 1

Creo que puedo proporcionar alguna información sobre lo que es pasando, si no por qué.

FF FE es un BOM ; su presencia en el principio del archivo indica que la codificación del archivo es UTF-16, ascendente hacia la izquierda. Y parece que el archivo original realmente es UTF-16, pero algo está ignorando la lista de materiales y la lectura como si se tratara de UTF-8.

Cuando eso sucede, cada uno de los bytes FF y FE se trata como no válida y se convierte en U+FFFD, el carácter oficial de la basura Unicode. Entonces, cuando el texto se escribe en un archivo de nuevo, cada uno de los caracteres de basura se convierte a su codificación UTF-8 (EF BF BD) y el UTF-8 lista de materiales (EF BB BF) se añade delante de ellos , lo que resulta en la secuencia de nueve bytes que informó:

EF BB BF  # UTF-8 BOM
EF BF BD  # U+FFFD in UTF-8
EF BF BD  # ditto

Si este es el caso, la simple sustitución de esos nueve bytes con FF FE no es seguro. No hay garantía de esos son los únicos bytes del archivo que sería válido cuando se interpreta como UTF-8. Mientras que el archivo contiene sólo caracteres ASCII que estás bien, pero todo lo demás, como caracteres acentuados (é) o comillas tipográficas (’), será irremediablemente destrozado.

¿Los archivos de proyecto supone realmente ser UTF-16? Si no, tal vez que el sistema de un desarrollador está generando UTF-16 cuando el sistema de control de versiones está a la espera UTF-8. Me he dado cuenta en mi Visual C # Express instalación hay una opción en Environment->Documents llamada "Guardar documentos como Unicode cuando los datos no se pueden guardar en la página de códigos". Eso suena como algo que podría causar la codificación al cambio en momentos aparentemente aleatorios.