FPC и UTF-32

[Alexander]

Не стоит ли перевести FPC в части типа string на UTF-32 ?

То есть полностью заменить представление о символе как о байте на символ из четырёх байт.

Собственно в Питоне это уже сделано,

"В GNU/Linux тип wchar_t имеет размер 32 бита. "

То есть всё располагает (и располагало сразу) к этому, но возможно есть некое предвзятое отношение к UTF-32, например, http://www.codenet.ru/progr/other/FPC-Unicode.php :

Управление строками на низком уровне, требующее поддержки компилятора полностью реализовано, за исключением, разве что совсем экзотических UTF-32 и UCS4 кодировок.

. Почему же это "экзотично", как раз наоборот. Юникод по смыслу четырёхбайтный, в системе wchar_t четырёхбайтный. Вместо этого широко распространилась какая-то неудачная полумерная 16-битная реализация, которая ни то ни сё.

Тогда проблема с Length(s) которая выдаёт непонятное значение и прямым индексированием широких строк исчезнет.

[Alex2013]

В чем глубокий смысл UTF-32? UTF-8 и так 1-4 байта ( хотя вроде бывает больше "но это неточно" ) а если сильно надо для индексирования (хотя если единица хранения текстовых данных строка то смысл подобного от меня ускользает ) то по идее можно юзать "неэкономное кодирование" . Насколько я понимаю Length(s) выдает значение в байтах ( и это правильно) но есть LengthUTF8(s) и кстати должно быть и LengthUTF32(s) потому что символ может быть составной.

[Alexander]

Глубокого смысла в этом нет, просто решает ряд проблем. Но в некотором смысле UTF-32 и есть "неэкономное кодирование".
В том то и дело, что 1-4, а здесь всегда 4. И индексирование символа и длина строки упрощены и однозначны.
При кодировке 1-4 байта есть сразу два взгляда на символ: он то байт, то несколько байт и возникает сложность в расчёте их и понимании, что есть вообще строка. Опять же лучшая совместимость с системой.

Добавлено спустя 3 минуты 33 секунды:
> LengthUTF32(s) потому что символ может быть составной.

Может этого можно и избежать. Как я понял из описания - это для UTF-32 излишне.
https://ru.wikipedia.org/wiki/UTF-32

[Alex2013]

Да да это "киберпанк который мы заслужили" то самое "данные дешевы". Но все-же ИМХО для внутреннего представления в конкретной программе обычно достаточно старых 8-битных кодировок ... или это из серии "учим китайский заранее"? Разумеется для парсинга веб страниц и тому подобного это не вариант, но есть 100500 случаев когда больше ничего не надо.

[Alexander]

Ну, кроме web-страниц имена файлов сейчас юникодные. Да и ридми даже уже давно в utf8.
lintian забракует текстовые файлы в национальных кодировках в пакете.
Почему-то при термине Юникод часто вспоминают в первой строчке "китайский". Но как-то последовательно было бы русский, латинский, а как формулы, так и греческий (уже больше байта на символ), а там и до китайского недалеко.
В общем-то переход с национальных кодировок на Юникод за 25 лет завершился и теперь всё такое "киберпанковое".

Но случаи однобайтной кодировки наверное можно как-то выделить - тоже скоростная возможность
из прошлого и небольшой ряд одноязыковых задач мог бы ими быть решён эффективно.
Не 100500 конечно, но в таких случаях без них будет упущена эффективность.

На заре Юникода браузеры попав на иероглифическую страницу надолго "задумывались", потом их заоптимизировали как смогли, но зато и иероглифы стали видны.

[Снег Север]

Вообще-то - полный абсурд экономить байты на удобном представлении и обработке текста в 21 веке и держаться за стандарты, введенные полвека и более назад.

[Awkward]

Не поверите, но до сих пор существует проблема экономии памяти, даже при работе с текстом.

[Снег Север]

Не поверите, но до сих пор существует проблема экономии памяти, даже при работе с текстом.

Не поверю. Может, на микроконтроллерах, но там текст - вопрос 25-й.

[sts]

Почему-то при термине Юникод часто вспоминают в первой строчке "китайский".

потому что алфавитные языки помещаются в однобайтовую кодировку, многобайтовую кодировку разработали, в первую очередь, ради иероглифов а потом уже объединили разные кодировки в юникод.

по поводу UTF-32, нужно так проектировать язык, компилятор, апи, чтобы в исходниках было все равно - string это utf8 или WideString (ucs2) или utf32

[Sharfik]

Не стоит ли перевести FPC в части типа string на UTF-32 ?

Кому это надо, пусть и пишет свою программу так, что в ней будет априори подразумеваться UTF-32.
А если у человека в одном места Length() в другом Copy(S,1,1) в третьем Text[i], в четвертом UTFLength() - ему ничто не похоже быть проклятым пользователями.

Только переделали laz на поддержку UTF-8, еще даже не все библиотеки адаптированы. А людям опять подавай извращений....

[iskander]

Только переделали laz на поддержку UTF-8

Но это неточно?

Имхо текущее состояние Юникода - "хотели как лучше, а получилось как всегда"(с).