PHP ereg против preg

Ответ 1

Посещение php.net/ereg отображает следующее:

Предупреждение

Эта функция была DEPRECATED с PHP 5.3.0 и удалена с PHP 6.0.0. Опираясь на эту особенность, очень не рекомендуется.

Вниз по странице немного дальше, и мы читаем следующее:

Примечание. preg_match(), который использует синтаксис регулярных выражений, совместимый с Perl, часто является более быстрой альтернативой ereg().

Обратите внимание на мой акцент.

Ответ 2

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

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

Ответ 3

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

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

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

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

PCRE быстрее, чем POSIX RE? Не всегда. В недавнем проекте поисковой системы здесь в Cynergi у меня была простая петля с несколько симпатичных функций ereg_replace(), которые для обработки данных потребовалось 3 мин. Я изменился что 10-строчный цикл в 100-строчный рукописный код для замены и цикл теперь занял 10 секунд для обработки одинаковые данные! Это открыло мне глаза на то, что может В НЕКОТОРЫХ СЛУЧАЕ быть очень медленным обычные выражения. В последнее время я решил просматривать Perl-совместимые регулярные выражения (PCRE). Большинство страниц требуют PCRE быстрее, чем POSIX, но несколько заявить иначе. Я решил мои собственные страхи. Мои первые несколько тесты подтвердили, что PCRE будет быстрее, но... результаты были немного другие, чем другие, Я решил сравнить каждый случай Использование RE я имел на защищенной 8000 строк (и быстрый) проект Webmail здесь Cynergi, чтобы проверить это. Результаты? Неопределенный! Иногда PCRE быстрее (иногда в большей степени чем в 100 раз быстрее!), но некоторые другие раз POSIX RE быстрее (в от 2x). Мне все еще нужно найти правило о когда они быстрее или быстрее. Это не только размер данных поиска, количество согласованных данных или "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} [ \ Т] + [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 до сих пор казалось лучшим вариантом. Но я нашел действительно странное поведение от ereg/eregi. На очень простой POSIX RE (^ |\r |\n) mime-version [\ t]: Я нашел eregi(), беру 3,60s (просто число в тестовом контрольном показателе), в то время как соответствующий PCRE взял 0,16 с! Но если Я использовал ereg() (с учетом регистра) Время POSIX RE сократилось до 0.08s! Так что я исследовали далее. Я попытался сделать сам регистр POSIX RE. Я дошел до этого: (^ |\Г |\п) [мМ] [Ii] [мМ] [еЕ] -vers [Ii] [Oo] [NN] [ \ t] *: Эта версия также заняла 0.08s. Но если я попытаюсь применить одно и то же правило к любой из" v "," e "," r "или" s ", буквы, которые не изменены, время возвращается к отметке 3.60s, а не постепенно, но сразу же! в тестовых данных не было это, другие" мим "слова в нем или любые" иона", который может ввести в заблуждение POSIX парсер, поэтому я в недоумении. Дно line: всегда проверяйте свой PCRE/ POSIX RE, чтобы найти самый быстрый! тесты были выполнены с использованием PHP 5.1.2 под Windows, из командной строки. Pedro Freire cynergi.com

Ответ 4

Несмотря на то, что ereg устарел в PHP 5.3, функции mb_ereg * не являются. Я считаю, что основной причиной этого является то, что PHP6 восстанавливает всю поддержку MB/Unicode, и поэтому старые "обычные" методы ereg бесполезны, поскольку mb_ereg будет более новым/лучшим.

Я знаю, что он не отвечает на вопрос о скорости, но это позволяет вам продолжать использовать как POSIX, так и PCRE.

Ответ 5

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

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