|
Notes |
|
|
(0014613)
|
|
zed
|
|
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
|
|
07-09-2014 18:37
|
|
|
Хотя я вот сейчас ещё посмотрел в код alcinoe, и там походу прямо передаются ансишные строки, хотя pcre работает только с utf8 же. Да и при компиляции регэкспов передаётся флаг PCRE_UTF8, и как-то всё работает. |
|
|
|
|
>Доступен только начиная с XE2.
Мда. Недосмотрел. Но что-то думать нужно. Потому тикет и завел. |
|
|
|
|
|
Кстати, а почему не взять отсюда готовый враппер из раздела Regular Expressions Classes for Older Versions of Delphi? И добавить условную компиляцию для XE2. |
|
|
|
(0014626)
|
|
zed
|
|
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
|
|
09-09-2014 07:54
|
|
|
Почитал хелп по юникоду в pcre и могу сделать вывод, что alcinoe ожидает только utf8 строки, поэтому если в XE2 нужны регэкспы для ансишных срок, их нужно писать самому. Хотя, "писать" это громко сказано, потому как тип строк в pcre определяется одним флагом PCRE_UTF8: с ним - utf8, без него - ansi. |
|
|
|
|
|
Ну, для юникодных строк можно продолжать пользоваться той реализацией, что уже есть, а для ансишных взять тот враппер? Еще один варинт, это избавиться от регекспов в парсерах имен тайлов. Они там упрощают код, но несколько излишни. И тогда можно будет даже пережить конвертацию юникода в утф-8 перед обработкой регекспами. |
|
|
|
(0014631)
|
|
zed
|
|
09-09-2014 09:09
|
|
> Они там упрощают код, но несколько излишни.
Ну, регэкспы у нас везде упрощают код. А так, при желании и в паскаль-скриптах от них можно избавиться. И будет как в геокодерах - куча Pos и Copy :) Зато, наверное быстрее. Хотя не факт. |
|
|
|
|
Будет быстрее. Факт. Особенно в парсере tqrs формата тайлов.
Поэтому я и предлагаю смириться с преобразованием в utf-8, там где скорость не критична. И переписать на ручной разбор мест, где хочется получить максимальную скорость. pcre этому вполне удовлетворяет. |
|
|
|
(0014633)
|
|
zed
|
|
09-09-2014 09:19
|
|
|
|
|
(0014634)
|
|
vdemidov
|
09-09-2014 09:33
(edited on: 09-09-2014 09:34) |
|
Не, я сначала заменю на регекспы работающие через utf-8, а если кому покажется что стало медленнее, тот и будет переписывать
|
|
|
|
|
|
Я тут слегка подумал. Похоже в большинстве мест вполне удастся свести все к работе регекспов с AnsiString. Даже в ITileFileNameParser, так как у нас все форматы кэша подразумевают наличие только Ansi символов в самом имени файла. Всякая фигня может появиться только в полном имени папки с кэшом. Так что достаточно не передавать в парсер полный путь, а только часть с именем тайла, начиная от зума. |
|
|
|
(0016614)
|
|
zed
|
|
23-10-2015 09:21
|
|
|
TRegExpr под XE2 вообще переходит на WideString, так что нет никакого практического смысла менять string на AnsiString у нас по коду. Оно в любом случае будет перекодироваться. Но если ты хочешь реально избавиться от ненужных перекодировок, то нужно подходить более глобально к вопросу и менять TRegExpr на что-то другое. |
|
|
|
|
|
А это будет следующим шагом. Я просто переведу весь юнит на AnsiString и ALStrings. И будет оно везде работать одинаково. |
|
|
|
(0016617)
|
|
zed
|
|
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'
и т.д. |
|
|
|
|
|
Ну да. Надеюсь за выходные переведу регулярки на анси и эти плюс еще куча варнингов пропадет. И можно будет попробовать выкладывать публичные ночнушки собранные в юникодной делфе. |
|
|
|
|
|
Вроде бы причесал. Осталось пару варнингов в геоконвертере по координатам (u_GeoCoderByCoord). |
|
|
|
(0016630)
|
|
zed
|
|
26-10-2015 12:22
|
|
По-моему, зря ты перешёл на ansi в регэкспах и в расширении файлов. Это потенциальные грабли в будущем. Вернее, хуже чем сейчас оно конечно не будет, но и юникодной мощи XE2 развернуться будет сложно - ты кругом расставил оградительных флажков с добровольным отказом от юникода.
И ещё меня терзают смутные сомнения по поводу utf-8 в параметрах прокси. Хотя, может всё так и надо. Ты в своих действиях уверен? |
|
|
|
|
Насчет ограничения ansi в расширениях уверен примерно 90% - я пока вообще не встречал расширений содержащих не Ansi символы и очень надеюсь, что не встречу. Как и имен тайлов с символами за Ansi диапазоном. В крайнем случае, если очень сильно понадобиться, можно будет вернуть на место. Зато имеющаяся у нас реализация регекспов в анси работает быстрее, потому что может использовать set of char вместо массивов символов.
Насчет параметров прокси, то тут уверенности меньше, но я с трудом представляю как его сделать по-другому.
А юникодная мощь проявится и без этого. Например в том, что кэш можно будет запихать в папки с любым именем в любой локали. Имя импортируемого файла может быть любым, с любыми иероглифами (главное что бы расширение было английским, но что мы будем делать с файлом с китайским расширением?) и тд. |
|
|
|
|
|
Кстати. В юникодной версии вполне нормально отображаются иероглифы в названии и описании меток. А ты говоришь юникодная мощь не развернется. |
|
|
|
(0016635)
|
|
zed
|
|
27-10-2015 08:51
|
|
|
Ха, так то метки. Там никаких ограничений нету и там идёт конвертирование string -> utf-8, но никак не в ansi. |
|
|
|
|
|
Ну так покажи мне где эти ограничения добавились? Метки - нормально, Панарамио и Викимапия с иероглифами - нормально. Имея папки для кэша карты с иероглифами - нормально. |
|
|
|
|
Поиск в гугле иероглифов - нормально, поиск иероглифов в метках - нормально.
Остальные геокодеры нужно проверять каждый отдельно, но никакого отношения к регекспам это уже не имеет. |
|
|
|
(0016708)
|
|
zed
|
03-11-2015 11:25
(edited on: 03-11-2015 11:26) |
|
>И ещё меня терзают смутные сомнения по поводу utf-8 в параметрах прокси.
Теперь я уверен, что туда нельзя отправлять utf-8. В Alcinoe используются функции InternetOpenA и InternetConnectA, которые работают только с текущей кодировкой системы. Если мы хотим большего, нужно отказываться от Alcinoe и использовать юникодные версии этих функций (но и там, utf-8 не пройдёт, а только WideString).
|
|
|
|
|
|
InternetOpenA и как это помешает отправить прокси серверу логин в utf-8? Нужно проверять на каком-то вменяемом прокси. |
|
|
|
|
|
Ну, давай тогда менять все на AnsiString и принудительно проверять что логин и пароль не содержат символов с не Ascii кодами. |
|
|
|
|
|
Но, вообще это все нужно обсуждать в инциденте 0002697 |
|