Delphi и ObjFPC такие разные

[скалогрыз]

Попробуйте вместо:

Код: Выделить всё

AO=#$C3#$85; // U+00C5

вставить:

Код: Выделить всё

AO=#$CC#$8A; // U+030A 'COMBINING RING ABOVE'

Что теперь получается?

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

Рахница будет в том, что при использовании utf8, проверка "окончаний" будет выполнятся на много байтовых строках, а в UTF16 на widechar строках.
При правильном написании, т.к. деакретические знаки в основном 2 байтовые в utf8, сравнение будет одинаково эффективно

С суророгатными парами мало кому вообще улыбнется встретиться, тогда как кодирование в UTF-8 суровая реальность за рамками ASCII

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

На самом деле понятие "суровая реальность" - это на 50% культурное восприятие. Почему, потому что мы привыкли что кирилица умещается в 128..255, и рабта многим (начинающим) программистам с мульти-байтовой кодировкой выглядит сложной. А какие-нибудь китайцы или японцы - всю жизнь работали только с мульти-байтовыми кодировками, им это не кажется трудоёмким.
Так же есть мнение (не проверял), что японцы и китайцы редко пишут (писали в бытность string-ов)код вроде:
s[Pos('с',s)]:='C';
сразу обрабатывая строку как мультибайтовая кодировка. И переход для utf-ы (любых мастей), для них особой проблемы не составляет, в психологическом плане

[kazalex]

Но это же решаемо, вместо StringReplace должен применятся другой алгоритм замены.

Достаточно выполнить нормализацию строки, впрочем, это касается юникода вообще, а не только конкретного представления

Довод технический, но мало практичесикий...

Тут, строго говоря, всё от задачи зависит. Никто, надеюсь, не станет оспаривать тезис о том, что в частных случаях вполне допустимо работать с UTF-16, как с UCS-2, тогда как в общих случаях (библиотечный код, например) не учитывать существования суррогатов нельзя.

И переход для utf-ы (любых мастей), для них особой проблемы не составляет, в психологическом плане

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

Но даже если опустить сложности психологического плана , есть вполне ощутимые сложности технического характера. У меня была задача, где необходимо было сканировать строки, проверяя наличие символов требующих экранирования и при необходимости деля строку по границе символа, если она, вдруг, не помещалась в буфер. Ничего особенного, но первый вариант алгоритма работал со строками в кодировке UTF-8, которая изначально была выбрана для внутреннего представления юникода. И там было всё в полный рост: детекция последовательностей, их размера и валидация. Это действительно много кода. После перехода на UTF-16 (вот где был психологический барьер!), та же самая задача решалась значительно более простым кодом, при этом с учетом суррогатов и обязательным требованием о их неразделении. Будь для этих форм представления юникода библиотечные функции, разница в количестве кода не была бы столь заметной, что, впрочем, не уменьшило бы объема проделываемой работы для UTF-8.

[Vapaamies]

С суророгатными парами мало кому вообще улыбнется встретиться

Улыбнется.

[kazalex]

Улыбнется.

Только в случае использования символов из supplementary диапазона. В рамках работы с BMP о суррогатах можно не думать и работать с UTF-16, как с USC-2 т.к. диапазоны суррогатов не пересекаются с другими символами из BMP. Но пример хороший, прямо в масть

[pda]

Но это же решаемо, вместо StringReplace должен применятся другой алгоритм замены.

Да кто же спорит-то. Но цимес в том и состоял, что нельзя просто так взять и оставить ansi'шный rtl, перейдя на utf-8.

При правильном написании, т.к. деакретические знаки в основном 2 байтовые в utf8, сравнение будет одинаково эффективно

Ох, если бы всё было так просто, то в библиотеках, типа libICU не было бы нужды. Но... Не знаками едиными. Немецкий подбросит проблем с лигатурами, турецкий - с переводом в верхний и нижний регистр, французский - со сравнениями...

Добавлено спустя 8 минут 52 секунды:
Кстати, я уверен, что когда в Lazarus LCL переводили на UTF-8 - проблемы вылезали. Не могло такого не быть. Допустим, у нас есть старая программа, написанная до этого. Она рассчитана на cp1251. Внезапно LCL начинает ждать Utf8String. Он "совместим" с AnsiString и компиляция проходит. Где-то в программе собирается строка в 1251 и передаётся в компонент. Но он-то теперь ждёт UTF-8... Или наоборот. Компонент отдаёт UTF-8, другая функция, возможно даже из rtl ждёт 1251. Бабах!

[Vapaamies]

Но пример хороший, прямо в масть

Ага, ага. Пишешь себе программку чтения сообщений из вконтактика -- а там внезапно emoji. Так что "верхний юникод" намного ближе, чем кажется.

[Cheb]

С суророгатными парами мало кому вообще улыбнется встретиться,

Hell yeah Я для своего игрового движка выбрал внутренним форматом WideString, и тупо считаю, что один символ - одна буква. Всё равно он умеет только 288 букв отображать из всего многообразия, сколько в одну текстуру влезло
Зато работать на порядок удобнее. Если надо вывести строку - процедура знает, что в ей ровно Length() символов. И т.п.

'COMBINING RING ABOVE'

Кстати! Есть ли в RTL стандартная процедура типа "нормализовать WideString, вырезав все несошедшиеся многобайтовые последовательности к ядрене фене"?