Преобразование исходного модуля из Unicode в ASCII или наоборот серьезно испортит различия? - PullRequest
0 голосов
/ 10 февраля 2010

В наборе тестов у меня были тесты, связанные с юникодом, разбросанные по различным модулям. Теперь я объединил их в один тестовый класс.

Исходные модули .cs, в которых больше нет юникода, остаются в кодировке Юникода, и в результате их размер вдвое больше необходимого Я хотел бы преобразовать их обратно в ASCII, чтобы сэкономить место и улучшить время загрузки этих файлов в редакторах и инструментах.

Q1. Это сломает мои различия? В настоящее время я использую Kdiff3 на своей рабочей станции, но меня больше интересует историческая запись diff для исходных модулей, сгенерированная TFS.

Q2. Есть ли что-то еще, что мне нужно знать о w.r.t. управление исходным кодом при преобразовании модуля из Unicode в ASCII?

Моя конкретная ситуация связана с .NET и TFS, но я думаю, что этот вопрос может быть применим практически к любой системе контроля исходного кода и языку программирования.

Ответы [ 2 ]

1 голос
/ 11 февраля 2010

Странно, что он был преобразован в UTF-16. Но это достаточно легко исправить из Visual Studio 2008. Используйте File + Save As, сохраните то же имя, нажмите стрелку на кнопке Save и выберите Save with Encoding. Нажмите на поле со списком «Кодировка» и выберите UTF8. Это кодировка по умолчанию, используемая VS2008.

Полученный файл имеет спецификацию, как и в вашей версии UTF-16. Этого должно быть достаточно для любого достаточно современного инструмента сравнения, включая KDiff3. Они будут декодировать текст в файле исходного кода обратно в Unicode. Проверьте это на нескольких файлах, чтобы убедиться.

1 голос
/ 11 февраля 2010

Почему бы не конвертировать все в UTF-8? Он может обрабатывать все, что может UTF-16 (что, очевидно, вы подразумеваете под «Unicode»), но символы ASCII будут занимать только один байт каждый, как ASCII. И вам не придется беспокоиться о том, что некоторые ваши файлы находятся в другой кодировке, чем другие. Если ваш инструмент сравнения сначала декодирует файлы в общую кодировку, он не должен нарушать ваши старые различия.

Преобразование UTF-16 в ASCII - очень плохая идея. Вы говорите, что в этих файлах нет ничего, кроме ASCII, но если вы ошибаетесь, не-ASCII символы будут потеряны. То есть, если вы не используете что-то вроде утилиты Java native2ascii, которая преобразует не-ASCII-символы в экранированные символы Юникода (например, Ã -> \u00C3), но это определенно нарушит ваши различия.

...