Unicode - вообще работа с ним в C ++

Question

Предположим, у нас есть произвольная строка, s .

s обладает способностью быть практически из любой точки мира. Люди из США, Японии, Кореи, России, Китая и Греции время от времени пишут в s . К счастью, у нас нет путешественников во времени, использующих Linear A.

Для обсуждения давайте предположим, что мы хотим выполнить строковые операции, такие как:

• обратная * * 1016
• длина
• 1020 * капитализировать *
• строчные буквы
• индекс в

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

Существует 3 стандарта Unicode: utf-8, utf-16 и utf-32, каждый со своими плюсами и минусами. Но, скажем, я немного тупой, и я хочу, чтобы один Unicode управлял ими всеми (потому что создание динамически адаптируемой библиотеки для 3 различных типов кодирования строк, которая скрывает разницу от API пользователя, звучит сложно).

• Какая кодировка наиболее общая?
• Какая кодировка поддерживается wchar_t?
• Какая кодировка поддерживается STL?
• Все ли эти кодировки (или вовсе не) завершены нулем?

-

Суть этого вопроса состоит в том, чтобы научить себя и других полезной и полезной информации для Unicode: чтение RFC - это хорошо, но есть «стопка» информации, относящейся к компиляторам, языкам и операционным системам, которую RFC не делают. Обложка, но важно знать, чтобы на самом деле использовать Unicode в реальном приложении.

Answer 1

1. Какая кодировка наиболее общая
   Вероятно, UTF-32, хотя все три формата могут хранить любой символ. UTF-32 обладает тем свойством, что каждый символ может быть закодирован в одной кодовой точке.

2. Какая кодировка поддерживается wchar_t
   Никто. Это реализация определена. На большинстве платформ Windows это UTF-16, на большинстве платформ Unix - UTF-32.

3. Какая кодировка поддерживается STL
   Нет действительно . STL может хранить любой тип символа, который вы хотите. Просто используйте шаблон std::basic_string<t> с типом, достаточно большим, чтобы сохранить код. Однако большинство операций (например, std::reverse) не знают ни о каком кодировке Unicode.

4. Являются ли все эти кодировки (или вовсе не) нулевыми?
   Нет. Null является допустимым значением в любой из этих кодировок. Технически, NULL также является легальным символом в простом ASCII. NULL завершение - это вещь C, а не кодировка.

Выбор того, как это сделать, во многом зависит от вашей платформы. Если вы работаете в Windows, используйте строки UTF-16 и wchar_t, потому что это то, что Windows API использует для поддержки юникода. Я не совсем уверен, что лучший выбор для платформ UNIX, но я знаю, что большинство из них используют UTF-8.

Answer 2

Ознакомьтесь с библиотекой с открытым исходным кодом ICU , особенно в разделе Документы и документы . Это обширная библиотека, работающая со всевозможными странностями юникода.

Answer 3

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

Answer 4

Определите «реальное приложение»:)

Серьезно, решение действительно во многом зависит от того, какое программное обеспечение вы разрабатываете. Если вашей целевой платформой является Win32 API (с или без оболочек, таких как MFC, WTL и т. Д.), Вы, вероятно, захотите использовать типы wstring с текстом, закодированным как UTF-16. Это просто потому, что все Win32 API внутренне используют эту кодировку в любом случае.

С другой стороны, если ваши выходные данные представляют собой что-то вроде XML / HTML и / или должны быть доставлены через Интернет, UTF-8 в значительной степени является стандартом - обычно он хорошо передается по протоколам, которые делают предположения о символах, имеющих бит.

Что касается UTF-32, я не могу придумать единственную причину его использования, если только вам не нужно отображение 1: 1 между единицами кода и точками кода (это все еще не означает отображение 1: 1 между единицами кода и символами !).

Для получения дополнительной информации обязательно загляните на Unicode.org. Этот FAQ может быть хорошей отправной точкой.