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

Любые обсуждения, не нарушающие правил форума.

Модератор: Модераторы

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

Сообщение скалогрыз » 05.11.2014 01:05:22

pda писал(а):Попробуйте вместо:
Код: Выделить всё
AO=#$C3#$85; // U+00C5


вставить:
Код: Выделить всё
AO=#$CC#$8A; // U+030A 'COMBINING RING ABOVE'


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

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

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

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

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

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

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

Сообщение kazalex » 05.11.2014 02:46:11

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

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

скалогрыз писал(а):Довод технический, но мало практичесикий...

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

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

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

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

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

Сообщение Vapaamies » 05.11.2014 03:43:03

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

Улыбнется. 8) :lol: :roll: :mrgreen:
Аватара пользователя
Vapaamies
постоялец
 
Сообщения: 291
Зарегистрирован: 24.07.2012 22:37:59
Откуда: Санкт-Петербург

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

Сообщение kazalex » 05.11.2014 20:14:50

Vapaamies писал(а):Улыбнется.

Только в случае использования символов из supplementary диапазона. В рамках работы с BMP о суррогатах можно не думать и работать с UTF-16, как с USC-2 т.к. диапазоны суррогатов не пересекаются с другими символами из BMP. Но пример хороший, прямо в масть :mrgreen:
kazalex
постоялец
 
Сообщения: 296
Зарегистрирован: 01.06.2012 14:54:10

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

Сообщение pda » 05.11.2014 22:44:10

скалогрыз писал(а):Но это же решаемо, вместо 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. Бабах!
Аватара пользователя
pda
постоялец
 
Сообщения: 303
Зарегистрирован: 27.05.2005 19:59:53

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

Сообщение Vapaamies » 05.11.2014 23:37:20

kazalex писал(а):Но пример хороший, прямо в масть :mrgreen:

Ага, ага. Пишешь себе программку чтения сообщений из вконтактика -- а там внезапно emoji. Так что "верхний юникод" намного ближе, чем кажется.
Аватара пользователя
Vapaamies
постоялец
 
Сообщения: 291
Зарегистрирован: 24.07.2012 22:37:59
Откуда: Санкт-Петербург

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

Сообщение Cheb » 16.12.2014 15:49:22

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

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

'COMBINING RING ABOVE'

Кстати! Есть ли в RTL стандартная процедура типа "нормализовать WideString, вырезав все несошедшиеся многобайтовые последовательности к ядрене фене"?
Аватара пользователя
Cheb
энтузиаст
 
Сообщения: 994
Зарегистрирован: 06.06.2005 15:54:34

Пред.

Вернуться в Потрепаться

Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 19

Рейтинг@Mail.ru