Visual Studio 2008-Projektdatei nicht geladen wegen eines unerwarteten Codierung ändern

Question

In unserem Team haben wir ein Datenbank-Projekt in Visual Studio 2008, die von Team Foundation Server unter Quellcodeverwaltung ist. Alle zwei Wochen oder so, nach einem Mitarbeiter überprüft in, wird die Projektdatei auf den anderen Entwicklern Maschinen nicht geladen werden. Die Fehlermeldung lautet:

  

Die Projektdatei kann nicht geladen werden. Die Daten auf der Stammebene ist ungültig. Zeile 1, Position 1.

Als ich in der Projektdatei suchen in Notepad ++, die Datei sieht wie folgt aus:

��<NUL?NULxNULmNULlNUL NULvNULeNULrNULsNULiNULoNULnNUL ...

und so weiter (Sie <?xml version in diesen sehen kann) während einer normalen Projektdatei aussieht wie:

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

So wahrscheinlich ist etwas falsch mit der Codierung der Datei. Dies ist ein Problem für uns, denn es stellt sich heraus unmöglich zu sein, um die Datei korrekt wieder codiert, zu erhalten. Die ‚Lösung‘ ist die Projektdatei wegzuwerfen eine die letzte bekannte funktionierende Version aus der Quellcodeverwaltung erhalten.

Nach der Datei sollte die Kodierung UTF-16 sein. Nach Notepad ++ ist die beschädigte Datei tatsächlich UTF-8.

Meine Fragen sind:

• ist Warum Visual Studio die Codierung der vermasselt Projektdatei, offenbar zu zufälligen Zeiten und bei Zufall Maschinen?
• Was sollten wir tun, um dies zu verhindern?
• Wenn es passiert ist, ist es ein Möglichkeit, den Strom wiederherzustellen Datei in der richtigen Codierung statt des Ziehens eine ältere Version von Quellcodeverwaltung?

Als letzte Anmerkung:. Das Problem ist, mit einer einzigen Projektdatei, alle anderen Projektdateien aussetzen dieses Problem nicht

UPDATE: Dank Jon Skeet Vorschlag habe ich die Antwort auf Frage Nummer drei. Als ich die ersten neun Bytes EF BB BF EF BF BD EF BF BD durch die zwei Bytes FF FE ersetzen, wird die Projektdatei erneut geladen werden.

Diese Blätter noch die Frage, warum Visual Studio die Datei korrumpiert.

Answer 1

ich glaube, ich einen kleinen Einblick in zur Verfügung stellen kann was ist geschieht, wenn nicht, warum.

FF FE ist ein BOM ; ihre Anwesenheit am Anfang der Datei gibt an, dass die Kodierung der Datei ist UTF-16, Little-Endian. Und es klingt wie die ursprüngliche Datei wirklich ist UTF-16, aber etwas ignoriert die BOM und lesen, als ob es UTF-8 waren.

Wenn das passiert, jedes der Bytes FF und FE als ungültig behandelt und umgewandelt U+FFFD, die offizielle Unicode Müll Zeichen. Dann, wenn der Text in eine Datei wieder geschrieben wird, jede der Garbage Collection-Zeichen wird in seine UTF-8-Codierung (EF BF BD) umgewandelt und die UTF-8 BOM (EF BB BF) wird vor ihnen hinzugefügt führt, die Sie in den ersten neun Byte-Sequenz berichtet:

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

Wenn dies der Fall ist, einfach jene neun Bytes mit FF FE ersetzt, ist nicht sicher. Es gibt keine Garantie, sind diejenigen, die nur in der Datei-Bytes, die ungültig, wenn sie als UTF-8 interpretiert würde. Solange die Datei nur ASCII-Zeichen du bist in Ordnung enthält, aber alles andere, wie akzentuierte Zeichen (é) oder typografische Anführungszeichen (’), unwiederbringlich verstümmelt werden.

Sollen die Projektdateien wirklich sein UTF-16? Wenn nicht, vielleicht, dass ein Entwickler-System UTF-16 wird erzeugt, wenn das Versionskontrollsystem erwartet UTF-8. Ich merke in meinem Visual C # Express installieren gibt es eine Option unter Environment->Documents „Speichern von Dokumenten als Unicode, wenn die Daten nicht in Codepage gespeichert werden“ genannt. Das klingt wie etwas, das die Codierung Änderung in scheinbar zufälligen Zeiten führen könnte.