Компилятор VC ++ / source-charset: utf-8 не работает - PullRequest
0 голосов
/ 16 мая 2018

Пока я экспериментирую с блоками кода под utf-8 в Visual Studio, я обнаружил много ловушек:

  1. По умолчанию VS сохраняет исходный файл с кодировкой, связанной с системной областью, для меняЭто GB2312 (кодовая страница 936, китайская кодировка).

    Решение: я использую сохранить как и сохранить файл с UTF-8 без подписи.

  2. Затем я обнаружил, что по умолчанию компилятор интерпретируетисходный файл с кодировкой, связанной с системным регионом, который по-прежнему является GB2312, поэтому я получил удивительное предупреждение и синтаксическую ошибку.

    Решение: я использую /source-charset:utf-8 для компиляции, без предупреждений и ошибок.Но в результате размер равен 2 ('知' в GB2312 кодируется двумя кодовыми единицами).Но это должно быть 3 под utf-8.

'知' Ссылка на Unicode https://unicode -table.com / ru / 77E5 /

(думаю, можно использоватьлюбой символ, который существует в вашей текущей системной кодировке и в utf-8, но с другим размером кодового блока для проведения аналогичного теста.)

Код:

#include <iostream>
#include <string>
using namespace std;

    int main(){
        string s = "知";
        cout << s.size() <<endl;
        cout << s << endl;
    }

Кроме того,Windows cmd, а также powershell также используют кодировку, связанную с системным регионом (введите chcp в cmd).Поэтому я не могу печатать такие символы, как ə.

Так что мне нужно позаботиться о трех вещах:

  1. Кодировка исходного файла
  2. Является ли компиляторинтерпретировать исходный файл как ожидалось
  3. Возможно, cmd не сможет отобразить символ, даже если удовлетворены 1. и 2.

Кроме того, из-за этого возникла путаницаопыт:

  1. Почему Windows действует так?Можно ли просто установить все с помощью utf-8?Я скопировал тот же файл на Mac, и все работает, как ожидалось.И очень легко установить терминальную кодировку Mac.
  2. В некоторых сообщениях, которые я нашел, говорилось, что причина в том, что некоторые стандарты кодирования (такие как этот GB2312) создаются до выхода utf-8.И многие из них не совместимы с utf-8.Так что он продолжает использовать для совместимости.

    Но мне интересно, как могла бы возникнуть несовместимость?Например, я загружаю NotePad ++ и устанавливаю все языковые пакеты.Моя системная кодировка - GB2312, но я все еще могу изменить язык отображения NotePad ++ на японский, и он хорошо отображается.Не такая вещь, как ????.

1 Ответ

0 голосов
/ 16 мая 2018

Термин «исходная кодировка» здесь не случаен.Стандарт C ++ явно проводит различие между (базовым) исходным набором символов (96 общих символов, все в простом ASCII) и набором символов выполнения.

Поскольку вы использовали UTF-8 в качестве исходного набора символов, отображается на \u77E5.

Однако во время выполнения вы используете набор символов выполнения .Опция VC ++ /source-charset не влияет на набор символов выполнения VC ++;для этого есть /execution-charset

Но, как уже отмечает @Matteo Italia, среда выполнения VC ++, как известно, более чем ненадежна, когда дело доходит до ввода / вывода UTF-8.std::string.size должно работать, но std::cout может не работать.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...