Блог

Главная - Вопросы по программированию - `wide-exec-charset` не изменяет кодировку `wchar_t`

`wide-exec-charset` не изменяет кодировку `wchar_t`

#c #g #c 17

#c #g #c 17

Вопрос:

Вот простой код на C .

 #include <iostream>
#include <locale>

int main() {
    std::wcout.sync_with_stdio(false);
    std::wcout.imbue(std::locale(""));
    std::cout << std::locale("").name() << std::endl; // C.UTF-8
    
    wchar_t s {L'xd0b8'};
    std::wcout << s << std::endl;
    // expected: и
    // actual: 킸
}
  • 'xd0b8' находится и в UTF-8 и 킸 в UTF-16

Упомянутая в ссылке:

Кодирование узких многобайтовых строковых литералов (1) и широких строковых литералов (2) определяется реализацией. Например, gcc выбирает их с помощью параметров командной строки -fexec-charset и -fwide-exec-charset.

Я выполнил код с помощью g -O3 -fwide-exec-charset=UTF-8 source.cc -o out.a amp;amp; out.a в Ubuntu 20.04.1 LTS (WSL) и ожидал, что результат будет и , однако фактический результат будет 킸 . g не обрабатывает шестнадцатеричное значение в литеральной строке, которое использовалось для прямой инициализации широкого символа s . Как заставить g учитывать значение wide char в UTF-8?

Системная информация:

 > lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 20.04.1 LTS
Release:        20.04
Codename:       focal
> g   -v
Using built-in specs.
COLLECT_GCC=g  
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/9/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none:hsa
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 9.3.0-10ubuntu2' --with-bugurl=file:///usr/share/doc/gcc-9/README.Bugs --enable-languages=c,ada,c  ,go,brig,d,fortran,objc,obj-c  ,gm2 --prefix=/usr --with-gcc-major-version-only --program-suffix=-9 --program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-vtable-verify --enable-plugin --enable-default-pie --with-system-zlib --with-target-system-zlib=auto --enable-objc-gc=auto --enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-offload-targets=nvptx-none,hsa --without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 9.3.0 (Ubuntu 9.3.0-10ubuntu2)

Комментарии:

1. -fwide-exec-charset=UTF-8 не имеет большого смысла. Если вам нужна широкая кодировка символов, вы выбираете широкосимвольную кодировку, такую как UTF-16, а не многобайтовую кодировку, такую как UTF-8. На самом деле вы никогда не должны использовать какие-либо широкие символы. Это устаревшая технология, порожденная ошибочными решениями, принятыми Microsoft и Sun в свое время.

2. Я просто тестирую wchar и пытаюсь понять, как это работает. Я знаю, wchar что он не переносим.

Ответ №1:

man gcc говорит

   -fwide-exec-charset=charset
       Set the wide execution character set, used for wide string and character
       constants.  The default is UTF-32 or UTF-16, whichever corresponds to the width
       of "wchar_t".  As with -fexec-charset, charset can be any encoding supported by
       the system's "iconv" library routine; however, you will have problems with
       encodings that do not fit exactly in "wchar_t".

UTF-8 — это многобайтовая кодировка, которая не совсем подходит wchar_t . Итак, у вас есть именно то, что указано в документации: проблемы. Поскольку sizeof(wchar_t) в Linux равно 4, вам необходимо указать кодировку шириной в 4 байта, такую как UTF-32.

В любом случае нет реальной причины использовать wchar_t для чего-либо, кроме взаимодействия с устаревшим кодом.

Комментарии:

1. После изменения L'xd0b8' на L'x00010437' ( 𐐷 в UTF32BE) и компиляции с -fwide-exec-charset=UTF32LE , препроцессор по-прежнему использует UTF32BE для декодирования L'x00010437' и печати 𐐷 . Похоже, что -fwide-exec-charset также не работает с 4-байтовой кодировкой, подобной UTF32LE.

2. x00010437 это число. Он представлен в виде одного и того же битового шаблона, независимо от используемой кодировки. Попробуйте L'𐐷' , вы увидите, что он выдает разные битовые шаблоны в зависимости от -fwide-exec-charset . Вы также увидите, что только с UTF32LE выводом является 𐐷 . Это потому, что стандартная библиотека понятия не имеет, что ваш конкретный исходный файл скомпилирован с помощью специального -fwide-exec-charset . Это не программная опция. Стандартная библиотека по-прежнему интерпретирует символы wide как UTF32LE. Если вы хотите, чтобы вся ваша программа работала в UTF32BE, вам понадобится стандартная библиотека, перекомпилированная с использованием UTF32BE.

3. Или, я думаю, вы можете использовать соответствующий std::codecvt<wchar_t, ...> аспект.

4. Попробовав изменить ваше предложение L'x00010437' на L'𐐷' , я наконец понял, что кодировка, указанная с -fwide-exec-charset , является целевой кодировкой преобразования из исходных файлов в wchar_t . Однако мне любопытно, является ли перекомпиляция стандартной библиотеки с помощью UFT32 единственным способом изменить кодировку, используемую wcout для чтения байтов в wchar_t , и где находится соответствующий исходный код? Я часами изучал libstdc v3 репозиторий gcc, но не могу найти код, преобразующий UFT32LE в кодировку, установленную с помощью imbue .

5. Вероятно, такого кода нет, если вам нужно это преобразование, вы должны предоставить свой собственный. Но зачем вам это нужно? Используйте то, что работает, то есть char и UTF-8.