0002493: Упорядочить использование RegExpr и RegExprUtils

Notes
(0014613) zed (manager) 07-09-2014 18:31	> Возможно для AnsiString использовать TALPerlRegEx из юнита ALString библиотеки alcinoe Доступен только начиная с XE2. Вообще, я тоже смотрел на регэкспы и немного гуглил этот вопрос и пришёл к выводу, что нужно брать pcre api и obj с XE6 или на крайняк отсюда и написать свой небольшой врапер, на подобиии того, что есть в Alcinoe (можно оттуда и слямзить в качестве каркаса), но для всех типов строк (utf8 и ansi). У нас регулярки заюзаны не очень активно, так что возможностей примитивной обёртки, сварганеной на быструю руку, будет вполне достаточно. Вот тут к примеру, пишут, что нужно юзать флаг PCRE_NO_UTF8_CHECK чтобы регэкспы работали реально быстро. Но в стандартной библиотеке, и в Alcinoe этот флаг не установлен, поэтому по ходу дела, нужно ещё и оптимизировать. А в стандартной либе, там вообще чудеса: One thing you need to watch out for is that the TPerlRegEx versions you can download here as well as those included with Delphi XE, XE2, and XE3 use UTF8String properties and all the Offset and Length properties are indexes to those UTF-8 strings. This is because at that time PCRE only supported UTF-8 and using UTF8String avoids repeated conversions. In Delphi XE4 and XE5 TPerlRegEx has UnicodeString (UTF-16) properties but still returns UTF-8 offsets and lengths. In Delphi XE6 the Offset and Length properties were changed to UTF-16 offsets and lengths. This means that code that works with XE3 or XE6 that uses the Offset and Length properties will not work with XE4 and XE5 if your strings contain non-ASCII characters. XE4, XE5, and XE6 still use the UTF-8 version of PCRE even though PCRE now has native UTF-16 support. This combined with the use of UnicodeString means constant conversions between UTF-16 and UTF-8. ...они там сами в строках капитально нахимичили, что чёрт ногу сломит.

(0014614) zed (manager) 07-09-2014 18:37	Хотя я вот сейчас ещё посмотрел в код alcinoe, и там походу прямо передаются ансишные строки, хотя pcre работает только с utf8 же. Да и при компиляции регэкспов передаётся флаг PCRE_UTF8, и как-то всё работает.

(0014617) vdemidov (manager) 07-09-2014 18:49	>Доступен только начиная с XE2. Мда. Недосмотрел. Но что-то думать нужно. Потому тикет и завел.

(0014625) vdemidov (manager) 09-09-2014 06:46	Кстати, а почему не взять отсюда готовый враппер из раздела Regular Expressions Classes for Older Versions of Delphi? И добавить условную компиляцию для XE2.

(0014626) zed (manager) 09-09-2014 06:59	И там и в alcinoe предлагают работать только с одним типом строк. В alcinoe это ansi, а в том врапере ansi для D2007 и UTF-8 для XE2. Нам же нужно иметь возможность парсить как ansi, так и юникод и в D2007 и в XE2. Плюс ко всему, у врапера читаем: // All implicit string casts have been verified to be correct {$WARN IMPLICIT_STRING_CAST OFF} т.е. тупо отключили варнинги и оно там конвертирует лишний раз из одного типа строк в другой (хоть и без потери данных, как они уверяют, но однозначно, с потерей производительности).

(0014628) zed (manager) 09-09-2014 07:54	Почитал хелп по юникоду в pcre и могу сделать вывод, что alcinoe ожидает только utf8 строки, поэтому если в XE2 нужны регэкспы для ансишных срок, их нужно писать самому. Хотя, "писать" это громко сказано, потому как тип строк в pcre определяется одним флагом PCRE_UTF8: с ним - utf8, без него - ansi.

(0014629) vdemidov (manager) 09-09-2014 08:16	Ну, для юникодных строк можно продолжать пользоваться той реализацией, что уже есть, а для ансишных взять тот враппер? Еще один варинт, это избавиться от регекспов в парсерах имен тайлов. Они там упрощают код, но несколько излишни. И тогда можно будет даже пережить конвертацию юникода в утф-8 перед обработкой регекспами.

(0014631) zed (manager) 09-09-2014 09:09	> Они там упрощают код, но несколько излишни. Ну, регэкспы у нас везде упрощают код. А так, при желании и в паскаль-скриптах от них можно избавиться. И будет как в геокодерах - куча Pos и Copy :) Зато, наверное быстрее. Хотя не факт.

