Die PHP-Funktion ereg() galt lange Zeit als Standard für reguläre Ausdrücke, doch mit den modernen Anforderungen an Performance und Unicode-Kompatibilität ist sie inzwischen überholt.
I. Einleitung: Das Ende einer Ära – ereg() in PHP
Die Funktion ereg() gehörte über Jahre zum Werkzeugkasten vieler PHP-Entwickler. Sie erlaubte das Suchen in Zeichenketten mittels regulärer Ausdrücke im POSIX-Format. Doch diese Zeiten sind vorbei: Mit PHP 5.3 wurde ereg() als veraltet (deprecated) markiert und seit PHP 7.0 ist sie vollständig entfernt. Wer versucht, heutigen Code mit ereg() auszuführen, erhält sofort einen Fatal Error wie:
Fatal error: Uncaught Error: Call to undefined function ereg()
Warum ist dieser Artikel relevant?
Alte Projekte oder Scripte, die noch auf ereg(), eregi() oder ereg_replace() setzen, funktionieren mit modernen PHP-Versionen nicht mehr. Wer auf Wartbarkeit, Sicherheit und Performance Wert legt, kommt um ein Refactoring nicht herum.
Ausblick: Die Familie der preg_*-Funktionen auf Basis der leistungsstarken PCRE-Engine ist heute der Standard für reguläre Ausdrücke in PHP. Wie du bestehende ereg()-Skripte robust migrierst, zeigt dieser Artikel Schritt für Schritt.
II. Warum der Wechsel? Die Gründe für die Veraltung von ereg()
Gerade bei umfangreichen Datenverarbeitungen geraten die älteren RegEx-Funktionen schnell an ihre Leistungsgrenzen und bremsen das Skript aus.
Performance:
Die preg_*-Funktionen (PCRE) arbeiten meist deutlich schneller und effizienter als ihre alten POSIX-Pendants wie ereg() oder eregi().
Funktionsumfang:
Die PCRE-Syntax (Perl Compatible Regular Expressions) erlaubt komplexere Patterns – zum Beispiel Lookarounds, non-capturing groups und mehr. POSIX ist im Vergleich schlicht zu limitiert.
Wartbarkeit und Zukunftssicherheit:
Die Pflege alter Funktionen lohnt nicht. Der PHP-Kern konzentriert sich längst auf PCRE, Weiterentwicklungen finden nur dort statt.
Sicherheitsaspekte:
Nicht gepflegter Altcode ist potenziell riskant – besonders, wenn Regex-Muster fehlerhaft oder unsauber übernommen werden.
III. Der Nachfolger: Vorstellung von preg_match() und der PCRE-Engine
Mit preg_match() erhältst du Zugriff auf die leistungsstarke PCRE-Engine, die weit mehr RegEx-Funktionen und eine bessere Performance bietet als frühere Lösungen.
preg_match():
Mit dieser Funktion prüfst du, ob ein String einem PCRE-Muster entspricht. Die Syntax ist flexibel, die Performance hoch und die Engine zuverlässig binärsicher.
Die PCRE-Engine:
„Perl Compatible Regular Expressions“ ist der De-facto-Standard für reguläre Ausdrücke, nicht nur in PHP, sondern in vielen Programmiersprachen. Sie bietet ein sehr breites Featureset.
Vorteile der Verwendung von preg_match():
- Flexibilität durch PCRE-Syntax
- Zuverlässigkeit und Sicherheit auch bei Binärdaten
- Hohe Performance
- Viele Erweiterungen und Optionen (z.B. Modifiers)
IV. ereg() vs. preg_match(): Die entscheidenden Unterschiede im Detail
Die größte Umstellung betrifft die verwendete Syntax: Während ältere Funktionen POSIX-Reguläre Ausdrücke erwarten, nutzt preg_match() die flexiblere Perl-Syntax, was neue Ausdrucksmöglichkeiten eröffnet – aber auch Anpassung im Code erfordert.
A. Syntax der regulären Ausdrücke
- ereg(): POSIX Extended Regex (etwas weniger flexibel)
- preg_match(): PCRE-Syntax (mächtig, mehr Features)
B. Delimiter (Trennzeichen)
-
ereg(): Kein Delimiter nötig, Muster direkt als String
-
preg_match(): Delimiter zwingend (z.B. /pattern/, #pattern#)
- Delimiter im Pattern? Mit preg_quote() escapen
C. Case-Sensitivität
- ereg(): Häufig case-insensitiv interpretiert
- eregi(): Explizit case-insensitiv
- preg_match(): Standard: case-sensitiv, für insensitive Suche /i-Modifier verwenden
D. Rückgabewerte
- ereg(): Liefert die Länge des Treffers oder false
- preg_match(): 1 (Treffer), 0 (kein Treffer), false (Fehler)
Beide können ein Array mit Treffern liefern (siehe $regs bei ereg() und $matches bei preg_match()).
E. Behandlung von Binärdaten
- ereg(): Nicht binärsicher
- preg_match(): Binärsicher, auch für Unicode geeignet (/u-Modifier!)
F. Gierigkeit (Greediness)
- Standardmäßig greifen beide „gierig“, d.h. sie matchen so viel wie möglich. PCRE erlaubt durch ?-Modifier nicht-gierige Patterns (.*? statt .*).
G. Tabellarische Übersicht
Die Tabelle macht deutlich, dass moderne RegEx-Funktionen nicht nur mehr Möglichkeiten bieten, sondern auch an aktuelle PHP-Versionen und Unicode-Anforderungen angepasst sind.
| Kriterium | ereg()/eregi() | preg_match() |
| Engine | POSIX Regex | PCRE (Perl Compatible Regex) |
| Delimiter | Nein | Ja (z. B. /, #, ~) |
| Syntaxumfang | Eingeschränkt | Umfangreich |
| Case-sensitivity | ereg: ja/nein, eregi: nein | Standard: ja, Modifier: /i |
| Rückgabewerte | Länge/false | 1/0/false |
| Treffer-Array | Optional über dritten Parameter | Optional über dritten Parameter |
| Binärsicher | Nein | Ja |
| Verfügbar ab PHP-Version | < 7.0 | 4.x und aktueller |
| Status | Entfernt (ab 7.0) | Standard |
V. Praktische Migration: Von ereg() zu preg_match() (und anderen preg_* Funktionen)
Bei der Migration gilt es, nicht nur die Funktionsnamen zu ersetzen, sondern vor allem die Syntax der regulären Ausdrücke sowie die notwendige Angabe eines Delimiters im Muster zu berücksichtigen.
A. Grundlegende Konvertierung
1. ereg(“pattern”, $string)
/** Vorher (nicht mehr nutzbar) */
if (ereg("abc[0-9]+", $sText)) {
/** ... */
}
/** Nachher */
if (preg_match("/abc[0-9]+/", $sText)) {
/** ... */
}
2. eregi(“pattern”, $string)
/** Vorher */
if (eregi("abc[0-9]+", $sText)) {
/** ... */
}
/** Nachher */
if (preg_match("/abc[0-9]+/i", $sText)) {
/** ... */
}
3. Mit Treffer-Array (drittes Argument)
/** Vorher */
if (ereg("([a-z]+)([0-9]+)", $sText, $aTreffer)) {
/** $aTreffer[1], $aTreffer[2] */
}
/** Nachher */
if (preg_match("/([a-z]+)([0-9]+)/", $sText, $aTreffer)) {
/** $aTreffer[1], $aTreffer[2] */
}
B. Migration von ereg_replace() zu preg_replace()
/** Vorher */
$sNeu = ereg_replace("abc[0-9]+", "X", $sText);
/** Nachher */
$sNeu = preg_replace("/abc[0-9]+/", "X", $sText);
eregi_replace()
/** Vorher */
$sNeu = eregi_replace("abc[0-9]+", "X", $sText);
/** Nachher */
$sNeu = preg_replace("/abc[0-9]+/i", "X", $sText);
C. split() zu preg_split()
/** Vorher */
$aTeile = split(",", $sText);
/** Nachher */
$aTeile = preg_split("/,/", $sText);
D. Wichtige preg_match() Modifier
- /i – Case-insensitive (Groß/Kleinschreibung ignorieren)
- /u – Unicode/UTF-8 behandeln (besonders wichtig bei deutschen Umlauten!)
- /s – Punkt matcht auch Zeilenumbrüche
- /m – Multiline: ^ und $ matchen Zeilenanfang/-ende
E. Typische Fallstricke
- Delimiter vergessen
Fehler: preg_match("abc[0-9]+", $sText)
Korrekt: preg_match("/abc[0-9]+/", $sText) - Delimiter falsch gewählt
Wenn das Pattern selbst / enthält, nimm ein anderes Zeichen als Delimiter (z.B. #). - Modifier vergessen
Suchen mit Umlauten: immer /u ergänzen! - Unterschiedliche Rückgabewerte
ereg() liefert Länge/false, preg_match() liefert 1/0/false.
VI. Sonderfall: Multibyte-Strings und mb_ereg()
Wer heute Unicode-Zeichen sicher prüfen will, sollte konsequent preg_match() mit dem /u-Modifier einsetzen, da dies Multibyte-Zeichen vollständig unterstützt und zukunftssicher ist.
mb_ereg()
War Teil der Multibyte String Functions für UTF-8-Support bei POSIX-Regex, ist aber weitgehend durch PCRE mit /u abgelöst.
Empfehlung:
Setze auf preg_match() mit /u für Unicode/UTF-8.
VII. Code-Beispiele: Vorher/Nachher-Szenarien
Beim Prüfen von E-Mail-Adressen erkennt man die Vorteile des Umstiegs sofort: Die aktuelle Methode arbeitet genauer und lässt sich bei Bedarf leichter anpassen, was in der offiziellen Doku als eine Verbesserung der Version beschrieben wird.
Szenario 1: E-Mail-Prüfung
Vorher (ereg):
$sMail = "info@beispiel.de";
if (ereg("^[a-zA-Z0-9._%-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,4}$", $sMail)) {
/** Gültig */
}
Nachher (preg_match):
$sMail = "info@beispiel.de";
if (preg_match("/^[a-zA-Z0-9._%-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,4}$/", $sMail)) {
/** Gültig */
}
Alternativ empfiehlt es sich, die Filterfunktion mit einem Validierungsfilter zu verwenden.
Vorher:
$sPfad = "/var/www/html/index.php";
ereg("^/([^/]+)/([^/]+)/([^/]+)$", $sPfad, $aTeile);
/** $aTeile[1], $aTeile[2], $aTeile[3] */
Nachher:
$sPfad = "/var/www/html/index.php";
preg_match("|^/([^/]+)/([^/]+)/([^/]+)$|", $sPfad, $aTeile);
/** $aTeile[1], $aTeile[2], $aTeile[3] */
Szenario 3: Case-insensitive Ersetzung
Vorher:
$sText = "Hallo Welt!";
$sNeu = eregi_replace("welt", "Erde", $sText);
/* Ergebnis: "Hallo Erde!" */
Nachher:
$sText = "Hallo Welt!";
$sNeu = preg_replace("/welt/i", "Erde", $sText);
VIII. Fazit: Die Vorteile moderner Regulärer Ausdrücke in PHP nutzen
Es führt kein Weg daran vorbei: ereg() ist tot. Die Vorteile von PCRE sind zu groß, um sie zu ignorieren. Wer die Migration konsequent angeht, erhält nicht nur mehr Performance und Features, sondern macht seinen Code auch sicherer und zukunftsfähig.
- Leistungsstark: Umfangreiche Regex-Syntax
- Sicher: Binärsicher und Unicode-fähig
- Wartbar: Einfache, konsistente Anwendung in allen Projekten
nichts gefunden
Mein Tipp: Nutze die Gelegenheit, um bestehende Scripte von Grund auf zu prüfen und Fehlerquellen (z.B. veraltete Regex-Patterns) gleich mit zu beseitigen.
IX. FAQ (Häufig gestellte Fragen)
Ist ereg() wirklich komplett weg?
Ja, seit PHP 7.0 gibt es diese Funktion nicht mehr.
Was ist der schnellste Weg, meinen alten Code zu aktualisieren?
Systematisch jede ereg()-Zeile durch preg_match()/preg_replace() ersetzen, Syntax prüfen, mit Testdaten gegenchecken.
Macht preg_match() meinen Code langsamer/schneller?
preg_match() ist fast immer schneller und dabei deutlich mächtiger.
Wo finde ich mehr Infos zur PCRE-Syntax?
Die offizielle Doku und regex101.com sind ideale Startpunkte.
