Новые сообщения [новые:0]
Дайджест
Горячие темы
Избранное [новые:0]
Форумы
Пользователи
Статистика
Статистика нагрузки
Мод. лог
Поиск
|
11.04.2020, 22:08
|
|||
---|---|---|---|
(php) Сферический конь в вакууме на регулярках (preg_match_all) |
|||
#18+
Пример 1 (результат корректный, ожидаемый): Код: php 1. 2. 3.
Код: php 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28.
Пример 2 (результат корректный, ожидаемый): Код: php 1. 2. 3.
Код: php 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17.
Пример 3 . Объединим именные карманы DIGIT и LETTER в один общий карман CHAR с помощью опции (?J) Код: php 1. 2. 3.
Код: php 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16.
Пример 4 . Объединённый карман + PREG_PATTERN_ORDER Код: php 1. 2. 3.
Код: php 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23.
Вот здесь мы получили сферического коня в вакууме. Исходя из логики опции (?J) , карман с ключом "CHAR" должен иметь вид ["01", "pp"], а не ["", "pp"]. Т.е. объединения именных карманов не произошло и второй карман с именем "CHAR" перезаписал первый карман с именем "CHAR". Возможны 3 варианта : 1) Особенность "объединения" одноимённых карманов в режиме PREG_PATTERN_ORDER, которую я понять не могу 2) Bug версии php 5.6, исправленный в версии 7.x 3) Bug версии php 7.x тоже, до сих пор не исправленный Для справки : авторIf you are using named patterns you can now have the same name multiple times, provided you put the " (?J) " option in your pattern. For example: Match: (?J)(?P<name>Ni.+)|(?P<name>Fr.+) This would match "Nick" or "Fred", and whichever one matched, the named pattern "name" would be set to it. The (?J) internal option setting changes the local PCRE_DUPNAMES option. Allow duplicate names for subpatterns. As of PHP 7.2.0 J is supported as modifier as well. ... |
|||
:
Нравится:
Не нравится:
|
|||
|
14.04.2020, 15:42
|
|||
---|---|---|---|
(php) Сферический конь в вакууме на регулярках (preg_match_all) |
|||
#18+
Может, кто проверит в php 7.2+ регулярное выражение из примера 4 в режиме PREG_PATTERN_ORDER : '/(?J)<(?<CHAR>\d+)>|<(?<CHAR>\w+)>/u' ... |
|||
:
Нравится:
Не нравится:
|
|||
|
14.04.2020, 16:53
|
|||
---|---|---|---|
(php) Сферический конь в вакууме на регулярках (preg_match_all) |
|||
#18+
Cyrax_02 Может, кто проверит в php 7.2+ регулярное выражение из примера 4 в режиме PREG_PATTERN_ORDER : '/(?J)<(?<CHAR>\d+)>|<(?<CHAR>\w+)>/u' PHP 7.3.16 (cli) и PHP 7.2.29 (cli) одинаково Код: php 1. 2. 3. 4.
Код: php 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30.
... |
|||
:
Нравится:
Не нравится:
|
|||
|
14.04.2020, 17:54
|
|||
---|---|---|---|
(php) Сферический конь в вакууме на регулярках (preg_match_all) |
|||
#18+
Плохи дела... Не исправили в 7.x . vkle , если не сложно, ещё одно регулярное выражение (здесь второй "CHAR" всегда пуст => перезаписывает/очищает объединённый "CHAR"): Код: php 1. 2. 3.
Код: php 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12.
P.S. А что, если поставить опцию (?J) в конец регулярного выражения в качестве модификатора: .../u J Не поможет? ... |
|||
:
Нравится:
Не нравится:
|
|||
|
14.04.2020, 20:03
|
|||
---|---|---|---|
(php) Сферический конь в вакууме на регулярках (preg_match_all) |
|||
#18+
Cyrax_02 Не исправили в 7.x . Cyrax_02 ещё одно регулярное выражение Cyrax_02 Не поможет? ... |
|||
:
Нравится:
Не нравится:
|
|||
|
14.04.2020, 21:22
|
|||
---|---|---|---|
(php) Сферический конь в вакууме на регулярках (preg_match_all) |
|||
#18+
авторА есть открытый багрипорт? Там, где проблема обозначена. Которую исправить надобно.Думал, иногда исправляют без багрепортов. На bugs.php.net таких багрепортов нет. И нафиг нужно. Работать нужно сейчас, а не через 10 лет. Регулярные выражения с одноимёнными подмасками переписал на условные подмаски с относительными ссылками. Короче получились и, скорее всего, работать станут быстрее, т.к. не содержат полных альтернатив (только частичные). P.S . Пример 3 на самом деле тоже глючный. Просто там пустой индексный карман оказался в самом конце, а последние пустые карманы, как известно, удаляются. Если бы там ещё карманы были, то он бы не был удалён и перезаписал (очистил) бы объединённый карман "CHAR" ... |
|||
:
Нравится:
Не нравится:
|
|||
|
23.04.2020, 14:38
|
|||
---|---|---|---|
(php) Сферический конь в вакууме на регулярках (preg_match_all) |
|||
#18+
Как оказалось, сабжевый багрепорт был (от 11 ферваля 2020 г.) Встроенный поиск на bugs.php.net и поиск Яндекса с задачей не справились. В php 7.4 проблема устранена: пустые вхождения больше не будут записываться в объединённый именной карман http://bugs.php.net/79257 Bug #79257: Duplicate named groups (?J) prefer last alternative even if not matched In 7.4 named capture group always returns the content captured in last alternative , no matter which of the alternatives matched. Looks like the actual problem existed in 7.3 and earlier , but it required slight modification to be reproduced. I'll try to update the bug report to take it into account. I've fixed this in PHP-7.4 . I don't want to fix this on 7.3. It's a long standing issue, and changes to PCRE matches output are risky. ... |
|||
:
Нравится:
Не нравится:
|
|||
|
|
start [/forum/topic.php?fid=23&mobile=1&tid=1459701]: |
0ms |
get settings: |
9ms |
get forum list: |
13ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
48ms |
get topic data: |
11ms |
get forum data: |
2ms |
get page messages: |
43ms |
get tp. blocked users: |
1ms |
others: | 14ms |
total: | 147ms |
0 / 0 |