PHP ereg по сравнению с preg

preg - это Perl-совместимая библиотека Regex
ereg - это совместимая с POSIX библиотека регулярных выражений

. Они имеют немного другой синтаксис, а preg в некоторых случаях немного быстрее. ereg устарел (и он удален в php6), поэтому я бы не рекомендовал его использовать.

Что ж, ereg и его производные функции (ereg_match и т. Д.) Устарели в php5 и удаляются из php6, так что вам, вероятно, лучше использовать семейство preg.

preg - это для регулярных выражений в стиле Perl, а ereg - это стандартное регулярное выражение POSIX.

Существует много дискуссий о том, что быстрее и лучше.

Если вы планируете когда-нибудь перейти на PHP6, ваше решение принято. В противном случае:

По общему мнению, PCRE - лучшее решение, но если у вас есть конкретная страница с большим объемом трафика, и вам не нужен PHP6, возможно, стоит провести некоторое тестирование. Например, из комментариев руководства PHP:

Устарение регулярных выражений POSIX в PHP для Поиск Perl похож на замену деревянные доски и кирпич для дома со сборными комнатами и стенами. Конечно, вы сможете смешивать и сочетать некоторые части, но это много легче модифицировать со всеми частями выложенный перед вами.

PCRE быстрее, чем POSIX RE? Не всегда. В недавнем проекте поисковой системы здесь в Cynergi у меня был простой цикл с несколько симпатичных функций ereg_replace (), которые На обработку данных ушло 3 минуты. Я изменился этот 10-строчный цикл в 100-строчный рукописный код для замены и цикл теперь занимал 10 секунд, чтобы обработать те же данные! Это открыло мне глаза на то, что может В НЕКОТОРЫХ СЛУЧАЯХ работать очень медленно регулярные выражения. В последнее время я решил изучить Perl-совместимый обычный выражения (PCRE). Большинство страниц утверждают PCRE быстрее, чем POSIX, но некоторые заявить иначе. Я решил собственные марки. Мои первые несколько тесты подтвердили, что PCRE работает быстрее, но ... результаты были немного отличается от других, поэтому Я решил протестировать каждый случай Использование RE у меня было на 8000-строчном безопасном (и быстро) проект веб-почты здесь, на Синерги, чтобы проверить это. Результаты, достижения? Безрезультатно! Иногда PCRE - это быстрее (иногда в раз больше чем в 100 раз быстрее!), но некоторые другие раз POSIX RE быстрее (в раз из 2х). Мне все еще нужно найти правило когда один или другой быстрее. Это не только о размере данных поиска, количество совпавших данных, или "RE время компиляции ", которое покажет когда вы часто повторяете функцию: всегда будет быстрее, чем Другой. Но я не нашел закономерности Вот. Но по правде говоря, я тоже не найдите время, чтобы изучить источник кодировать и анализировать проблему. Я могу тем не менее, приведу несколько примеров. В POSIX RE ([0-9] {4}) / ([0-9] {2}) / ([0-9] {2}) [^ 0-9] + ([0-9] {2}): ([0-9] {2}): ([0-9] {2}) - это На 30% быстрее в POSIX, чем когда преобразован в PCRE (даже если вы используете \ d и \ D и нежадное сопоставление). На с другой стороны, аналогичный PCRE сложный узор / [0-9] {1,2} [ \ t] + [a-zA-Z] {3} [\ t] + [0-9] {4} [ \ t] + [0-9] {1,2}: [0-9] {1,2} (: [0-9] {1,2})? [ \ t] + [+ -] [0-9] {4} / в 2,5 раза быстрее в PCRE, чем в POSIX RE. просто шаблоны замены, такие как ereg_replace ("[^ a-zA-Z0-9 -] +", "", $ m ); в POSIX RE в 2 раза быстрее, чем PCRE. А потом мы снова запутаемся потому что шаблон POSIX RE вроде (^ | \ n | \ r) begin-base64 [\ t] + [0-7] {3,4} [ \ t] + ...... в 2 раза быстрее, чем POSIX RE, но регистронезависимый PCRE / ^ Получено [\ t] *: [\ t] от [\ t] + ([^ \ t] +) [\ t] / i в 30 раз быстрее, чем его Версия POSIX RE! Когда дело доходит до чувствительность к регистру, PCRE пока показался лучшим вариантом. Но я обнаружил действительно странное поведение от эрег / эреги. На очень простом Mime-версия POSIX RE (^ | \ r | \ n) [\ t] : Я обнаружил, что eregi () принимает 3,60 с (просто число в тестовом тесте), а соответствующий PCRE занял 0,16 секунды! Но если Я использовал ereg () (с учетом регистра) Время POSIX RE сократилось до 0,08 с! Так что я исследовали дальше. Я пытался сделать сам POSIX RE нечувствителен к регистру. Я дошел до этого: (^ | \ r | \ n) [mM] [iI] [mM] [eE] -vers [iI] [oO] [nN] [ \ t] *: Эта версия также заняла 0,08 с. Но если я попытаюсь применить то же правило к любой из 'v', 'e', ​​'r' или 's' буквы, которые не меняются, время вернулся к отметке 3,60 с, а не постепенно, но сразу! В в тестовых данных не было "vers" в это, другие "мимические" слова в нем или любые "ion", который может сбивать с толку Парсер POSIX, так что я в растерянности. Дно строка: всегда проверяйте свой PCRE / POSIX RE, чтобы найти самый быстрый! Тесты были выполнены с PHP 5.1.2 под Windows из командной строки. Педро Freire cynergi.com