VS2010 не понимает строковое кодирование своих файлов
Я работаю с проектом Unicode VS2010, который все прекрасно работает. Когда я удаляю свои локальные файлы и загружаю свежую копию из системы контроля версий (Perforce), resource.h файл читает неправильно (на китайском).
// {{}} NO_DEPENDENCIES ⼀ ⼀ 䴀 椀 挀 爀 漀 猀 漀 昀 琀 嘀 椀 猀 甀 愀 氀 䌀 ⬀⬀ 最 攀 渀 攀 爀 愀 琀 攀 搀 椀 渀 挀 氀 甀 搀 攀 昀 椀 氀 攀 ⸀ഀഀ // Используется MyDemo.rc define ⼀ ⼀ ഀഀ # define IDM_ABOUTBOX 0x0010 ⌀ 搀 攀 昀 椀 渀 攀 䐀 䐀 䐀 䐀 䈀 伀 吀 吀 吀 堀
Почему VS2010 это делает? и как я могу это исправить? По сути, это идентичный файл, но в одном случае он открывается, а в новом случае он не может определить кодировку файла.
Хотя это проект MFC, но, похоже, это не имеет никакого отношения к этой проблеме.
Решение
Это похоже на проблему с Perforce’s преобразование конца строки и невозможность правильно вывести формат UTF16 для resource.h
Следуя инструкциям Вот может решить проблему, если вы столкнетесь с ней в будущем:
проблема
В Windows после синхронизации текстовых файлов (типа файла Perforce), содержащих
кодировка utf16, файл в моей рабочей области кажется поврежденным.Решение
Поскольку кодировка символов utf16 является двухбайтовой кодировкой символов
и Perforce рассматривает «текстовые» файлы как один байт, вы можете столкнуться с
проблемы рендеринга или повреждения в среде Windows. Линия Windows
окончания неправильно преобразованы в наборе символов UTF16 для
«текстовые» файлы. Это повредит содержимое файла utf16.Редакции файлов с содержимым utf16 всегда должны отправляться с использованием
тип файла «utf16» (при добавлении Perforce автоматически обнаружит utf16
файлы, если пользователь или правило карты типов не переопределяют это поведение).Чтобы решить вашу проблему, выполните следующие действия:
- Отредактируйте свою спецификацию рабочей области и измените значение поля LineEnding на «unix»
- Принудительно синхронизировать файл (преобразование не заканчивается)
- Убедитесь, что файл рабочей области теперь отображается правильно
- Извлеките файл (ы), изменив тип файла на utf16 (измените с «text» на «utf16»)
- Отредактируйте свою спецификацию рабочей области и измените значение поля LineEnding обратно на «local»
- Отправить новую версию файла
Пример:
p4 client bruno_ws LineEnd: unix p4 sync -f myfile.txt p4 edit -t utf16 myfile.txt p4 client bruno_ws LineEnd: local p4 submit -d "Fixing unicode file"
Другие решения
Я думаю, что я видел эту проблему раньше, поэтому я собираюсь ответить на это сейчас, когда я понял это. Каким-то образом resource.h кодировка или формат были испорчены, и я не знаю почему. Я не вносил в него никаких изменений вручную. Perforce не смог обнаружить изменения и правильно отобразить их в сравнении. Однако это не выдает сообщение «Файлы идентичны», которое обычно появляется, если файлы идентичны. Однако, если я делаю «Вернуть неизмененные файлы», он откатывает назад, не обнаруживая изменений.
Я использовал шестнадцатеричный инструмент сравнения, и внутренности двух файлов были разными. Я просто выбрал тот, который работал. Кроме того, размер файла также отличался по некоторым причинам.
Правильный файл показывает следующее
//{{NO_DEPENDENCIES}}
// Microsoft Visual C++ generated include file.
// Used by MyDemo.rc
//
#define IDD_ABOUTBOX 100
....
Resource.h должен быть в формате ANSI.
Иногда Visual Studio преобразует его в Unicode и помещает 2-байтовую спецификацию в начале. Однако, когда он загружен в редактор IDE, он не может распознать его и отображает как китайский.
Если вы посмотрите в шестнадцатеричном редакторе, вы сможете прочитать содержимое файла.
Решение состоит в том, чтобы использовать независимый текстовый редактор (я использую Notepad ++ или Notepad2) и убедиться, что файл закодирован в формате ANSI без спецификации.
Затем проверьте файл и больше не открывайте его в Visual Studio.
Если вам нужно внести изменения, всегда обращайтесь к внешнему редактору и убедитесь, что после сохранения кодировка по-прежнему соответствует ANSI.
Я не знаю, почему это происходит. Я предполагаю, что локаль по умолчанию ОС отличается от локали ресурса проекта VS. Затем среда IDE запутывается и, вероятно, пытается преобразовать файл ресурсов в Unicode, чтобы избежать проблем с преобразованием, но Resource.h — это не обычный текстовый файл. Компиляторы, кажется, не понимают исходники Unicode с BOM.