Файл проекта Visual Studio 2008 не загружается из-за неожиданного изменения кодировки

Question

В нашей команде у нас есть проект базы данных в Visual Studio 2008, который находится под управлением исходного кода Team Foundation Server.Примерно каждые две недели, после регистрации одного сотрудника, файл проекта не загружается на компьютеры других разработчиков.Сообщение об ошибке выглядит следующим образом:

Не удалось загрузить файл проекта.Данные на корневом уровне недопустимы.Строка 1, позиция 1.

Когда я просматриваю файл проекта в Notepad ++, файл выглядит следующим образом:

��<NUL?NULxNULmNULlNUL NULvNULeNULrNULsNULiNULoNULnNUL ...

и так далее (вы можете видеть <?xml version в этом) в то время как обычный файл проекта выглядит как:

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

Так что, вероятно, что-то не так с кодировкой файла.Это проблема для нас, потому что оказывается невозможным снова получить правильную кодировку файла."Решение" состоит в том, чтобы выбросить файл проекта и получить последнюю известную рабочую версию из системы управления версиями.

Согласно файлу, кодировка должна быть UTF-16.Согласно Notepad ++, поврежденный файл на самом деле имеет формат UTF-8.

Мои вопросы таковы:

• Почему Visual Studio портит кодировку файла проекта, по-видимому, в случайное время и на случайных машинах?
• Что мы должны сделать, чтобы предотвратить это?
• Когда это произойдет, есть ли возможность восстановить текущий файл в правильной кодировке вместо извлечения более старой версии из системы управления версиями?

В качестве последнего замечания:проблема связана с одним единственным файлом проекта, все остальные файлы проекта не раскрывают эту проблему.

Обновить:Благодаря предложению Джона Скита у меня есть ответ на вопрос номер три.Когда я заменю первые девять байтов EF BB BF EF BF BD EF BF BD на два байта FF FE, файл проекта загрузится снова.

Это все еще оставляет вопрос, почему Visual Studio повреждает файл.

Answer 1

Я думаю, что могу дать некоторое представление о что такое происходит, если не почему.

FF FE является РОЖДЕННЫЙ;его присутствие в начале файла указывает на то, что кодировкой файла является UTF-16 с начальным порядком.И похоже, что исходный файл действительно имеет формат UTF-16, но что-то игнорирует спецификацию и читает ее так, как если бы это был UTF-8.

Когда это произойдет, каждый из байтов FF и FE рассматривается как недействительный и преобразуется в U+FFFD, официальный мусорный символ Юникода.Затем, когда текст снова записывается в файл, каждый из символов мусора преобразуется в свою кодировку UTF-8 (EF BF BD) и тот UTF-8 Спецификация (EF BB BF) добавляется перед ними, в результате чего получается последовательность из девяти байтов, о которой вы сообщили:

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

Если это так, просто замените эти девять байтов на FF FE это небезопасно.Нет никакой гарантии, что это единственные байты в файле, которые были бы недопустимы при интерпретации как UTF-8.Пока файл содержит только символы ASCII, все в порядке, но все остальное, например, символы с ударением (é) или фигурные кавычки (’), будет безвозвратно искалечен.

Действительно ли файлы проекта должны быть в формате UTF-16?Если нет, возможно, система этого одного разработчика генерирует UTF-16, когда система контроля версий ожидает UTF-8.Я заметил, что в моей установке Visual C # Express есть опция в разделе Environment->Documents называется "Сохранять документы в формате Unicode, когда данные не могут быть сохранены в кодовой странице".Это звучит как нечто, что может привести к изменению кодировки в явно случайные моменты времени.