fichier de projet Visual Studio 2008 ne se charge pas en raison d'un changement de codage inattendu

Question

Dans notre équipe, nous avons un projet de base de données dans Visual Studio 2008 qui est sous contrôle de code source par Team Foundation Server. Toutes les deux semaines environ, après un contrôle collègue dans le dossier du projet ne se charge pas sur les autres machines développeurs. Le message d'erreur est:

  

Le fichier de projet n'a pas pu être chargé. Les données au niveau de la racine est invalide. Ligne 1, position 1.

Quand je regarde le fichier de projet dans Notepad ++, le fichier ressemble à ceci:

��<NUL?NULxNULmNULlNUL NULvNULeNULrNULsNULiNULoNULnNUL ...

et ainsi de suite (vous pouvez voir dans ce <?xml version) alors qu'un fichier de projet normale ressemble à:

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

Donc probablement quelque chose ne va pas avec l'encodage du fichier. Ceci est un problème pour nous, car il se révèle impossible d'obtenir le fichier encodage correct à nouveau. La « solution » est de jeter le fichier de projet une obtenir la dernière version de travail savoir du contrôle de source.

Selon le fichier, le codage doit être UTF-16. Selon Notepad ++, le fichier corrompu est en fait UTF-8.

Mes questions sont les suivantes:

• Pourquoi Visual Studio chambouler l'encodage du fichier de projet, apparemment à des moments aléatoires et à machines aléatoires?
• Que devons-nous faire pour empêcher cela?
• Quand il est arrivé, est-il possibilité de restaurer le courant fichier dans le codage correct à la place de tirer une ancienne version de contrôle de code source?

En dernière note:. Le problème est avec un seul fichier de projet, tous les autres fichiers de projet ne pas exposer ce problème

MISE À JOUR: Merci à la suggestion de Jon Skeet J'ai la réponse à la question numéro trois. Quand je remplace les neuf premiers octets EF BB BF EF BF BD EF BF BD par les deux octets FF FE, le fichier de projet se charge à nouveau.

Cela laisse encore la question de savoir pourquoi Visual Studio corrompt le fichier.

Answer 1

Je pense que je peux donner un aperçu quoi qui se passe, sinon pourquoi.

FF FE est un BOM ; sa présence au début du fichier indique que l'encodage du fichier est UTF-16, little-endian. Et il semble que le fichier d'origine est vraiment UTF-16, mais quelque chose ne tient pas compte de la nomenclature et la lecture comme si elle était UTF-8.

Lorsque cela se produit, chacun des octets FF et FE est considérée comme non valide et converti en U+FFFD, le caractère des ordures Unicode officiel. Ensuite, lorsque le texte est écrit dans un fichier à nouveau, chacun des personnages de déchets est converti en son encodage UTF-8 (EF BF BD) et UTF-8 BOM (EF BB BF) est ajouté devant eux , ce qui entraîne dans la séquence de neuf octets que vous avez déclaré:

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

Si tel est le cas, le simple remplacement de ces neuf octets avec FF FE est pas sûr. Il n'y a aucune garantie que ce sont les seuls octets dans le fichier qui serait invalide lorsqu'elle est interprétée en UTF-8. Tant que le fichier ne contient que des caractères ASCII que vous êtes d'accord, mais tout le reste, comme les caractères accentués (ou) de é citations bouclés (’), sera irrémédiablement mutilée.

sont les fichiers de projet vraiment censé être UTF-16? Sinon, peut-être que le système d'un développeur génère UTF-16 lorsque le système de contrôle de version attend UTF-8. Je remarque dans mon Visual C # Express installer il y a une option sous Environment->Documents appelé « Enregistrer les documents en Unicode lorsque les données ne peuvent pas être enregistrées dans codepage ». Cela ressemble à quelque chose qui pourrait provoquer l'encodage pour changer parfois apparemment au hasard.