8
votes

Satisfait de la durée de vie d'EREG, migrant vers PREG

Je travaille sur une grande application PHP (> 1 million de lignes, 10 ans) qui fait une utilisation intensive de ereg et ereg_replace - actuellement 1 768 expressions régulières uniques en 516 classes.

Je suis très conscient Pourquoi EREG est obsolète mais migrant clairement vers PREG pourrait être très impliqué.

Est-ce que quelqu'un sait combien de temps ereg est susceptible d'être maintenu dans PHP, et / ou avoir des conseils pour migrer vers PREG sur cette échelle. Je soupçonne une traduction automatisée d'Ereg to freg est impossible / impraticable?


2 commentaires

EREG a été découragé depuis autour de PHP 4.1 - mais uniquement parce qu'il n'est pas aussi optimisé que les fonctions PCRE. Il n'est pas trop susceptible d'être supprimé de façon bientôt (pas avec le mythique PHP6 de toute façon), et même il serait simple d'écrire un wrapper de support de compatibilité d'exécution (que vous devriez faire pour tester). Vous devez énumérer quelques exemples pourquoi vous pensez que vos expressions étendues POSIX seraient incompatibles. Les différences sont rarement significatives.


Il existe des outils qui peuvent traduire de ereg à prg ; Regexbuddy par exemple et prend en charge COM Automation. En fonction de la complexité de vos regexes, et si vous avez besoin de migrer, cela pourrait être une option pertinente.


4 Réponses :


0
votes

Tous les fonctions EREG seront supprimées à partir de PHP 6, je crois.


0 commentaires

2
votes

Je ne suis pas sûr quand ereg code> sera supprimé mais mon pari est à partir de PHP 6.0.

Concern ce deuxième problème (traduire ereg code> sur sur vers PREG CODE>) Ne semble pas quelque chose qui est difficile, si votre demande a> 1 million de lignes, vous devez sûrement avoir les ressources nécessaires pour que quelqu'un effectue ce travail pendant au plus une semaine. Je goyai tous les ereg _ code> dans votre code et configurez des macros dans votre IDE préféré (des trucs simples comme Ajout de délimiteurs, modificateurs, etc.). P>

Je parie la plupart des Les 1768 regexes peuvent être portées à l'aide d'une macro, et les autres, bien, une bonne paire d'yeux. p>

Une autre option peut être d'écrire des emballages autour des fonctions ereg code> si elles sont Non disponible, implémentant Les modifications au besoin: P>

if (function_exists('ereg') !== true)
{
    function ereg($pattern, $string, &$regs)
    {
        return preg_match('~' . addcslashes($pattern, '~') . '~', $string, $regs);
    }
}

if (function_exists('eregi') !== true)
{
    function eregi($pattern, $string, &$regs)
    {
        return preg_match('~' . addcslashes($pattern, '~') . '~i', $string, $regs);
    }
}


4 commentaires

Plus évasif serait d'utiliser "\ 1" comme délimiteurs. Pourrait encore échouer, mais les autres délimiteurs typiques peuvent déjà être utilisés et préfixés sans inutilement avec les barres backslashes [\ - \ ~] + , donc addcslashes pourrait potentiellement défaire les échapper (oui, trop nombreux). - La fonction Wrapper est la seule approche sensée. Ajouterait plus de tests / d'avertissements et de l'exécuter à sec avec Runkit / Override_function dans l'affaire OPS.


+1 - Superbe réponse, merci (c'était ma première question Stackoverflow, et je suis déjà impressionné!)


@Mario: est \ 1 un délimiteur PCRE valide? Je ne savais pas ça! =) S'ils sont déjà échappés dans le contexte de ereg , échapper à nouveau aux tildes ne devraient pas avoir de mauvaises conséquences ... ou doit-il être addcslashes ($ motif, '\\ ~') ? Je suis vraiment mauvais quand il s'agit de s'échapper (ONU) des données échappées, il faut toujours tester ça d'innombrables fois!


@Oliver: Merci, j'espère que vous vous tenez! ;)



1
votes

J'ai eu ce problème sur une échelle beaucoup plus petite - une application plus comme 10 000 lignes. Dans tous les cas, tout ce que je dois faire était de passer à Preg_replace () et mettez des délimiteurs autour du motif de regex.

Quiconque devrait être capable de le faire - même un non programmeur peut recevoir une liste de noms de fichiers et de numéros de ligne.

Exécutez simplement vos tests pour surveiller les échecs pouvant être corrigés.

Les fonctions EREG seront supprimées de PHP6, par la manière - http://jero.net/articles/php6 < / a>.


0 commentaires

2
votes

1 commentaires

Merci - votre dernier lien était particulièrement intéressant. Nous faisons une utilisation intensive d'analyses multibyte / unicode et avons une tonne de classes utilitaires à la maison pour le soutenir. La promesse de soutien native dans PHP6 était extraite mais terrifiante pour nous!