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

Question

En nuestro equipo tenemos un proyecto de base de datos en Visual Studio 2008 que está bajo control de fuente por Team Foundation Server. Cada dos semanas más o menos, después de que un compañero de trabajo se registra, el archivo del proyecto no se cargará en las otras máquinas de desarrollo. 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 tiene el siguiente aspecto:

��<NUL?NULxNULmNULlNUL NULvNULeNULrNULsNULiNULoNULnNUL ...

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

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

Así que probablemente algo está mal en el enc oding del archivo. Este es un problema para nosotros porque resulta imposible volver a corregir la codificación del archivo. La 'solución' es tirar el archivo del proyecto y obtener la última versión de trabajo conocida del control de fuente.

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

Mis preguntas son:

• ¿Por qué Visual Studio echar a perder la codificación del archivo proyecto, aparentemente de forma aleatoria y al azar máquinas?
• ¿Qué deberíamos hacer para prevenir esto?
• Cuando ha sucedido, ¿existe la posibilidad para restaurar el archivo actual en la codificación correcta en vez de tirar una versión más antigua de control de código fuente?

Como última nota: el problema es con un único archivo de proyecto, el resto de los 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 reemplazo los primeros nueve bytes EF BB BF EF BF BD EF BF BD por los dos bytes FF FE, el archivo de proyecto se cargará nuevamente.

Esto deja la pregunta por qué Visual Studio corrompe el archivo.

Answer 1

Creo que puedo dar una idea de lo que está sucediendo, sino es por qué.

FF FE es un BOM; su presencia al principio del archivo indica que la codificación del archivo es UTF-16, little-endian. Y parece que el archivo original es realmente UTF-16, pero algo está ignorando la lista de materiales y leyéndola como si fuera UTF-8.

Cuando eso sucede, cada uno de los bytes FF y FE se considera no válido y se convierte a U+FFFD, el carácter de basura Unicode oficial.Luego, cuando el texto se escribe nuevamente en un archivo, cada uno de los caracteres basura se convierte a su codificación UTF-8 (EF BF BD) y se agrega UTF-8 BOM (EF BB BF), lo que resulta en nueve -byte secuencia 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 que esos son los únicos bytes en el archivo que no serían válidos cuando se los interpreta como UTF-8. Siempre que el archivo contenga solo caracteres ASCII, está bien, pero cualquier otra cosa, como los caracteres acentuados (é) o las comillas (’), quedarán irreparablemente destrozados.

¿Se supone que los archivos del proyecto son realmente UTF-16? Si no, tal vez el sistema de ese desarrollador genere UTF-16 cuando el sistema de control de versiones esté esperando UTF-8. Noté en mi instalación de Visual C# Express que hay una opción bajo 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 que la codificación cambie en momentos aparentemente aleatorios.