pcntl_wtermsig
I have written a short introduction and a colorful cheat sheet for Perl Compatible Regular Expressions (PCRE):
http://www.bitcetera.com/en/techblog/2008/04/01/regex-in-a-nutshell/
CXVIII. Reguläre Ausdrücke Funktionen (Perl-kompatibel)
Einführung
Die Syntax für Suchmuster, die in diesen Funktionen verwendet werden, ist Perl sehr ähnlich. Der Ausdruck muss von Begrenzungszeichen, z.B. von Schrägstrichen (/), umgeben sein. Jedes Zeichen kann als Begrenzungszeichen verwendet werden, solange es kein alphanumerisches Zeichen oder der Backslash (\) ist. Falls das Begrenzungszeichen im Ausdruck selbst verwendet wird, muss es mit dem Backslash als Escape-Zeichen maskiert werden. Seit PHP 4.0.4 können Sie auch dem Perl-Stil entsprechend (), {}, [] und <> als Begrenzung für Suchmuster verwenden. Für eine ausführliche Erklärung siehe Suchmuster-Syntax.
An die Schlussbegrenzung können verschiedene Modifikatoren angehängt werden, die das Suchergebnis beeinflussen. Siehe Modifikatoren für Suchmuster.
Bei Verwendung der POSIX-erweiterten Reguläre Ausdrücke Funktionen unterstützt PHP auch reguläre Ausdrücke mit POSIX-erweiterter Syntax.
Anmerkung: Diese Erweiterung unterhält pro Thread einen globalen Cache mit compilierten regulären Ausdrücken (bis zu 4096).
| Warnung |
| Sie sollten sich über ein paar Einschränkungen von PCRE bewusst sein. Lesen Sie bitte » http://www.pcre.org/pcre.txt für weitere Informationen. |
Anforderungen
Diese Erweiterung benötigt keine externen Bibliotheken.
Installation
Ab PHP 4.2.0 sind diese Funktionen standardmäßig aktiviert. Sie können die pcre-Funktionen mit --without-pcre-regex deaktivieren. Falls Sie nicht die mitgelieferte Bibliothek benutzen, geben Sie mit --with-pcre-regex=VERZEICHNIS an, in welchem Verzeichnis die Include- und Bibliotheks-Dateien von PCRE liegen. Bei älteren PHP-Versionen müssen Sie diese mit --with-pcre-regex[=VERZEICHNIS] konfigurieren und übersetzen, um diese Funktionen benutzen zu können.
Die Windowsversion von PHP enthält diese Erweiterung. Um diese Funktionen zu verwenden, müssen Sie keine zusätzlichen Erweiterungen aktivieren.
Laufzeit Konfiguration
Das Verhalten dieser Funktionen wird durch Einstellungen in der php.ini beeinflusst.
Tabelle 202. PCRE Configuration Options
| Name | Default | Changeable | Changelog |
|---|---|---|---|
| pcre.backtrack_limit | 100000 | PHP_INI_ALL | Available since PHP 5.2.0. |
| pcre.recursion_limit | 100000 | PHP_INI_ALL | Available since PHP 5.2.0. |
Weitere Details und die Definitionen der PHP_INI_*-Konstanten finden Sie im Anhang G, php.ini Einstellungen.
Hier eine kurze Erklärung der Konfigurationsoptionen:
- pcre.backtrack_limit integer
PCRE's backtracking limit.
- pcre.recursion_limit integer
PCRE's recursion limit. Please note that if you set this value to a high number you may consume all the available process stack and eventually crash PHP (due to reaching the stack size limit imposed by the Operating System).
Resource Typen
Diese Erweiterung definiert keine Resource-Typen.
Vordefinierte Konstanten
Folgende Konstanten werden von dieser Erweiterung definiert und stehen nur zur Verfügung, wenn die Erweiterung entweder statisch in PHP kompiliert oder dynamisch zur Laufzeit geladen wurde.
Tabelle 203. PREG-Konstanten
| Konstante | Beschreibung |
|---|---|
| PREG_PATTERN_ORDER | Sortiert die Ergebnisse so, dass $matches[0] ein Array von Übereinstimmungen mit dem ganzen Suchmuster ist, $matches[1] ein Array von Zeichenketten, die mit dem ersten geklammerten Teil-Suchmuster übereinstimmen und so weiter. Dieses Flag wird nur bei preg_match_all() verwendet. |
| PREG_SET_ORDER | Sortiert die Ergebnisse so, dass $matches[0] ein Array des ersten Satzes von Übereinstimmungen ist, $matches[1] ein Array des zweiten Satzes von Übereinstimmungen und so weiter. Dieses Flag wird nur bei preg_match_all() verwendet. |
| PREG_OFFSET_CAPTURE | Siehe Beschreibung von PREG_SPLIT_OFFSET_CAPTURE. Dieses Flag steht seit PHP 4.3.0 zur Verfügung. |
| PREG_SPLIT_NO_EMPTY | Dieses Flag teilt der Funktion preg_split() mit, dass sie nur nicht-leere Teile zurückgeben soll. |
| PREG_SPLIT_DELIM_CAPTURE | Dieses Flag teilt der Funktion preg_split() mit, dass sie auch die eingeklammerten Ausdrücke des Trennsymbol-Musters zurückgeben soll. Dieses Flag steht seit PHP 4.0.5 zur Verfügung. |
| PREG_SPLIT_OFFSET_CAPTURE | Wenn dieses Flag gesetzt ist, wird für jede gefundene Übereinstimmung auch der dazugehörige Versatz zurückgegeben. Beachten Sie, dass dies die Rückgabewerte in einem Array dahingehend ändert, dass jedes Element ein Array ist, das aus der übereinstimmenden Zeichenkette als erstem und deren Stelle im durchsuchten Text als zweitem Element besteht. Dieses Flag steht seit PHP 4.3.0 zur Verfügung und wird nur bei preg_split() verwendet. |
| PREG_NO_ERROR | Dieses Flag wird von preg_last_error() zurückgegeben, falls kein Fehler aufgetreten ist. Es steht seit PHP 5.2.0 zur Verfügung. |
| PREG_INTERNAL_ERROR | Dieses Flag wird von preg_last_error() zurückgegeben, falls ein interner PCRE-Fehler aufgetreten ist. Es steht seit PHP 5.2.0 zur Verfügung. |
| PREG_BACKTRACK_LIMIT_ERROR | Dieses Flag wird von preg_last_error() zurückgegeben, falls das Limit der Zurückverfolgung (Backtracking) überschritten wurde. Es steht seit PHP 5.2.0 zur Verfügung. |
| PREG_RECURSION_LIMIT_ERROR | Dieses Flag wird von preg_last_error() zurückgegeben, falls das Rekursionslimit überschritten wurde. Es steht seit PHP 5.2.0 zur Verfügung. |
| PREG_BAD_UTF8_ERROR | Dieses Flag wird von preg_last_error() zurückgegeben, falls der letzte Fehler durch fehlerhafte UTF8-Daten verursacht wurde (nur bei RegEx, die im UTF-8-Modus laufen). Es steht seit PHP 5.2.0 zur Verfügung. |
Beispiele
Beispiel 1432. Beispiele ungültiger Suchmuster
- /href='(.*)' - fehlender Begrenzer am Ende
- /\w+\s*\w+/J - ungültiger Modifikator 'J'
- 1-\d3-\d3-\d4| - fehlender Begrenzer am Anfang
Inhaltsverzeichnis
- Suchmuster-Modifikatoren — Beschreibt mögliche Modifikatoren in Regex-Suchmustern
- Pattern Syntax — Describes PCRE regex syntax
- preg_grep — Liefert die mit einem Suchmuster übereinstimmenden Array-Elemente
- preg_last_error — Liefert den Fehlercode der letzten PCRE RegEx-Auswertung
- preg_match_all — Führt eine umfassende Suche nach Übereinstimmungen mit regulärem Ausdruck durch
- preg_match — Führt eine Suche mit einem regulären Ausdruck durch
- preg_quote — Maskiert Zeichen regulärer Ausdrücke
- preg_replace_callback — Sucht und ersetzt einen regulären Ausdruck unter Verwendung eines Callbacks
- preg_replace — Sucht und ersetzt einen regulären Ausdruck
- preg_split — Zerlegt eine Zeichenkette anhand eines regulären Ausdrucks
add a note
User Contributed Notes
Reguläre Ausdrücke Funktionen (Perl-kompatibel)
Svoop
10-Feb-2009 05:43
stronk7 at moodle dot org
13-Sep-2007 01:42
One comment about 5.2.x and the pcre.backtrack_limit:
Note that this setting wasn't present under previous PHP releases and the behaviour (or limit) under those releases was, in practise, higher so all these PCRE functions were able to "capture" longer strings.
With the arrival of the setting, defaulting to 100000 (less than 100K), you won't be able to match/capture strings over that size using, for example "ungreedy" modifiers.
So, in a lot of situations, you'll need to raise that (very small IMO) limit.
The worst part is that PHP simply won't match/capture those strings over pcre.backtrack_limit and will it be 100% silent about that (I think that throwing some NOTICE/WARNING if raised could help a lot to developers).
There is a lot of people suffering this changed behaviour from I've read on forums, bugs and so on).
Hope this note helps, ciao :-)
misc at e2007 dot cynergi dot com
05-May-2007 04:16
PCRE faster than POSIX RE? Not always.
In a recent search-engine project here at Cynergi, I had a simple loop with a few cute ereg_replace() functions that took 3min to process data. I changed that 10-line loop into a 100-line hand-written code for replacement and the loop now took 10s to process the same data! This opened my eye to what can *IN SOME CASES* be very slow regular expressions.
Lately I decided to look into Perl-compatible regular expressions (PCRE). Most pages claim PCRE are faster than POSIX, but a few claim otherwise. I decided on bechmarks of my own.
My first few tests confirmed PCRE to be faster, but... the results were slightly different than others were getting, so I decided to benchmark every case of RE usage I had on a 8000-line secure (and fast) Webmail project here at Cynergi to check it out.
The results? Inconclusive! Sometimes PCRE *are* faster (sometimes by a factor greater than 100x faster!), but some other times POSIX RE are faster (by a factor of 2x).
I still have to find a rule on when are one or the other faster. It's not only about search data size, amount of data matched, or "RE compilation time" which would show when you repeated the function often: one would *always* be faster than the other. But I didn't find a pattern here. But truth be said, I also didn't take the time to look into the source code and analyse the problem.
I can give you some examples, though. The POSIX RE
([0-9]{4})/([0-9]{2})/([0-9]{2})[^0-9]+
([0-9]{2}):([0-9]{2}):([0-9]{2})
is 30% faster in POSIX than when converted to PCRE (even if you use \d and \D and non-greedy matching). On the other hand, a similarly PCRE complex pattern
/[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}/
is 2.5x faster in PCRE than in POSIX RE. Simple replacement patterns like
ereg_replace( "[^a-zA-Z0-9-]+", "", $m );
are 2x faster in POSIX RE than PCRE. And then we get confused again because a POSIX RE pattern like
(^|\n|\r)begin-base64[ \t]+[0-7]{3,4}[ \t]+......
is 2x faster as POSIX RE, but the case-insensitive PCRE
/^Received[ \t]*:[ \t]*by[ \t]+([^ \t]+)[ \t]/i
is 30x faster than its POSIX RE version!
When it comes to case sensitivity, PCRE has so far seemed to be the best option. But I found some really strange behaviour from ereg/eregi. On a very simple POSIX RE
(^|\r|\n)mime-version[ \t]*:
I found eregi() taking 3.60s (just a number in a test benchmark), while the corresponding PCRE took 0.16s! But if I used ereg() (case-sensitive) the POSIX RE time went down to 0.08s! So I investigated further. I tried to make the POSIX RE case-insensitive itself. I got as far as this:
(^|\r|\n)[mM][iI][mM][eE]-vers[iI][oO][nN][ \t]*:
This version also took 0.08s. But if I try to apply the same rule to any of the 'v', 'e', 'r' or 's' letters that are not changed, the time is back to the 3.60s mark, and not gradually, but immediatelly so! The test data didn't have any "vers" in it, other "mime" words in it or any "ion" that might be confusing the POSIX parser, so I'm at a loss.
Bottom line: always benchmark your PCRE / POSIX RE to find the fastest!
Tests were performed with PHP 5.1.2 under Windows, from the command line.
Pedro Freire
cynergi.com
richardh at phpguru dot org
22-Sep-2005 11:50
There's a printable PDF PCRE cheat sheet available here:
http://www.phpguru.org/article.php?ne_id=67
Has the common metacharacters, quantifiers, pattern modifiers, character classes and assertions with short explanations.
Ned Baldessin
23-Oct-2004 06:08
If you want to perform regular expressions on Unicode strings, the PCRE functions will NOT be of any help. You need to use the Multibyte extension : mb_ereg(), mb_eregi(), pb_ereg_replace() and so on. When doing so, be carefull to set the default text encoding to the same encoding used by the text you are searching and replacing in. You can do that with the mb_regex_encoding() function. You will probably also want to set the default encoding for the other mb_* string functions with mb_internal_encoding().
So when dealing with, say, french text, I start with these :
<?php
mb_internal_encoding('UTF-8');
mb_regex_encoding('UTF-8');
setlocale(LC_ALL, 'fr-fr');
?>
steve at stevedix dot de
20-Jul-2004 05:17
Something to bear in mind is that regex is actually a declarative programming language like prolog : your regex is a set of rules which the regex interpreter tries to match against a string. During this matching, the interpreter will assume certain things, and continue assuming them until it comes up against a failure to match, which then causes it to backtrack. Regex assumes "greedy matching" unless explicitly told not to, which can cause a lot of backtracking. A general rule of thumb is that the more backtracking, the slower the matching process.
It is therefore vital, if you are trying to optimise your program to run quickly (and if you can't do without regex), to optimise your regexes to match quickly.
I recommend the use of a tool such as "The Regex Coach" to debug your regex strings.
http://weitz.de/files/regex-coach.exe (Windows installer) http://weitz.de/files/regex-coach.tgz (Linux tar archive)
Biju
20-Sep-2003 09:00
Regular Expressions Tutorial from non PHP sites
http://www.amk.ca/python/howto/regex/
http://sitescooper.org/tao_regexps.html
http://www.english.uga.edu/humcomp/perl/regex2a.html
http://www.english.uga.edu/humcomp/perl/regexps.html
http://www.english.uga.edu/humcomp/perl/regular_expressions.HTML
http://www.english.uga.edu/humcomp/perl/
http://java.sun.com/docs/books/tutorial/extra/regex/
http://gnosis.cx/publish/programming/regular_expressions.html
http://www.zvon.org/other/PerlTutorial/Books/Book1/
http://it.metr.ou.edu/regex/
http://www.regular-expressions.info/