Visual Studio файл проекта 2008 года не загружается из-за неожиданного изменения кодирования
В нашей команде у нас есть проект базы данных в Visual Studio 2008, который является объектом управления исходным кодом Сервером Основы Команды. Каждые две недели или так, после регистраций коллеги, файл проекта не загрузится на других машинах разработчиков. Сообщение об ошибке:
Файл проекта не мог быть загружен. Данные на корневом уровне недопустимы. Строка 1, положение 1.
Когда я смотрю на файл проекта в Блокноте ++, файл похож на это:
��<NUL?NULxNULmNULlNUL NULvNULeNULrNULsNULiNULoNULnNUL ...
и так далее (Вы видите <?xml version в этом), тогда как нормальный файл проекта похож:
<?xml version="1.0" encoding="utf-16"?> ...
Так, вероятно, что-то неправильно с кодированием файла. Это - проблема для нас, потому что оказывается невозможным получить файл, кодирующий корректный снова. 'Решение' состоит в том, чтобы выбросить файл проекта, получение последнего знает рабочую версию от управления исходным кодом.
Согласно файлу, кодирование должно быть UTF-16. Согласно Блокноту ++, поврежденным файлом является на самом деле UTF-8.
Мои вопросы:
- Почему Visual Studio портит кодирование файла проекта, по-видимому, наугад времена и наугад машины?
- Что мы должны сделать для предотвращения этого?
- То, когда это произошло, является там возможностью восстановить текущий файл в корректном кодировании вместо того, чтобы вытянуть более старую версию от управления исходным кодом?
Как последнее примечание: проблема с одним единственным файлом проекта, все другие файлы проекта не выставляют эту проблему.
ОБНОВЛЕНИЕ: Благодаря предложению Jon Skeet у меня есть ответ на вопрос номер три. Когда я заменю первый девятибайтовый EF BB BF EF BF BD EF BF BD двухбайтовым FE FF, файл проекта загрузится снова.
Это оставляет все еще вопрос, почему Visual Studio повреждает файл.
1 ответ
Думаю, я могу дать некоторое представление о , что происходит, если не почему.
FF FE представляет собой спецификацию ; его присутствие в начале файла указывает на то, что кодировка файла - UTF-16, little-endian. И похоже, что исходный файл действительно является UTF-16, но что-то игнорирует спецификацию и читает ее, как если бы это был UTF-8.
В этом случае каждый из байтов FF и FE обрабатывается как недопустимый и преобразуется в U + FFFD , официальный символ мусора Unicode. Затем, когда текст снова записывается в файл, каждый из символов мусора преобразуется в свою кодировку UTF-8 ( EF BF BD ) и в UTF-8 BOM ( 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, если данные не могут быть сохранены в кодовой странице». Похоже, что это может привести к изменению кодировки в случайные моменты времени.