Правильный способ обработки Unicode с C ++ в 2018 году? - PullRequest
0 голосов
/ 31 мая 2018

Я попытался выполнить поиск в stackoverflow, чтобы найти ответ на этот вопрос, но я нашел примерно 1001 * 10 лет вопросов и ответов, и я не могу найти консенсуса по этому вопросу из-за изменений ивозможный прогресс.

Есть несколько известных мне библиотек вне stl, которые должны обрабатывать unicode-

Есть несколько особенностей stl ( wstring , codecvt_utf8 ), которые были включены, но люди, кажется, имеют двойственное отношение к использованию, потому что они имеют дело с UTF-16, который этот сайт: ( utf-8 везде ) говорит, что не должен использоваться, и многие люди в Интернете, похоже, согласны спосылка.

Единственное, что я ищу, - это возможность делать 4 вещи со строками в юникоде -

  1. Читать строку в память
  2. Поискстрока с регулярным выражением с использованием Unicode или ASCII, объединить или сделать замену текста / форматдобавьте в него ascii + номера Unicode или символы.
  3. Преобразуйте в ascii + формат номера Unicode для символов, которые не вписываются в диапазон ascii.
  4. Записать строку на диск илиотправить куда угодно.

Из того, что я могу сказать, icu обрабатывает это и многое другое.Я хотел бы знать, есть ли стандартный способ справиться с этим в Linux, Windows и MacOS.

Спасибо за ваше время.

1 Ответ

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

Я попытаюсь привести некоторые идеи здесь:

  • большинство программ / программистов на C ++ просто предполагают, что текст представляет собой почти непрозрачную последовательность байтов.UTF-8, вероятно, виновен в этом, и неудивительно, что многие комментарии возобновляют: не беспокойтесь о Unicode, просто обрабатывайте строки в кодировке UTF-8
  • файлы содержат только байты,В настоящий момент, если вы попытаетесь внутренне обработать истинные кодовые точки Unicode, вам придется сериализовать это в байты -> и здесь UTF-8 выигрывает точку
  • , как только вы выходите изБазовая многоязычная плоскость (16-битные кодовые точки), вещи становятся все более и более сложными. emoji особенно ужасен в обработке: за эмодзи может следовать селектор вариаций (U + FE0E VARIATION SELECTOR-15 (VS15) для текста или U + FE0F VARIATION SELECTOR-16(VS16) для стиля эмодзи), чтобы изменить его стиль отображения, более или менее старый i bs ^, который использовался в 1970-х годах, когда кто-то хотел напечатать î.Это еще не все, символы от U + 1F3FB до U + 1F3FF используются для предоставления цвета кожи для 102 человеческих смайликов, разбросанных по шести блокам: дингбаты, смайлики, разные символы, разные символы и пиктограммы, дополнительные символы и пиктограммы, а также транспорт и карта.Символы.

    Это просто означает, что до 3 последовательных кодовых точек Unicode могут представлять один отдельный глиф ... Таким образом, идея о том, что один символ равен одному char32_t, по-прежнему является приблизительной

Мой вывод заключается в том, что Unicode - это сложная вещь, и для нее действительно требуется специальная библиотека, такая как ICU.Вы можете попробовать использовать простые инструменты, такие как конвертеры стандартной библиотеки, когда имеете дело только с BMP, но полная поддержка намного выше этого.


Кстати: даже другие языки, такие как Python, которые делают вид, что имеютВстроенная поддержка Unicode (которая, на мой взгляд, намного лучше, чем у нынешнего C ++), иногда дает сбой:

  • Библиотека GUI tkinter не может отображать какие-либо кодовые точки вне BMP - хотя это стандартный Python IDLEtool
  • различные модули или стандартная библиотека предназначены для Unicode в дополнение к поддержке основного языка (кодеки и unicodedata), а в индексе пакетов Python доступны и другие модули, такие как поддержка emoji, поскольку стандартная библиотека неудовлетворить все потребности

Таким образом, поддержка Unicode оставляет желать лучшего уже более 10 лет, и я не очень надеюсь, что в ближайшие 10 лет дела пойдут намного лучше ...

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