Formulareingaben prüfen gehört zu den häufigsten Aufgaben in der Webentwicklung, und bei E-Mail, URL und Telefonnummer landet man schnell bei regulären Ausdrücken. Wann Regex wirklich das richtige Werkzeug ist und wann die eingebauten Filter die bessere Wahl sind, zeigt dieses Tutorial mit drei praxisnahen Patterns und den typischen Stolperfallen.
Wann lohnt sich Regex für Validierung?
Wer in PHP Formulare verarbeitet, kommt früher oder später zur Frage: Wie prüfe ich, ob die Eingabe wirklich eine E-Mail-Adresse, URL oder Telefonnummer ist? PHP regex email ist eine der am häufigsten gegoogelten Antworten zur Validierung, doch die ehrliche Antwort lautet: Für E-Mail-Adressen ist filter_var() heute der robustere Standard. Reguläre Ausdrücke spielen ihre Stärken erst dann aus, wenn es um eigene Formate wie deutsche Telefonnummern geht oder wenn aus einem Text alle URLs extrahiert werden sollen.
Bevor die drei Patterns folgen, ein kurzer Überblick, was dieses Tutorial abdeckt und wann Regex gegenüber filter_var() wirklich die bessere Wahl ist.
Dieses Tutorial zeigt drei pragmatische Patterns für E-Mail, URL und Telefonnummer, vergleicht sie mit den eingebauten filter_var-Filtern und gibt eine klare Empfehlung, welches Werkzeug wann das richtige ist. Bei der Prüfung des E-Mail-Formats lauern Stolperfallen wie das Pluszeichen im Local-Part oder IDN-Domains, die hier beleuchtet werden, damit am Ende keine gültigen Eingaben unfreiwillig abgelehnt werden.
Eine pragmatische PHP regex email Variante
Die wohl beliebteste Pattern-Variante deckt rund 95 Prozent der Fälle ab und ist gleichzeitig kurz genug, um sie zu verstehen. Sie lässt alphanumerische Zeichen, Punkte, Underscores, Pluszeichen und Bindestriche im Local-Part zu und erwartet nach dem @ einen Domainnamen mit mindestens einem Punkt.
<?php
$pattern = '/^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}$/';
$email = 'info@example.de';
if (preg_match($pattern, $email)) {
echo 'Gueltige E-Mail';
} else {
echo 'Ungueltige E-Mail';
}
Diese PHP regex email ist bewusst pragmatisch und kein RFC-konformer Vollparser. Sie schluckt einige sehr exotische, aber tatsächlich gültige Adressen nicht, etwa solche mit Anführungszeichen oder mit IP-Adresse als Domain. Für den Alltag reicht sie aber locker und ist gut nachvollziehbar. Wer mit dem Aufbau von Regex generell noch unsicher ist, findet in unserem PHP-Regex-Grundlagen-Tutorial die nötige Basis.
filter_var mit FILTER_VALIDATE_EMAIL als Alternative
Seit PHP 5.2 gibt es den eingebauten Filter FILTER_VALIDATE_EMAIL als Alternative zur Eigenbau-Regex. Er folgt RFC 822 deutlich exakter als die meisten Eigenbau-Patterns und ist in der Praxis die saubere Wahl für die E-Mail-Prüfung.
<?php
$email = 'info+sales@example.de';
if (filter_var($email, FILTER_VALIDATE_EMAIL)) {
echo 'Gueltige E-Mail';
} else {
echo 'Ungueltige E-Mail';
}
Der große Vorteil: filter_var() akzeptiert auch Spezialfälle wie info+sales@example.de oder Adressen mit Bindestrich in der Domain. Eine selbstgeschriebene Regex müsste alle diese Fälle einzeln abdecken und würde mit jeder Sonderregel komplexer. In unserer Eingabe-Filterung mit filter_var findet sich der gesamte Kontext der Filter-Familie.
Wo bleibt dann die Regex-Lösung? Sobald die Validierung über das hinausgeht, was die Filter abdecken, wird Regex unverzichtbar. Beispiele: Nur E-Mails einer bestimmten Domain zulassen, Pluszeichen-Aliase verbieten, oder Adressen aus einem Text extrahieren.
URLs validieren und aus Texten extrahieren
Bei URLs ist das Bild ähnlich wie bei E-Mail-Adressen. Der Filter FILTER_VALIDATE_URL ist genau und prüft auf wohlgeformte URIs, erwartet aber zwingend ein Schema. Eine Eingabe wie beispiel.de schlägt dort durch. Wer das auffangen will, ergänzt eine kurze Regex.
<?php
$url = 'https://www.beispiel.de/seite?id=42';
/* filter_var: erwartet Schema */
if (filter_var($url, FILTER_VALIDATE_URL)) {
echo 'Gueltige URL';
}
/* Regex: erlaubt URL ohne Schema */
$pattern = '#^(https?://)?([a-z0-9.-]+\.[a-z]{2,})(/[^\s]*)?$#i';
if (preg_match($pattern, 'beispiel.de/seite')) {
echo 'Gueltige URL';
}
Die zweite Variante akzeptiert auch URLs ohne http:// oder https://. In Anmeldeformularen für Webseiten ist das oft die nutzerfreundlichere Wahl, weil die Eingabe vor dem Speichern ohnehin normalisiert wird. Beim Speichern hängt das Skript dann automatisch ein https:// an, falls keines vorhanden ist.
Eine zweite häufige Aufgabe ist das Extrahieren mehrerer URLs aus einem Text. Hier ist Regex-Pattern-Matching unschlagbar, weil filter_var() nur einzelne Eingaben prüft. Mit preg_match_all lassen sich alle Treffer in einem Aufruf finden.
<?php
$text = 'Besuche https://example.de oder http://php-space.info fuer mehr Infos.';
preg_match_all('#https?://[^\s]+#', $text, $treffer);
print_r($treffer[0]);
/* Array mit beiden URLs */
Deutsche Telefonnummern per Pattern prüfen
Anders als E-Mails und URLs gibt es für Telefonnummern keine eingebaute PHP-Funktion, die wie filter_var arbeitet. Hier ist Regex die natürliche Wahl. Der Trick liegt darin, die typischen Präfixe abzudecken: international +49, alternativ 0049 oder die nationale Variante mit führender 0.
<?php
$mobil = '/^(\+49|0049|0)1[5-7][0-9]{8,9}$/';
$nummern = ['+491511234567', '01511234567', '00491511234567', '0123456'];
foreach ($nummern as $n) {
echo $n . ' -> ' . (preg_match($mobil, $n) ? 'OK' : 'NEIN') . "\n";
}
/* Die ersten drei OK, die vierte NEIN */
Die Regex deckt deutsche Mobilnummern ab, die mit der Vorwahl 015, 016 oder 017 beginnen. Festnetznummern haben dagegen sehr unterschiedliche Vorwahllängen (von 030 Berlin bis 04401 für Westerstede). Eine vollständige Festnetz-Regex sieht typischerweise so aus.
<?php
$festnetz = '/^(\+49|0049|0)[2-9][0-9]{1,4}[\s-]?[0-9]{3,12}$/';
$beispiele = ['030 12345678', '+49 30 12345678', '04401-987654'];
foreach ($beispiele as $b) {
echo $b . ' -> ' . (preg_match($festnetz, $b) ? 'OK' : 'NEIN') . "\n";
}
Die Regex erlaubt optional ein Leerzeichen oder einen Bindestrich als Trenner. Vor der eigentlichen Prüfung lohnt es sich, die Eingabe mit preg_replace('/\s+/', '', $eingabe) von Whitespace zu befreien, das macht die Regex einfacher und stabiler.
Internationale Telefonnummern und Normalisierung
Sobald internationale Daten ins Spiel kommen, wird Regex schnell unhandlich. Eine pragmatische Lösung ist das Normalisieren auf das +-Format vor der Prüfung. Aus 0049 151 1234567 und 0151 1234567 wird +491511234567. Anschließend genügt eine einfachere Pattern-Prüfung.
<?php
function normalisiereTelefon(string $nummer): string
{
$nur_zahlen = preg_replace('/[^0-9+]/', '', $nummer);
if (str_starts_with($nur_zahlen, '0049')) {
return '+49' . substr($nur_zahlen, 4);
}
if (str_starts_with($nur_zahlen, '0')) {
return '+49' . substr($nur_zahlen, 1);
}
return $nur_zahlen;
}
echo normalisiereTelefon('0151 12345678');
/* +4915112345678 */
Wer es ganz robust haben will, sollte für internationale Telefonnummern eine Bibliothek wie giggsey/libphonenumber-for-php nutzen. Das Paket portiert Googles Validierungs-Logik und kennt die Regeln von über 200 Ländern. Eine reine Telefon-Lösung mit eigenen Patterns reicht für den deutschen Markt aber meist aus.
flowchart TD
A[Eingabe pruefen] --> B{E-Mail oder URL?}
B -->|E-Mail| C[filter_var FILTER_VALIDATE_EMAIL]
B -->|URL| D[filter_var FILTER_VALIDATE_URL]
B -->|Telefon| E[preg_match mit Pattern]
C --> F{Gueltig?}
D --> F
E --> F
F -->|Ja| G[weiterverarbeiten]
F -->|Nein| H[Fehlermeldung]
Wichtige Modifier i, u und m
Am Ende einer Regex-Definition stehen oft Buchstaben wie i, u oder m. Diese Modifier verändern das Verhalten der Pattern.
| Modifier | Bedeutung | Beispiel |
|---|
i | case-insensitive (Groß- und Kleinschreibung egal) | /INFO/i matcht info |
u | UTF-8-Modus, nötig für Umlaute und Unicode | /\w+/u |
m | multiline, ^ und $ matchen Zeilenanfang/-ende | /^Fehler/m |
Wer ein Pattern auf Texte mit Umlauten oder Sonderzeichen anwendet, sollte konsequent den u-Modifier nutzen. Ohne ihn matcht \w (Wortzeichen) zwar die ASCII-Buchstaben von a bis z, aber keine Umlaute wie ö oder Zeichen aus anderen Alphabeten. Im Zweifel lieber u setzen, das schadet nicht.
Komplettes Form-Validation-Beispiel
Bei der Frage nach PHP regex email geht es in der Praxis meist nicht nur um das blanke Pattern, sondern um den kompletten POST-Workflow: Eingabe lesen, validieren, Fehler zurückspielen, gegebenenfalls weiterverarbeiten. Das folgende Snippet zeigt einen kompakten Server-side-Pfad mit Fehleranzeige im Formular.
<?php
$fehler = [];
$email = '';
if ($_SERVER['REQUEST_METHOD'] === 'POST') {
$email = trim((string) ($_POST['email'] ?? ''));
if ($email === '') {
$fehler['email'] = 'Bitte eine E-Mail-Adresse angeben.';
} elseif (!filter_var($email, FILTER_VALIDATE_EMAIL)) {
$fehler['email'] = 'Diese E-Mail-Adresse ist ungueltig.';
}
if ($fehler === []) {
/* hier weiterverarbeiten, z.B. in DB speichern */
echo 'Danke! Eingang fuer ' . htmlspecialchars($email);
exit;
}
}
?>
<form method="post">
<input type="email" name="email"
value="<?= htmlspecialchars($email) ?>">
<?php if (isset($fehler['email'])): ?>
<p class="is-invalid"><?= htmlspecialchars($fehler['email']) ?></p>
<?php endif; ?>
<button type="submit">Absenden</button>
</form>
Wichtig sind drei Dinge: htmlspecialchars() beim Zurückschreiben des Werts (sonst entsteht XSS), eine eigene Fehlerklasse pro Feld für CSS-Markierung und der Hinweis, dass die HTML5-Pflichtmarkierung required und der type="email" zwar im Browser helfen, aber niemals die Server-Validierung ersetzen. Manipulierte Requests umgehen jede client-seitige Prüfung. Erst die Server-Prüfung mit filter_var() oder Regex stoppt sie zuverlässig.
Disposable-Email-Adressen erkennen
Wegwerf-Mailadressen von Diensten wie 10minutemail oder mailinator helfen Spammern und Sockenpuppen. Wer ein Newsletter- oder Forum-Projekt betreibt, möchte solche Domains oft blockieren. Die einfachste Variante ist eine kleine Blacklist mit den bekanntesten Anbietern.
<?php
$disposable = [
'mailinator.com', 'tempmail.com', '10minutemail.com',
'guerrillamail.com', 'trashmail.com',
];
$email = 'user@mailinator.com';
$domain = strtolower(substr(strrchr($email, '@'), 1));
if (in_array($domain, $disposable, true)) {
echo 'Wegwerf-Adresse, bitte echte Adresse nutzen.';
}
Für den produktiven Einsatz lohnt sich eine gepflegte Liste, etwa aus dem Open-Source-Projekt disposable-email-domains. Statt die Liste hart in den Code zu schreiben, wird sie als JSON-Datei gepflegt und einmal pro Tag über einen Cronjob aktualisiert. Damit bleibt die Prüfung wartbar und die Falsch-Positiven gering.
Domain-spezifische Filterung mit Whitelist
Manchmal ist das Ziel umgekehrt: nur E-Mail-Adressen einer bestimmten Domain zulassen, etwa für ein Mitarbeiter-Tool oder ein Schul-Portal. Dafür reicht ein zusätzlicher Vergleich nach der Format-Prüfung.
<?php
$erlaubt = ['firma.de', 'firma-tochter.de'];
$email = 'mitarbeiter@firma.de';
$domain = strtolower(substr(strrchr($email, '@'), 1));
if (filter_var($email, FILTER_VALIDATE_EMAIL) && in_array($domain, $erlaubt, true)) {
echo 'Zugriff erlaubt';
} else {
echo 'Bitte eine Firmen-Adresse verwenden.';
}
Wer mehrteilige Top-Level-Domains wie .co.uk oder .com.au zulassen will, sollte die Domain mit strrchr extrahieren und nicht naiv per explode('.', $email). Sonst landen Subdomains in der falschen Schublade. Für mehrere hundert Domains lohnt sich ein array_flip() plus isset()-Check, der mit O(1) deutlich schneller ist als in_array() mit linearem Durchlauf.
Stolperfallen: Pluszeichen, IDN und zu strenge Patterns
Drei Punkte rund um Eigenbau-Patterns haben in der Praxis schon viele Stunden gekostet. Erstens: Das Pluszeichen + ist im Local-Part einer E-Mail erlaubt (RFC 5322). Adressen wie info+sales@example.com sind völlig gültig und werden von Google Mail, Outlook und vielen anderen Anbietern als Aliase verwendet. Eine Regex, die + nicht zulässt, schließt genau diese Nutzer aus.
Zweitens: IDN-Domains (Internationalized Domain Names) wie info@müller.de erscheinen mit Umlaut, werden im DNS aber als Punycode info@xn--mller-kva.de gespeichert. Wer solche Adressen prüfen will, muss vor der Regex mit idn_to_ascii() umwandeln oder den u-Modifier setzen und Umlaute im Pattern erlauben.
Drittens: Eine zu strenge Regex kostet Conversions. Wer sicher ist, dass filter_var() reicht, sollte es nutzen. Eine Eigenbau-Regex ist nur dann sinnvoll, wenn das Format wirklich vom Standard abweicht (etwa "nur E-Mails von firma.de zulassen") oder wenn Treffer aus einem Text extrahiert werden sollen.
Fazit zu PHP regex email
Für PHP regex email ist die ehrliche Antwort heute: Nutze filter_var(..., FILTER_VALIDATE_EMAIL), weil der Filter RFC-näher arbeitet als jede selbstgebaute Regex. Bei URLs ist FILTER_VALIDATE_URL der Standard, eine Regex hilft, wenn das Schema optional sein soll. Telefonnummern sind die Domäne der Regex, hier zählen pragmatische Patterns mit den deutschen Präfixen oder für internationale Fälle die libphonenumber-Bibliothek. Wer Patterns kurz hält, Modifier wie u bewusst setzt und auf typische Stolperfallen wie das Pluszeichen achtet, baut Form-Validierung, die zuverlässig funktioniert und keine gültigen Nutzer ausschließt.
