Хорошо ли обрабатывать символы юникода с помощью wchar_t?Не вызывает ли это никаких проблем? - PullRequest
1 голос
/ 28 сентября 2019

Я искал способ обработки польских слов.Я читал об utf8, 16, 32, но любое преобразование из char в utf дает мне другое письмо.

wchar_t дает правильное письмо, хотя.

Это нормально делатьэто так?

А как насчет производительности, если, например, я буду использовать только ascii, просто потому что?Влияет ли это на приложение?

1 Ответ

2 голосов
/ 28 сентября 2019

Вы путаете две разные вещи:

  1. Хранение

    Как вы храните байты, составляющие вашу текстовую строку.Это будет в массиве char (однобайтовых) значений?Или это будет в виде wchar_t (многобайтовых) значений?

  2. Кодировка

    Ваш компьютер (и вы!)нужно знать, что делать со значениями в этих байтах.Что они имеют в виду?Независимо от хранилища это могут быть ASCII, некоторые кодовые страницы , UTF-8, UTF-16, UTF-32, Klingon, что угодно.

Обычно , по историческим причинам, мы выбираем char для однобайтовых кодировок (например, ASCII) и UTF-8, и wchar_t для UTF-16 (особенно в Windows, которая имеет 16-битные wchar_t s).и обычно предполагает эту комбинацию во всем своем API - обратите внимание, что она неверно называет это просто «Unicode»).

Производительность на самом деле не влияет, хотя вы сэкономите время и энергию, конвертируя между различными кодировками, если вывыберите one и придерживайтесь его (и используйте механизм хранения, который подходит для библиотек строк, которые вы используете).Иногда ваша ОС поможет определить этот выбор, но мы не можем сказать вам, каким он будет.

Аналогичным образом, ваши утверждения о том, что «работает» и «не работает», очень расплывчаты и, вероятно, ложны..

Мы не можем сказать, что "нормально", не зная требований вашего проекта, какого компьютера он будет использовать и с какими технологиями.Я, однако, сделаю огромное обобщение: в старые времена вы могли использовать Мазовия с кодировкой , измененную кодовую страницу с польскими символами;в настоящее время вы, вероятно, хотите сделать переносимость и обмен как можно более легкими (потому что почему бы нет ?!), поэтому вам будет предложено придерживаться UTF-16 над wchar_t в Windows и UTF-8 над char в противном случае.

(Начиная с C ++ 20 у нас также будет char8_t, механизм хранения, специально разработанный для обозначения того, что он хранит данные в кодировке UTF-8; однако, это будет некоторое времяпрежде чем вы увидите это в широком использовании, если оно вообще есть. Вы можете прочитать больше о символьных типах C ++ в статье cppreference.com о "Фундаментальных типах" )

...