Microsoft IDE, исходные кодировки файлов, спецификации и символ Unicode \ uFEFF? - PullRequest
3 голосов
/ 28 ноября 2011

У нас есть парсеры для различных языков Microsoft (VB6, VB.net, C #, MS диалекты C / C ++).

Они поддерживают Unicode, если мы все согласны с тем, что такое Unicode.Где мы не согласны, наш объект лексеров.

Все последние версии MS IDE, похоже, читают / пишут свои файлы исходного кода в UTF-8 ... Я не уверен, что это всегда так.Есть ли справочный документ, который разъясняет, как MS будет писать файл кода souce?С метками порядка байтов или без них?Отличается ли он от версии IDE к версии?(Я не могу себе представить, что старая среда разработки VB6 написала что-то кроме 8-битного набора символов, и я предполагаю, что это будет в кодировке CP-xxxx, установленной локалью, верно?)

Для C # (и я предполагаю, что другие современные языковые диалекты поддерживаются MS), код символа \ uFEFF фактически может быть найден в середине файла.Этот код определяется как пробел нулевой ширины без перерывов.Похоже, что он игнорируется VS 2010, когда находится в середине идентификатора, в пробеле, но имеет значение для ключевых слов и чисел.Итак, каковы правила?Или у MS есть некие нормализаторы-идентификаторы для обработки таких вещей, как составные символы, которые позволяют обрабатывать разные строки идентификаторов как идентичные?

Ответы [ 3 ]

4 голосов
/ 29 ноября 2011

В некотором смысле это не ответ, потому что он говорит не о том, что говорит Microsoft, а о том, что говорят стандарты.Надеюсь, что это все равно поможет.

U + FEFF как обычный символ

Как вы сказали, U + FEFF следует рассматривать как BOM (метку порядка байтов) в начале файла,Теоретически он также может появляться в середине текста, поскольку на самом деле это символ, обозначающий неразрывный пробел нулевой ширины (ZWNBSP).В некоторых языках / системах письма все слова в строке объединяются (= пишутся вместе), и в таких случаях этот символ может использоваться в качестве разделителя, как обычный пробел в английском, но он не вызывает типографически видимого пробела.Я на самом деле не знаком с такими сценариями, поэтому мое мнение может быть не совсем правильным.

U + FEFF должен отображаться только как спецификация

Однако использование U + FEFF в качестве ZWNBSP устарело начиная с версии Unicode 3.2 и в настоящее время является цельюиз U + FEFF должен действовать как спецификация.Вместо ZWNBSP в качестве разделителя консорциум Unicode настоятельно предпочитает использовать символ U + 2060 (объединитель слов).Их FAQ также предлагают , что любой U + FEFF, встречающийся в середине файла, может рассматриваться как неподдерживаемый символ, который должен отображаться как невидимый.Другое возможное решение, которое приходит мне в голову, - это заменить любой U + FEFF, встречающийся в середине файла, на U + 2060 или просто игнорировать его.

Случайно добавленный U + FEFF

IУгадайте, что наиболее вероятная причина появления U + FEFF в середине текста заключается в том, что это ошибочный результат (или побочный эффект) конкатенации строк.RFC 3629, который включал в себя использование спецификации, означает, что для объединения строк необходимо удалить начальный U + FEFF.Это также подразумевает, что символ может быть просто удален при нахождении в середине текста.

U + FEFF и UTF-8

U + FEFF, поскольку спецификация не имеет реального эффекта, когда тексткодируется как UTF-8, поскольку он всегда имеет один и тот же порядок байтов.Спецификация в UTF-8 создает помехи системам, которые полагаются на наличие определенных ведущих символов и протоколов, которые явно предписывают метод кодирования или идентификации кодирования.Реальный мировой опыт также показал, что некоторые приложения подавляются UTF-8 с помощью спецификации.Поэтому использование спецификации, как правило, не рекомендуется при использовании UTF-8.Удаление спецификации из файла в кодировке UTF-8 не должно приводить к неправильной интерпретации файла (если только не существует какой-либо контрольной суммы или цифровой подписи, связанной с потоком байтов файла).

1 голос
/ 29 ноября 2011

О том, «как MS напишет файл кода souce»: VS может сохранять файлы как с BOM, так и без нее, а также в целом ряде других кодировок. По умолчанию используется UTF-8 с спецификацией. Вы можете попробовать это самостоятельно, зайдя в Файл -> Сохранить ... как -> щелкните треугольник на кнопке «Сохранить» и выберите «Сохранить с кодировкой».

Об использовании FEFF в реальном коде - никогда не видел, чтобы кто-то использовал его в коде ... Википедия предлагает рассматривать его как пробел нулевой ширины, если это произошло где-нибудь, кроме первой позиции (http://en.wikipedia.org/wiki/Byte_order_mark).

0 голосов
/ 29 ноября 2011

Для C ++ файл является либо Unicode с BOM, либо будет интерпретироваться как ANSI (имеется в виду системная кодовая страница, не обязательно 1252).Да, вы можете сохранять в любой кодировке, которую захотите, но компилятор захлебнется, если вы попытаетесь скомпилировать файл Shift-JIS (японский, кодовая страница 932) в ОС с 1252 в качестве системной кодовой страницы.На самом деле, даже редактор ошибется.Вы можете сохранить его как Shift-JIS в системе 1252, и все будет хорошо.Но закройте проект и откройте его, и текст выглядит как мусор.Таким образом, информация нигде не сохраняется.

Так что это ваше лучшее предположение: если нет спецификации, предположим, ANSI.Это то, что делает редактор / компилятор.

Также: VS 2008 и VS 2010, более старые редакторы, где нет Unicode дружественных.А в C ++ есть иные правила, чем в C # (для C ++ файлы по умолчанию являются ANSI, для C # - utf-8)

...