(0014632) vdemidov (manager) 09-09-2014 09:16	Будет быстрее. Факт. Особенно в парсере tqrs формата тайлов. Поэтому я и предлагаю смириться с преобразованием в utf-8, там где скорость не критична. И переписать на ручной разбор мест, где хочется получить максимальную скорость. pcre этому вполне удовлетворяет.

(0014633) zed (manager) 09-09-2014 09:19	Ну, ок, переписывай.

(0014634) vdemidov (manager) 09-09-2014 09:33 edited on: 09-09-2014 09:34	Не, я сначала заменю на регекспы работающие через utf-8, а если кому покажется что стало медленнее, тот и будет переписывать

(0016613) vdemidov (manager) 23-10-2015 08:44	Я тут слегка подумал. Похоже в большинстве мест вполне удастся свести все к работе регекспов с AnsiString. Даже в ITileFileNameParser, так как у нас все форматы кэша подразумевают наличие только Ansi символов в самом имени файла. Всякая фигня может появиться только в полном имени папки с кэшом. Так что достаточно не передавать в парсер полный путь, а только часть с именем тайла, начиная от зума.

(0016614) zed (manager) 23-10-2015 09:21	TRegExpr под XE2 вообще переходит на WideString, так что нет никакого практического смысла менять string на AnsiString у нас по коду. Оно в любом случае будет перекодироваться. Но если ты хочешь реально избавиться от ненужных перекодировок, то нужно подходить более глобально к вопросу и менять TRegExpr на что-то другое.

(0016615) vdemidov (manager) 23-10-2015 09:30	А это будет следующим шагом. Я просто переведу весь юнит на AnsiString и ALStrings. И будет оно везде работать одинаково.

(0016617) zed (manager) 23-10-2015 14:35	Не знаю, что там будет дальше, но пока что варнингов в XE2 только добавилось (65 до изменений vs 72 после): [DCC Warning] RegExprUtils.pas(64): W1058 Implicit string cast with potential data loss from 'WideString' to 'AnsiString' [DCC Warning] RegExprUtils.pas(83): W1058 Implicit string cast with potential data loss from 'WideString' to 'AnsiString' [DCC Warning] u_GeoCoderByCoord.pas(130): W1058 Implicit string cast with potential data loss from 'string' to 'AnsiString' и т.д.

(0016618) vdemidov (manager) 23-10-2015 15:03	Ну да. Надеюсь за выходные переведу регулярки на анси и эти плюс еще куча варнингов пропадет. И можно будет попробовать выкладывать публичные ночнушки собранные в юникодной делфе.

(0016626) vdemidov (manager) 26-10-2015 10:45	Вроде бы причесал. Осталось пару варнингов в геоконвертере по координатам (u_GeoCoderByCoord).

(0016630) zed (manager) 26-10-2015 12:22	По-моему, зря ты перешёл на ansi в регэкспах и в расширении файлов. Это потенциальные грабли в будущем. Вернее, хуже чем сейчас оно конечно не будет, но и юникодной мощи XE2 развернуться будет сложно - ты кругом расставил оградительных флажков с добровольным отказом от юникода. И ещё меня терзают смутные сомнения по поводу utf-8 в параметрах прокси. Хотя, может всё так и надо. Ты в своих действиях уверен?

(0016631) vdemidov (manager) 26-10-2015 12:41	Насчет ограничения ansi в расширениях уверен примерно 90% - я пока вообще не встречал расширений содержащих не Ansi символы и очень надеюсь, что не встречу. Как и имен тайлов с символами за Ansi диапазоном. В крайнем случае, если очень сильно понадобиться, можно будет вернуть на место. Зато имеющаяся у нас реализация регекспов в анси работает быстрее, потому что может использовать set of char вместо массивов символов. Насчет параметров прокси, то тут уверенности меньше, но я с трудом представляю как его сделать по-другому. А юникодная мощь проявится и без этого. Например в том, что кэш можно будет запихать в папки с любым именем в любой локали. Имя импортируемого файла может быть любым, с любыми иероглифами (главное что бы расширение было английским, но что мы будем делать с файлом с китайским расширением?) и тд.

(0016634) vdemidov (manager) 27-10-2015 07:49	Кстати. В юникодной версии вполне нормально отображаются иероглифы в названии и описании меток. А ты говоришь юникодная мощь не развернется.

(0016635) zed (manager) 27-10-2015 08:51	Ха, так то метки. Там никаких ограничений нету и там идёт конвертирование string -> utf-8, но никак не в ansi.

