freepascal.ru

Почему внутри программы все популярнее становятся строки UTF16, тогда как формат обмена данными UTF8? Например, в python3, delphi XE2, XE3 внутренние строки хранятся в UTF16. Ведь тогда лишнюю конвертацию данных надо проводить, когда на вход поступает UTF8, преобразуешь в UTF16, и то же самое делаешь на выходе - из UTF16 преобразуешь в UTF8.
Чем объясняется такая необходимость? Почему внутри строки в UTF16? Ведь проще сделать везде UTF8, и в форматах обмена и внутри.

hovadur писал(а):Почему внутри строки в UTF16?

Потому что в UTF16 каждый символ в общем случае занимает четко определенные фиксированные два байта, что очень удобно для индексации, а символы строк UTF-8, гм... вообще не подлежат индексации, чтобы отсчитать какой-нибудь символ - нужно каждый раз декодировать строку от начала.

И, кстати, UTF16 - внутренняя кодировка Windows. Что-то мне говорит, что в первую очередь ноги растут оттуда.

hovadur писал(а):внутренние строки хранятся в UTF16

Вы о них плохо думаете. В linux gcc/g++ например wstring/wchar орудуют 32-битным представлением уникода

Добавлено спустя 5 минут 38 секунд:

hovadur писал(а):Ведь тогда лишнюю конвертацию данных надо проводить

В этом вашем delphi XE вообще то конвертация данных происходит при каждом присвоении друг другу строковых переменных с разной кодовой страницей, только сей факт тщательно скрыт от взора компилятором. Так что далеко не только на входе и выходе "потери". И они куда большие чем вы озвучили.

четко определенные фиксированные два байта

Но ведь UTF16 может содержать от 2 до 4 байтов.

Так что далеко не только на входе и выходе "потери".

Я понимаю. Если внутри только String, то нужно только контролировать вход и выход. А там всего лишь надо четко находить, чтоб из AnsiString(UTF_8) конвертировалось в String только один раз. Ассемблерный код тоже никто не отменял, там хорошо видны вставки LStrFromUStr, UStrFromLStr.

И, кстати, UTF16 - внутренняя кодировка Windows

В fpc2.7 тоже планируют добавить UTF16 строки. А fpc поддерживает уже много платформ. Не уж-то только из-за Windows городить конвертацию, терять производительность? (Я знаю, что при обращении к виндовым функциям типа W нужно тоже делать конвертацию, ну или сама Windows ее делает, если обращаешься к функциям типа A)

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

Процессоры бывают разные. Для x86 лучше всего выравнивание по машинным словам, т.е. 4 или 8 байт (для x86_64). Но из-за большей длины адресуемых данных меньше влезает в кэш, промахи обращения к кэшу съедают выигрыш за счет выравнивания.
Работая над fcl-xml, я ради эксперимента делал вариант с utf32. Разницы по быстродействию по сравнению с utf16 не заметил.

Почему внутри строки в UTF16? Ведь проще сделать везде UTF8, и в форматах обмена и внутри.

Потому что так умнее Конверитруется толко при чтении из файла и записи в файл, все остальные (ресурсовемкие) манипулциии - с быствым и индексириуемым представлением. РАботать в памяти с UTF8 - мазохизм типа "АНДРОИД вместо нативных приложений". 4-байтная UTF16 вряли когда-либо понадобится - даже китайцы с их иероглифами переключились на упрощенную (2 байтную) кодировку. 4 байта могут потребоваться разве что для будущих алфавитов инопланетян.

Лично мне UTF-8 куда более симпатична и непонятно, зачем вообще куча хлама в виде WideString, UnicodeString и т. п. с их transparent conversions понадобилась где-либо кроме $MODE DELPHI, когда можно было обойтись единственным однобайтовым string с настройкой его кодировки (ANSI с пометкой "obsolete" / UTF-8 по дефолту) в опциях проекта. Очень напрягает, например, невозможность использовать юникод в стандартных файловых функциях.

Во-первых, 7-bit ASCII без изменений (почему и юзают в подавляющем большинстве исходников) и совместимость почти со всеми строковыми ASCII-функциями.
Во-вторых, никаких проблем с endianness.
В-третьих... Поддержку UTF-16 очень просто зафейлить и не заметить этого — всего-то забыть про суррогатные пары. Что бы там ни говорили, UCS-2 как минимум не forward-compatible. С UTF-8 такая ошибка в принципе невозможна.

Как заметил Sergei I. Gorelkin, итерирование UTF-8 строки не медленнее UTF-16, и обычно этого достаточно. Нужна быстрая индексируемость (ну мало ли) — онли UTF-32.

UTF8 хороша только тогда, когда код не превращается в посмещище из-за нашпигованности вызовами "UTF8To..()" & "toUTF8()".

debi12345 писал(а):нашпигованности вызовами "UTF8To..()" & "toUTF8()".

Ну это наверное обёртки над системными вызовами в винде?
Просто сгруппируй их в одном месте, не размазывай по коду...