View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0002493 | SAS.Планета | Рефакторинг / Refactoring | public | 06-09-2014 17:32 | 03-11-2015 12:22 |
| Reporter | vdemidov | Assigned To | vdemidov | ||
| Priority | normal | Severity | minor | Reproducibility | N/A |
| Status | resolved | Resolution | fixed | ||
| Product Version | 121010 | ||||
| Target Version | 151111 | Fixed in Version | 151111 | ||
| Summary | 0002493: Упорядочить использование RegExpr и RegExprUtils | ||||
| Description | Сейчас регулярные выражения из этих юнитов используются как для AnsiString так и для string. На неюникодной версии делфи это не представляет проблемы, но после перехода будет приводить к неоправданным перекодировкам из юникода и обратно. Нужно подумать что с этим делать. Возможно для AnsiString использовать TALPerlRegEx из юнита ALString библиотеки alcinoe. Текущее состояние: Используется для string Во всех реализациях ITileFileNameParser u_GeoCoderByCoord u_GeoCoderByWikimapia fr_ExportToJNX u_CmdLineArgProcessorHelpers u_UpdateDownloader (это судя по всему ошибка, которую нужно исправлять) Используется для AnsiString u_BasePascalCompiler u_TileRequestBuilderHelpers u_GeoCoderByNavitel u_GeoCoderByRosreestr u_GeoCoderByURL | ||||
| Tags | No tags attached. | ||||
|
|
> Возможно для 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. ...они там сами в строках капитально нахимичили, что чёрт ногу сломит. |
|
|
Хотя я вот сейчас ещё посмотрел в код alcinoe, и там походу прямо передаются ансишные строки, хотя pcre работает только с utf8 же. Да и при компиляции регэкспов передаётся флаг PCRE_UTF8, и как-то всё работает. |
|
|
>Доступен только начиная с XE2. Мда. Недосмотрел. Но что-то думать нужно. Потому тикет и завел. |
|
|
Кстати, а почему не взять отсюда готовый враппер из раздела Regular Expressions Classes for Older Versions of Delphi? И добавить условную компиляцию для XE2. |
|
|
И там и в 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} т.е. тупо отключили варнинги и оно там конвертирует лишний раз из одного типа строк в другой (хоть и без потери данных, как они уверяют, но однозначно, с потерей производительности). |
|
|
Почитал хелп по юникоду в pcre и могу сделать вывод, что alcinoe ожидает только utf8 строки, поэтому если в XE2 нужны регэкспы для ансишных срок, их нужно писать самому. Хотя, "писать" это громко сказано, потому как тип строк в pcre определяется одним флагом PCRE_UTF8: с ним - utf8, без него - ansi. |
|
|
Ну, для юникодных строк можно продолжать пользоваться той реализацией, что уже есть, а для ансишных взять тот враппер? Еще один варинт, это избавиться от регекспов в парсерах имен тайлов. Они там упрощают код, но несколько излишни. И тогда можно будет даже пережить конвертацию юникода в утф-8 перед обработкой регекспами. |
|
|
> Они там упрощают код, но несколько излишни. Ну, регэкспы у нас везде упрощают код. А так, при желании и в паскаль-скриптах от них можно избавиться. И будет как в геокодерах - куча Pos и Copy :) Зато, наверное быстрее. Хотя не факт. |
|
|
Будет быстрее. Факт. Особенно в парсере tqrs формата тайлов. Поэтому я и предлагаю смириться с преобразованием в utf-8, там где скорость не критична. И переписать на ручной разбор мест, где хочется получить максимальную скорость. pcre этому вполне удовлетворяет. |
|
|
Ну, ок, переписывай. |
|
|
Не, я сначала заменю на регекспы работающие через utf-8, а если кому покажется что стало медленнее, тот и будет переписывать |
|
|
Я тут слегка подумал. Похоже в большинстве мест вполне удастся свести все к работе регекспов с AnsiString. Даже в ITileFileNameParser, так как у нас все форматы кэша подразумевают наличие только Ansi символов в самом имени файла. Всякая фигня может появиться только в полном имени папки с кэшом. Так что достаточно не передавать в парсер полный путь, а только часть с именем тайла, начиная от зума. |
|
|
TRegExpr под XE2 вообще переходит на WideString, так что нет никакого практического смысла менять string на AnsiString у нас по коду. Оно в любом случае будет перекодироваться. Но если ты хочешь реально избавиться от ненужных перекодировок, то нужно подходить более глобально к вопросу и менять TRegExpr на что-то другое. |
|
|
А это будет следующим шагом. Я просто переведу весь юнит на AnsiString и ALStrings. И будет оно везде работать одинаково. |
|
|
Не знаю, что там будет дальше, но пока что варнингов в 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' и т.д. |
|
|
Ну да. Надеюсь за выходные переведу регулярки на анси и эти плюс еще куча варнингов пропадет. И можно будет попробовать выкладывать публичные ночнушки собранные в юникодной делфе. |
|
|
Вроде бы причесал. Осталось пару варнингов в геоконвертере по координатам (u_GeoCoderByCoord). |
|
|
По-моему, зря ты перешёл на ansi в регэкспах и в расширении файлов. Это потенциальные грабли в будущем. Вернее, хуже чем сейчас оно конечно не будет, но и юникодной мощи XE2 развернуться будет сложно - ты кругом расставил оградительных флажков с добровольным отказом от юникода. И ещё меня терзают смутные сомнения по поводу utf-8 в параметрах прокси. Хотя, может всё так и надо. Ты в своих действиях уверен? |
|
|
Насчет ограничения ansi в расширениях уверен примерно 90% - я пока вообще не встречал расширений содержащих не Ansi символы и очень надеюсь, что не встречу. Как и имен тайлов с символами за Ansi диапазоном. В крайнем случае, если очень сильно понадобиться, можно будет вернуть на место. Зато имеющаяся у нас реализация регекспов в анси работает быстрее, потому что может использовать set of char вместо массивов символов. Насчет параметров прокси, то тут уверенности меньше, но я с трудом представляю как его сделать по-другому. А юникодная мощь проявится и без этого. Например в том, что кэш можно будет запихать в папки с любым именем в любой локали. Имя импортируемого файла может быть любым, с любыми иероглифами (главное что бы расширение было английским, но что мы будем делать с файлом с китайским расширением?) и тд. |
|
|
Кстати. В юникодной версии вполне нормально отображаются иероглифы в названии и описании меток. А ты говоришь юникодная мощь не развернется. |
|
|
Ха, так то метки. Там никаких ограничений нету и там идёт конвертирование string -> utf-8, но никак не в ansi. |
|
|
Ну так покажи мне где эти ограничения добавились? Метки - нормально, Панарамио и Викимапия с иероглифами - нормально. Имея папки для кэша карты с иероглифами - нормально. |
|
|
Поиск в гугле иероглифов - нормально, поиск иероглифов в метках - нормально. Остальные геокодеры нужно проверять каждый отдельно, но никакого отношения к регекспам это уже не имеет. |
|
|
>И ещё меня терзают смутные сомнения по поводу utf-8 в параметрах прокси. Теперь я уверен, что туда нельзя отправлять utf-8. В Alcinoe используются функции InternetOpenA и InternetConnectA, которые работают только с текущей кодировкой системы. Если мы хотим большего, нужно отказываться от Alcinoe и использовать юникодные версии этих функций (но и там, utf-8 не пройдёт, а только WideString). |
|
|
InternetOpenA и как это помешает отправить прокси серверу логин в utf-8? Нужно проверять на каком-то вменяемом прокси. |
|
|
Ну, давай тогда менять все на AnsiString и принудительно проверять что логин и пароль не содержат символов с не Ascii кодами. |
|
|
Но, вообще это все нужно обсуждать в инциденте 0002697 |
| 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 | |
| 09-09-2014 09:34 | vdemidov | Note Edited: 0014634 | |
| 23-10-2014 09:04 | vdemidov | Target Version | 141111 => 150915 |
| 22-01-2015 14:22 | vdemidov | Description Updated | |
| 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 | |
| 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 | |
| 08-08-2025 13:25 | zed | Category | Рефакторинг => Рефакторинг / Refactoring |