O arquivo do projeto Visual Studio 2008 não é carregado devido a uma mudança inesperada de codificação

Question

Em nossa equipe, temos um projeto de banco de dados no Visual Studio 2008, que está sob controle de origem do Team Foundation Server. A cada duas semanas, depois que um colega de trabalho faz check-in, o arquivo do projeto não carrega nas outras máquinas de desenvolvedores. A mensagem de erro é:

O arquivo do projeto não pôde ser carregado. Os dados no nível raiz são inválidos. Linha 1, posição 1.

Quando olho para o arquivo do projeto no bloco de notas ++, o arquivo se parece com o seguinte:

��<NUL?NULxNULmNULlNUL NULvNULeNULrNULsNULiNULoNULnNUL ...

e assim por diante (você pode ver <?xml version neste) enquanto um arquivo de projeto normal se parece:

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

Então provavelmente algo está errado com a codificação do arquivo. Isso é um problema para nós, porque é impossível obter o arquivo codificando correto novamente. A 'Solução' é jogar fora o arquivo do projeto e obter a última versão de funcionamento do Conhecimento do Controle de Origem.

De acordo com o arquivo, a codificação deve ser UTF-16. De acordo com o Notepad ++, o arquivo corrompido é na verdade UTF-8.

Minhas perguntas são:

• Por que o Visual Studio está bagunçando a codificação do arquivo do projeto, aparentemente em momentos aleatórios e em máquinas aleatórias?
• O que devemos fazer para evitar isso?
• Quando aconteceu, existe a possibilidade de restaurar o arquivo atual na codificação correta em vez de extrair uma versão mais antiga do controle de origem?

Como uma última nota: o problema é com um único arquivo de projeto, todos os outros arquivos do projeto não expõem esse problema.

ATUALIZAÇÃO: Graças à sugestão de Jon Skeet, tenho a resposta para a pergunta número três. Quando substituo os nove primeiros bytes ef bb bf ef bf bd ef bf bd pelos dois bytes ff fe, o arquivo do projeto será carregado novamente.

Isso ainda deixa a pergunta por que o Visual Studio corrompe o arquivo.

Answer 1

Eu acho que posso fornecer algumas dicas sobre o que é acontecendo, se não o porquê.

FF FE é um Bom; Sua presença no início do arquivo indica que a codificação do arquivo é UTF-16, Little-Endian. E parece que o arquivo original é realmente UTF-16, mas algo está ignorando o nascido e lendo-o como se fosse UTF-8.

Quando isso acontece, cada um dos bytes FF e FE é tratado como inválido e convertido para U+FFFD, o caráter oficial de lixo unicode. Então, quando o texto é escrito em um arquivo novamente, cada um dos caracteres de lixo é convertido em sua codificação UTF-8 (EF BF BD) e o UTF-8 Bom (EF BB BF) é adicionado à frente deles, resultando na sequência de nove bytes que você relatou:

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

Se for esse o caso, simplesmente substituir esses nove bytes por FF FE não é seguro. Não há garantia de que esses sejam os únicos bytes no arquivo que seriam inválidos quando interpretados como UTF-8. Enquanto o arquivo contiver apenas caracteres ASCII, você está bem, mas qualquer outra coisa, como caracteres acentuados (é) ou citações encaracoladas (’), será irremediavelmente mutilado.

Os arquivos do projeto realmente deveriam ser UTF-16? Caso contrário, talvez o sistema de um desenvolvedor esteja gerando UTF-16 quando o sistema de controle de versão espera UTF-8. Percebo na minha instalação visual c# express, há uma opção em Environment->Documents Chamado "Salvar documentos como unicode quando os dados não podem ser salvos no CodePage". Isso soa como algo que poderia fazer com que a codificação mude em tempos aparentemente aleatórios.