Comments 16
UFO just landed and posted this here
Почему только UTF-32 <-> UTF-8? Целевая платформа — только Linux?
UFO just landed and posted this here
Нам для задач достаточно UTF-8 и UTF-32… Для доступа или замены i-ого символа для скорости лучше применять UTF-32, для остальных случаях, видимо UTF-8 подходит… UTF-16 что-то промежуточное и непонятно зачем нужное…
UFO just landed and posted this here
UTF-16 что-то промежуточное и непонятно зачем нужноеНу как сказать, для Windows sizeof( wchar_t ) == 2, и в ней нативно используется UCS-2 (ранний вариант стандарта UTF-16, не допускающий последовательностей если правильно помню), в Linux sizeof( wchar_t ) == 4 и применяется UTF-32.
Если работать с современными системами, основанными на коде WinNT, то основными вызовами там будут вызовы функций с постфиксом W, например OpenFileW(...), ожидающие на входе именно «двубайтные» символы, а если вызывать OpenFileA(...) с обычными «однобайтными», то система выполнит преобразование символов и всё равно вызовет OpenFileW(...). При этом UTF-8 не поддерживается.
Поэтому я и спросил про целевую платформу. При использовании Windows с подходом «достаточно UTF-8 и UTF-32» возникнут огромные накладные расходы дополнительных преобразований. QChar, кстати, тоже 16-ти битный, что чревато опять же, накладными расходами, если его использовать (ведь не просто так же вы о нём в статье упоминали?).
А с решением Björn Höhrmann не сравнивали? Его код выглядит гениально коротким и быстрым.
UNICODE это не только преобразование из utf-8 в utf-32 и обратно, там главное — классификация символов. В библиотеке Strutext https://github.com/merfill/strutext реализован UTF-8 итератор по байтовому потоку, а также в symbols.h определены классы символов и функция определения класса по его коду. Код итератора — это адаптация библитеки разбора utf-8 от unicode.org, там сделано хорошо и быстро. Классы символов лежат в файле UnicdeData.txt, это родная база классов символов от unicode.org, которая при сборке проекта парсится в сишные структуры.
5 и 6-байтовых UTF-8 символов не бывает, см. RFC 3629.
По скорости код с Qt не сравнивали?
По скорости код с Qt не сравнивали?
Никаких тяжёлых операций, только проверка условий, ...
Сброс конвейера, все дела, не? Всё-таки интересно было бы увидеть сравнение с решением Björn Höhrmann (ссылка выше). Не берусь сказать, что будет быстрее.
Ещё можно "поиграться" со std::string::reserve(). В вашем коде оно будет вызываться явно больше одного раза (на больших строках), при желании можно сократить до одного вызова вначале.
Это следует учитывать и при сравнительных тестах.
Нету проверок на Overlong Sequence и прочий испорченный UTF8 — потенциальная дыра в безопасности.
Sign up to leave a comment.
Unicode — это очень увлекательно