PHP ereg vs. preg

Question

He notado en la biblioteca de expresiones regulares de PHP que hay una opción entre ereg y preg. ¿Cuál es la diferencia? ¿Es uno más rápido que el otro? De ser así, ¿por qué no se desaprobaba el más lento?

¿Hay alguna situación en la que sea mejor usar una sobre otra?

Answer 1

Visitar php.net/ereg muestra lo siguiente:

Advertencia

Esta función ha sido DEPRECATED a partir de PHP 5.3.0 y se retira a partir de PHP 6.0.0. Confiar en esta característica es altamente desaconsejado.

Abajo de la página un poco más allá y leemos esto:

Nota: preg_match(), que utiliza una sintaxis de expresiones regulares compatibles con Perl, es menudo una alternativa más rápida a ereg() .

Nota mi énfasis.

Answer 2

preg es la biblioteca de expresiones regulares de Perl Compatible
ereg es la biblioteca de expresiones regulares POSIX complient

Tienen una sintaxis ligeramente diversa y preg es en algunos casos un poco más rápido. ereg está en desuso (y se elimina en php6) por lo que no recomendaría que se use.

Answer 3

Bueno, ereg y sus funciones derivadas (ereg_match, etc.) están en desuso en php5 y se eliminan en php6, por lo que es mejor que vayas con la familia de preg.

preg es para las expresiones regulares de estilo Perl, mientras que ereg es estándar de POSIX regex.

Answer 4

Hay mucha discusión sobre cuál es más rápido y mejor.

Si planea algún día avanzar a PHP6, se tomará una decisión. De lo contrario:

El consenso general es que PCRE es la mejor solución, pero si tiene una página específica con mucho tráfico y no necesita PHP6, puede valer la pena realizar algunas pruebas. Por ejemplo, a partir de los comentarios Manual de PHP:

deprecating POSIX expresiones regulares en PHP para búsqueda Perl es como la sustitución de tablas de madera y ladrillo de una casa con habitaciones y paredes prefabricadas. Claro, es posible que pueda mezclar y combinar algunas de las partes, pero es mucho más fácil de modificar con todas las piezas dispuestas delante de usted.

PCRE más rápido que POSIX RE? No siempre. En un reciente proyecto de motor de búsqueda aquí en Cynergi, tenía un bucle simple con pocas funciones ereg_replace() que tardaron 3 minutos en procesar los datos.Cambié ese bucle de 10 líneas en un código escrito a mano de 100 líneas para el reemplazo y ¡El bucle ahora tardó 10 segundos en procesar los mismos datos de ! Esto me abrió los ojos a lo que puede EN ALGUNOS CASOS sea muy lento expresiones regulares. Últimamente decidí buscar expresiones compatibles con Perl (PCRE). La mayoría de las páginas reclaman PCRE son más rápidas que POSIX, pero algunas afirman lo contrario. Me decidí por las marcas de propias. Mis primeras pruebas confirmaron PCRE a ser más rápido, pero ... los resultados fueron ligeramente diferente a los demás estaban recibiendo, por lo que decidí referencia todos los casos de uso RE que tenía en una línea segura 8000- (y rápido) Proyecto webmail aquí en Cynergi para verificarlo. ¿Los resultados? ¡Inconclusivo! A veces PCRE es más rápido (a veces por un factor mayor que 100 veces más rápido!), Pero algunos otros veces POSIX RE son más rápidos (por un factor de 2x). Todavía tengo que encontrar una regla en cuando uno u otro es más rápido. Es no sólo por el tamaño de búsqueda de datos, cantidad de datos emparejados, o "RE tiempo de compilación" que mostraría cuando se repite la función de frecuencia: uno siempre será más rápido que el otro . Pero no encontré un patrón aquí. Pero a decir verdad, tampoco lo hice tómese el tiempo para buscar en el código fuente y analizar el problema. Puedo darle algunos ejemplos, sin embargo. El POSIX RE ([0-9] {4})/([0-9] {2})/([0-9] {2}) [^ 0-9] + ([0-9 ] {2}): ([0-9] {2}) es 30% más rápido en POSIX que cuando se convirtió a PCRE (incluso si usa \ d y \ D y concordancia no codiciosa). En por otro lado, un patrón complejo similar 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}/es 2.5 veces más rápido en PCRE que en POSIX RE. Patrones de reemplazo simples como ereg_replace ("[^ a-zA-Z0-9 -] +", "", $ m ); son 2 veces más rápidos en POSIX RE que PCRE. Y luego nos confundimos nuevamente porque un patrón POSIX RE como (^ | \ n | \ r) begin-base64 [\ t] + [0-7] {3,4} [ \ t] + ... ... es 2 veces más rápido que POSIX RE, , pero el PCRE /^ sensible a las mayúsculas y minúsculas ha recibido [\ t] *: [\ t] por [\ t] + ([^ \ t] +) [\ t ]/i es 30 veces más rápido que su versión POSIX RE! Cuando se trata de sensibilidad de la caja, PCRE hasta ahora parecía ser la mejor opción. Pero I encontró un comportamiento realmente extraño de ereg/eregi. En una muy simple POSIX RE (^ | \ r | \ n) mime-versión [\ t]: Encontré eregi() tomando 3.60s (solo un número en una prueba de referencia), mientras que el PCRE correspondiente tomó 0.16s! ¡Pero si utilicé ereg() (distingue entre mayúsculas y minúsculas), el tiempo POSIX RE bajó a 0.08s! Entonces investigué más . Traté de hacer el POSIX RE insensible a mayúsculas y minúsculas. Llegué tan lejos como este: (^ | \ r | \ n) [mM] [iI] [mM] [eE] -vers [iI] [oO] [nN] [ \ t] *: Esta versión también tomó 0.08s. Pero si trato de aplicar la misma regla a cualquiera de las letras 'v', 'e', ​​'r' o 's' que no han cambiado, el tiempo ha vuelto a la marca de los 3.60 y no gradualmente, ¡pero de inmediato! Los datos de prueba no tenían ningún "vers" en , ni otras palabras "mime" ni ningún "ion" que pudiera confundir el analizador POSIX , por lo que estoy perdido. Abajo línea: ¡siempre compare su PCRE/ POSIX RE para encontrar el más rápido! Las pruebas se realizaron con PHP 5.1.2 bajo Windows, desde la línea de comandos. Pedro Freire cynergi.com

Answer 5

Aunque ereg está en desuso en PHP 5.3, las funciones mb_ereg * no lo son. Creo que la razón principal de esto es porque PHP6 está reconstruyendo todo el soporte MB/Unicode y, por lo tanto, los antiguos métodos "regulares" de ereg son inútiles ya que mb_ereg será más nuevo/mejor.

Sé que no responde la pregunta sobre la velocidad, pero sí te permite continuar usando tanto POSIX como PCRE.