Le fichier du 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 le contrôle de la source par Team Foundation Server. Toutes les deux semaines environ, après qu'un collaborateur se soit enregistré, le fichier de projet ne sera pas chargé sur les autres machines de développement. Le message d'erreur est:

Le fichier de projet n'a pas pu être chargé. Les données au niveau racine sont incorrectes. Ligne 1, 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 qui ne va pas avec le enc oding du fichier. C'est un problème pour nous car il s'avère impossible d'obtenir à nouveau l'encodage correct. La 'solution' consiste à jeter le fichier projet et à obtenir la dernière version de travail du contrôle 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 Messing l'encodage du fichier de projet , apparemment à des moments aléatoires et à machines aléatoires?
• Que devons-nous faire pour éviter cela?
• Quand il est arrivé, est-il une possibilité pour restaurer le fichier en cours dans le codage correct à la place de tirer une ancienne version de contrôle de code source?

En note: le problème concerne un seul fichier projet, tous les autres fichiers projet n'exposent pas ce problème. MISE À JOUR: Grâce à la suggestion de Jon Skeet, j'ai la réponse à la question numéro trois. Lorsque 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 toujours la question de savoir pourquoi Visual Studio corrompt le fichier.

Answer 1

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

FF FE est un BOM; sa présence au début du fichier indique que le codage du fichier est UTF-16, little-endian. Et il semble que le fichier original soit vraiment UTF-16, mais quelque chose ignore la nomenclature et la lit comme s'il s'agissait d'UTF-8. Lorsque cela se produit, chacun des octets FF et FE est traité comme non valide et converti en U+FFFD, le caractère de chiffrement Unicode officiel.Ensuite, lorsque le texte est à nouveau écrit dans un fichier, chacun des caractères incorrects est converti en son codage UTF-8 (EF BF BD) et le UTF-8 BOM (EF BB BF) est ajouté en face d'eux, entraînant neuf séquence -Byte 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 n'est pas sûr. Il n'y a aucune garantie que ce sont les seuls octets du fichier qui seraient invalides lorsqu'ils sont interprétés comme UTF-8. Tant que le fichier ne contient que des caractères ASCII, tout va bien, mais toute autre chose, comme les caractères accentués (é) ou les guillemets (’), seront irrémédiablement mutilés.

Les fichiers de projet sont-ils vraiment supposés ê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 installation Visual C# Express il existe une option sous Environment->Documents appelée "Enregistrer des documents en tant que Unicode lorsque les données ne peuvent pas être enregistrées dans la page de code". Cela ressemble à quelque chose qui pourrait faire changer l'encodage à des moments apparemment aléatoires.