Visual Studio 2008 file di progetto non viene caricato a causa di un cambiamento di codifica inaspettato

Question

Nel nostro team abbiamo un progetto di database in Visual Studio 2008, che è sotto il controllo del codice sorgente per Team Foundation Server. Ogni due settimane o giù di lì, dopo una verifica collaboratore in, il file di progetto non caricare sulle altre macchine sviluppatori. Il messaggio di errore è:

  

Il file di progetto non può essere caricato. I dati al livello principale non è valido. Linea 1, posizione 1.

Quando guardo il file di progetto in Notepad ++, il file si presenta così:

��<NUL?NULxNULmNULlNUL NULvNULeNULrNULsNULiNULoNULnNUL ...

e così via (si può vedere in questo <?xml version) mentre un normale file di progetto si presenta come:

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

Quindi, probabilmente qualcosa non va con la codifica del file. Questo è un problema per noi perché risulta essere impossibile ottenere di nuovo la codifica del file corretto. La 'soluzione' è quello di buttare via il file di progetto di avere l'ultima versione di lavoro sapere dal controllo di origine.

Secondo il file, la codifica dovrebbe essere UTF-16. Secondo Notepad ++, il file danneggiato è in realtà UTF-8.

Le mie domande sono:

• Perché Visual Studio in disordine la codifica del file di progetto, a quanto pare, a volte casuali e al macchine casuali?
• Che cosa dobbiamo fare per evitare questo?
• Quando è successo, c'è un possibilità di ripristinare la corrente depositare nella codifica corretta invece di tirare da una versione precedente controllo del codice sorgente?

Come ultima nota:. Il problema è con un singolo file di progetto, tutti gli altri file di progetto non esporre questo problema

UPDATE: Grazie per il suggerimento di Jon Skeet ho la risposta alla domanda numero tre. Se si sostituisce primi nove byte EF BB BF EF BF BD EF BF BD dai due byte FF FE, il file di progetto verrà caricato nuovamente.

Questo lascia ancora la questione del perché Visual Studio danneggia il file.

Answer 1

Credo di poter fornire qualche informazione in Da accadendo, se non il perché.

FF FE è un href="http://en.wikipedia.org/wiki/Byte_order_mark" rel="nofollow noreferrer"> BOM ; la sua presenza all'inizio del file indica che la codifica del file è UTF-16, little-endian. E suona come il file originale è davvero UTF-16, ma qualcosa sta ignorando la distinta e leggendo come se fosse UTF-8.

Quando ciò accade, ciascuno dei byte FF e FE viene trattata come non validi e convertito U+FFFD, il carattere ufficiale Unicode spazzatura. Poi, quando il testo viene scritto in un file di nuovo, ognuno dei caratteri illeggibili viene convertito la sua codifica UTF-8 (EF BF BD) e il UTF-8 BOM (EF BB BF) viene aggiunto di fronte a loro , causando la sequenza di nove byte da te segnalato:

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

Se questo è il caso, semplicemente sostituendo i nove byte con FF FE non è sicuro. Non c'è alcuna garanzia quelle sono le uniche byte del file che sarebbe valida se interpretato come UTF-8. Fino a quando il file contiene solo caratteri ASCII che stai bene, ma qualsiasi altra cosa, come caratteri accentati (é) o le virgolette (’), sarà irrimediabilmente alterati.

Sono i file di progetto dovrebbero davvero essere UTF-16? Se non, forse che il sistema di uno sviluppatore sta generando UTF-16 quando il sistema di controllo della versione si aspetta UTF-8. Ho notato nel mio Visual C # Express Install c'è un'opzione in Environment->Documents chiamato "Salva i documenti come Unicode quando i dati non possono essere salvati nella tabella codici". Che suona come qualcosa che potrebbe causare la codifica a cambiare, a volte apparentemente casuali.