Unicode в C++11

я немного читал по теме Unicode-в частности, UTF-8 - (не) поддержка в C++11, и я надеялся, что гуру на Stack Overflow могут убедить меня, что мое понимание правильно, или указать, где я неправильно понял или пропустил что-то, если это так.

краткий обзор

во-первых, хорошо: вы можете определить UTF-8, UTF-16 и UCS-4 литералов в исходном коде. Кроме того,<locale> заголовок содержит несколько std::codecvt реализации, которые могут конвертировать между любым из UTF-8, UTF-16, UCS-4 и многобайтовой кодировкой платформы (хотя API кажется, мягко говоря, менее чем простым). Эти codecvt реализации могут быть imbue() ' d на потоках, чтобы позволить вам сделать преобразование, как Вы читаете или пишете файл (или другой поток).

[EDIT: Cubbi указывает в комментариях, что я забыл упомянуть о , которая содержит std::codecvt реализации которых не зависит от локали. Кроме того,std::wstring_convert и wbuffer_convert функции могут использовать эти codecvtS для преобразования строк и буферов напрямую, не полагаясь на потоки.]

C++11 также включает в себя C99 / C11 <uchar.h> заголовок, который содержит функции для преобразования отдельных символов из многобайтовой кодировки платформы (которая может быть или не быть UTF-8) В и из UCS-2 и UCS-4.

однако, это о степени его. Хотя вы, конечно, можете хранить текст UTF-8 в std::string, там я не вижу способов сделать с ним что-то действительно полезное. Например, кроме определения литерала в коде, вы не можете проверить массив байтов как содержащий допустимый UTF-8, вы не можете узнать длину (т. е. количество символов Юникода, для некоторого определения "символа") UTF-8-containing std::string, и вы не можете перебирать std::string в любом случае, кроме байт за байтом.

аналогично, даже добавление C++11 std::u16string не поддерживает UTF-16, но только старый UCS-2 - он не поддерживает суррогатные пары, оставляя вас только с BMP.

замечания

учитывая, что UTF-8 является стандартным способом обработки Unicode практически на каждой Unix-производной системе (включая Mac OS X и* Linux) и в значительной степени стал де-факто стандартом в интернете, отсутствие поддержки в современном C++ кажется довольно серьезным упущением. Даже на Windows, тот факт, что новый std::u16string на самом деле не поддерживают UTF-16 кажется несколько прискорбным.

_{* как указано в комментариях и ясно здесь, BSD-производные части Mac OS используют UTF-8, в то время как Cocoa использует UTF-16.}

вопросы

если вы сумели прочитать все это, спасибо! Просто несколько быстрых вопросов, так как это переполнение стека в конце концов...

• является ли приведенный выше анализ правильным, или есть какие-либо другие средства поддержки Unicode, которые я не хватает?

• комитет по стандартам проделал фантастическую работу за последние пару лет, продвигая C++ вперед быстрыми темпами. Они все умные люди, и я предполагаю, что они хорошо знают о вышеуказанных недостатках. Есть ли какая-то известная причина, по которой поддержка Unicode остается такой плохой в C++?

• забегая вперед, кто-нибудь знает о каких-либо предложениях по исправлению ситуации? Быстрый поиск на isocpp.org не похоже, чтобы раскрыть что угодно.

EDIT: спасибо всем за ваши ответы. Я должен признаться, что нахожу их немного обескураживающими-похоже, статус-кво вряд ли изменится в ближайшем будущем. Если есть консенсус среди cognoscenti, похоже, что полная поддержка Unicode слишком сложна, и любое решение должно переопределить большую часть ICU, чтобы считаться полезным.

я лично с этим не согласен; Я думаю, что есть ценная середина, которую нужно найти. Например, алгоритмы проверки и нормализации для UTF-8 и UTF-16 хорошо определены консорциумом Unicode и могут быть предоставлены стандартной библиотекой в качестве свободных функций, скажем, a std::unicode пространство имен. Это само по себе было бы большим подспорьем для программ на C++, которые должны взаимодействовать с библиотеками, ожидающими ввода Unicode. Но исходя из приведенного ниже ответа (окрашенного, надо сказать, с оттенком горечи) кажется, что предложение щенка ибо именно такого рода ограниченная функциональность не была хорошо воспринята.