(0016637) vdemidov (manager) 27-10-2015 10:00	Ну так покажи мне где эти ограничения добавились? Метки - нормально, Панарамио и Викимапия с иероглифами - нормально. Имея папки для кэша карты с иероглифами - нормально.

(0016638) vdemidov (manager) 27-10-2015 10:03	Поиск в гугле иероглифов - нормально, поиск иероглифов в метках - нормально. Остальные геокодеры нужно проверять каждый отдельно, но никакого отношения к регекспам это уже не имеет.

(0016708) zed (manager) 03-11-2015 11:25 edited on: 03-11-2015 11:26	>И ещё меня терзают смутные сомнения по поводу utf-8 в параметрах прокси. Теперь я уверен, что туда нельзя отправлять utf-8. В Alcinoe используются функции InternetOpenA и InternetConnectA, которые работают только с текущей кодировкой системы. Если мы хотим большего, нужно отказываться от Alcinoe и использовать юникодные версии этих функций (но и там, utf-8 не пройдёт, а только WideString).

(0016709) vdemidov (manager) 03-11-2015 11:42	InternetOpenA и как это помешает отправить прокси серверу логин в utf-8? Нужно проверять на каком-то вменяемом прокси.

(0016710) vdemidov (manager) 03-11-2015 11:46	Ну, давай тогда менять все на AnsiString и принудительно проверять что логин и пароль не содержат символов с не Ascii кодами.

(0016711) vdemidov (manager) 03-11-2015 12:22	Но, вообще это все нужно обсуждать в инциденте 0002697

Users who viewed this issue
User List	Anonymous (3981x), vdemidov (51x), zed (23x), bk99 (1x)
Total Views	4056
Last View	23-11-2024 09:28

Issue History
Date Modified	Username	Field	Change
06-09-2014 17:32	vdemidov	New Issue
06-09-2014 17:32	vdemidov	Issue generated from: 0002166
06-09-2014 17:32	vdemidov	Relationship added	child of 0002166
06-09-2014 17:39	vdemidov	Status	new => confirmed
07-09-2014 18:31	zed	Note Added: 0014613
07-09-2014 18:37	zed	Note Added: 0014614
07-09-2014 18:49	vdemidov	Note Added: 0014617
09-09-2014 06:46	vdemidov	Note Added: 0014625
09-09-2014 06:59	zed	Note Added: 0014626
09-09-2014 07:54	zed	Note Added: 0014628
09-09-2014 08:16	vdemidov	Note Added: 0014629
09-09-2014 09:09	zed	Note Added: 0014631
09-09-2014 09:16	vdemidov	Note Added: 0014632
09-09-2014 09:19	zed	Note Added: 0014633
09-09-2014 09:33	vdemidov	Note Added: 0014634
09-09-2014 09:33	vdemidov	Note Edited: 0014634	View Revisions
09-09-2014 09:34	vdemidov	Note Edited: 0014634	View Revisions
23-10-2014 09:04	vdemidov	Target Version	141111 => 150915
22-01-2015 14:22	vdemidov	Description Updated	View Revisions
16-09-2015 14:52	vdemidov	Target Version	150915 => 151010
04-10-2015 15:28	vdemidov	Target Version	151010 => 151111
23-10-2015 08:44	vdemidov	Note Added: 0016613
23-10-2015 09:21	zed	Note Added: 0016614
23-10-2015 09:30	vdemidov	Note Added: 0016615
23-10-2015 14:35	zed	Note Added: 0016617
23-10-2015 15:03	vdemidov	Note Added: 0016618
26-10-2015 10:45	vdemidov	Note Added: 0016626
26-10-2015 12:22	zed	Note Added: 0016630
26-10-2015 12:41	vdemidov	Note Added: 0016631
27-10-2015 07:49	vdemidov	Note Added: 0016634
27-10-2015 07:50	vdemidov	Status	confirmed => resolved
27-10-2015 07:50	vdemidov	Fixed in Version	=> 151111
27-10-2015 07:50	vdemidov	Resolution	open => fixed
27-10-2015 07:50	vdemidov	Assigned To	=> vdemidov
27-10-2015 08:51	zed	Note Added: 0016635
27-10-2015 10:00	vdemidov	Note Added: 0016637
27-10-2015 10:03	vdemidov	Note Added: 0016638
03-11-2015 11:25	zed	Note Added: 0016708
03-11-2015 11:26	zed	Note Edited: 0016708	View Revisions
03-11-2015 11:42	vdemidov	Note Added: 0016709
03-11-2015 11:46	vdemidov	Note Added: 0016710
03-11-2015 12:22	vdemidov	Note Added: 0016711

SASGIS