Eingegebenen Text prüfen
snoot
Eingegebenen Text prüfen
snoot
suitHi,
ich möchte in einem Formular den Text auf Korrektheit prüfen. Für einzeilige Textfelder wie 'Name', 'E-Mail' oder 'Telefon' geht das ja noch ganz gut und man findet auch Beispiele im Netz, aber wie sieht es mit längerem Text aus?
Gibt es da eine gute Regex-Syntax/Funktion/o.ä. um den Text zu prüfen? Im Moment prüfe ich zumindest Buchstaben- und Wortanzahl. Aber das erkennt natürlich kein "gfgff ddgf fdhf dfjk hf asdf k fdjkadg afj ...". Da wäre es bspw. schon hilfreich die Anzahl _unterschiedlicher_ Zeichen zu zählen. Da fallen mir bisher aber nur sehr umständliche Wege via array_unique ein um doppelte Buchstaben zu entfernen und die verbleibenden, einmaligen Buchstaben zu zählen.
Vielleicht hat ja jemand eine gute Idee, wie oder was man generell noch prüfen könnte.
Danke
-
Hi!
Gibt es da eine gute Regex-Syntax/Funktion/o.ä. um den Text zu prüfen? Im Moment prüfe ich zumindest Buchstaben- und Wortanzahl. Aber das erkennt natürlich kein "gfgff ddgf fdhf dfjk hf asdf k fdjkadg afj ...". Da wäre es bspw. schon hilfreich die Anzahl _unterschiedlicher_ Zeichen zu zählen. Da fallen mir bisher aber nur sehr umständliche Wege via array_unique ein um doppelte Buchstaben zu entfernen und die verbleibenden, einmaligen Buchstaben zu zählen.
Egal welchen Aufwand du betreibst, es lässt sich immer etwas formulieren, das deine Prüfung durchlässt, aber ansonsten unsinnig oder ungewünscht ist. Andererseits gibt es sonnvolle Antworten, die vielleicht aber nach Meinung deiner Prüfung zu kurz sind, woraufhin die Anwender erfinderisch werden und erst recht sinnlose Sachen hinzufügen, um übers Limit zu kommen. Du musst also auf jeden Fall eine Prüfung durch ein intelligentes und der Sprache mächtiges Wesen implementieren.
Lo!
-
ich möchte in einem Formular den Text auf Korrektheit prüfen. Für einzeilige Textfelder wie 'Name'
Problematisch. Man kann einen Login-Usernamen beschränken, nicht aber Namen, die bereits real existierende Namen adequat abbilden sollen.
, 'E-Mail'
Auch hier ist eine Einschränkung mit vorsicht zu geniessen.
Insbesondere Annahmen bezäglich der TLD am Ende können Sorgen bereiten.oder 'Telefon'
Auch hier ist Vorsicht am Platz.
Es ist zu unterscheiden, die Liberalität einer Eingabe (Trennzeichen) und die kanonische Form bei der Anwendung einer Nummer.geht das ja noch ganz gut und man findet auch Beispiele im Netz, aber wie sieht es mit längerem Text aus?
Hier gilt die Regel, je restriktiver man verfährt, um so mehr Energie wird darauf verwendet, die Restriktion zu Umgehen. Dagegen gibt es kein Mittel.
Aus technischen gründen sehe ich hier lediglich eine Längenbegrenzung als sinnvoll.Gibt es da eine gute Regex-Syntax/Funktion/o.ä. um den Text zu prüfen? Im Moment prüfe ich zumindest Buchstaben- und Wortanzahl. Aber das erkennt natürlich kein "gfgff ddgf fdhf dfjk hf asdf k fdjkadg afj ...".
Warum willst du vermeiden, dass ich mit dir über Porn konversieren kann, oder andere kryptische Information?
Da wäre es bspw. schon hilfreich die Anzahl _unterschiedlicher_ Zeichen zu zählen. Da fallen mir bisher aber nur sehr umständliche Wege via array_unique ein um doppelte Buchstaben zu entfernen und die verbleibenden, einmaligen Buchstaben zu zählen.
Der Schuss in den eigenen Fuss ist Kür, nicht Pflicht.
mfg Beat
--
><o(((°> ><o(((°>
<°)))o>< ><o(((°>o
Der Valigator leibt diese Fische-
'Name'
Problematisch. Man kann einen Login-Usernamen beschränken, nicht aber Namen, die bereits real existierende Namen adequat abbilden sollen.
Ich kann bspw. Ziffern verbieten, 2 Worte verlangen (Vor + Nachname), min. 2 Zeichen ...
, 'E-Mail'
Auch hier ist eine Einschränkung mit vorsicht zu geniessen.
Insbesondere Annahmen bezäglich der TLD am Ende können Sorgen bereiten.TLD = 2-6 Zeichen, fertig. Man kann auch alle TLDs aufführen, so viele sinds auch wieder nicht. Auch alles davor kann man auch relativ bequem auf Richtigkeit prüfen. So ungefähr:
!eregi("^[_a-zÀ-Ýß?*-ý0-9-]+(\.[_a-zÀ-Ýß?*-ý0-9-]+)*@[a-zÀ-Ýß?*-ý0-9-]+(\.[a-zÀ-Ýß?*-ý0-9-]+)*(\.[a-z]{2,6})$", $email)oder 'Telefon'
Auch hier ist Vorsicht am Platz.
Es ist zu unterscheiden, die Liberalität einer Eingabe (Trennzeichen) und die kanonische Form bei der Anwendung einer Nummer.Auch hier kann ich zumindest die Stringlänge prüfen und Buchstaben verbieten
Warum willst du vermeiden, dass ich mit dir über Porn konversieren kann, oder andere kryptische Information?
Weil das nicht Thema der Webseite ist auf der man das Formular findet.
-
Ich kann bspw. Ziffern verbieten, 2 Worte verlangen (Vor + Nachname), min. 2 Zeichen ...
Worte mit \w - wohl eher mit \p{L}. Was ist dann mit Personen wie 宮本 茂?
Ich würde mich nicht darauf verlassen, dass es nicht auch Namen gibt, die nur aus einem Zeichen bestehen (in welcher Sprache auch immer).
!eregi("^[_a-zÀ-Ýß?*-ý0-9-]+(\.[_a-zÀ-Ýß?*-ý0-9-]+)*@[a-zÀ-Ýß?*-ý0-9-]+(\.[a-zÀ-Ýß?*-ý0-9-]+)*(\.[a-z]{2,6})$", $email)FAIL :D Ich könnte dir auf einen Schlag massenweise gültige Mail-Adressen nennen, die da durchfallen. Zudem verwendest du eine missbilligte ereg-Funktion.
Auch hier kann ich zumindest die Stringlänge prüfen und Buchstaben verbieten
Auf welche Stringlänge willst du prüfen? 3 Zeichen?
Warum Buchstaben? Es gibt genug sprechende Telefonnummern mit Buchstaben.
Weil das nicht Thema der Webseite ist auf der man das Formular findet.
"Porn" war ein Beispiel - nutze einen Algorithmus der die Plausibilität prüft - der bayessche Wahrscheinlichkeitsbegriff ist hierbei hilfreich. Da hat sich ein Mathematiker den Kopf zerbrochen, sein Lebenswerk sozusagen - ohne dich persönlich angreifen zu wollen: davon sind deine Überlegungen, egal wie lange du dein Hirn anstrengst, weit entfernt. Fertige Lösungen gibts genug SpamAssassin, Akismet usw.
-
Ich kann bspw. Ziffern verbieten, 2 Worte verlangen (Vor + Nachname), min. 2 Zeichen ...
Worte mit \w - wohl eher mit \p{L}. Was ist dann mit Personen wie 宮本 茂?
Ich prüfe nicht auf Buchstaben, sondern auf Ziffern.
!eregi("^[_a-zÀ-Ýß?*-ý0-9-]+(\.[_a-zÀ-Ýß?*-ý0-9-]+)*@[a-zÀ-Ýß?*-ý0-9-]+(\.[a-zÀ-Ýß?*-ý0-9-]+)*(\.[a-z]{2,6})$", $email)FAIL :D Ich könnte dir auf einen Schlag massenweise gültige Mail-Adressen nennen, die da durchfallen. Zudem verwendest du eine missbilligte ereg-Funktion.
Dann nenn mal bitte ein paar.
-
Ich prüfe nicht auf Buchstaben, sondern auf Ziffern.
Ich kann dir nicht folgen.
Dann nenn mal bitte ein paar.
Folgende werden ausgefiltert, sind syntaktisch aber völlig ok.
"foo bar"@example.com
foo@bar@example.com
$?^_`.!#{|}%&'*+-/=~@example.comFolgende geht durch, ist aber fehlerhaft (ok, da würde dir filter_var auch nicht helfen, da dort RFC 5321 (noch) ignoriert wird.
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa@example.com-
Folgende werden ausgefiltert, sind syntaktisch aber völlig ok.
"foo bar"@example.com
foo@bar@example.com
$?^_`.!#{|}%&'*+-/=~@example.comGanz ehrlich, wer so eine Adresse benutzt, hat es nicht anders verdient ;)
Zumal ich bezweifle, dass es einen E-Mail-Provider gibt, der sowas zulässt.
-
Ganz ehrlich, wer so eine Adresse benutzt, hat es nicht anders verdient ;)
Mit anderen Worten: du hast es also nicht anders verdient, dass du dir potentielle Kunden vergraulst.
Zumal ich bezweifle, dass es einen E-Mail-Provider gibt, der sowas zulässt.
Ich bezweifle, dass du dir im Klaren darüber bist, wieviele E-Mai-Provider da draußen in der Welt herumgondeln und welche Beschränkungen haben oder nicht. trash-mail.com hat z.B. kein Problem mit $?^_`.!#{|}%&'*+-/=~ als local-part.
Besonders die Ignoranz an deiner Einstellung schockiert mich. Frei interpretiert:
"Ich dreh' mein eigenes Ding und erfinde (kopiere) einen unübersichtlichen Ausdruck. Ungeachtet ob er standardkonform ist oder nicht verwende ich ihn, obwohl mich jemand darauf hingewiesen hat, dass es eine PHP-Funktion dafür gibt die absolut korrekt nach RFC 2821 bzw. 2822 arbeitet".
-
Ganz ehrlich, wer so eine Adresse benutzt, hat es nicht anders verdient ;)
Mit anderen Worten: du hast es also nicht anders verdient, dass du dir potentielle Kunden vergraulst.
Ich habe keine potentiellen Kunden.
Zumal ich bezweifle, dass es einen E-Mail-Provider gibt, der sowas zulässt.
Ich bezweifle, dass du dir im Klaren darüber bist, wieviele E-Mai-Provider da draußen in der Welt herumgondeln und welche Beschränkungen haben oder nicht. trash-mail.com hat z.B. kein Problem mit $?^_`.!#{|}%&'*+-/=~ als local-part.
Tja, schön für trash-mail. Das hilft mir als *Absender* nicht weiter wenn mein Provider so eine Adresse nicht akzeptiert. Selbst mein kostenpflichtiges E-Mail-Konto bei HostEurope erlaubt das nicht. Oder muss ich mir dann erst noch einen Provider suchen, bei dem solche Hieroglyphen erlaubt sind?
Ich ruf doch auch keine 0900er-Nummer zurück, nur weil jemand meint, dass wäre eine schicke Telefonnummer.
--> Wer mit mir in Kontakt treten will soll dafür sorgen, dass dies auch möglich ist.
-
Ich habe keine potentiellen Kunden.
Das ist schlecht fürs Geschäft.
Tja, schön für trash-mail.
Das war ein Beispiel, es gibt genügend andere.
Wie wärs mit franz+maria@example.com - wäre das so abwegig? oder maier&co@example.com
Das hilft mir als *Absender* nicht weiter wenn mein Provider so eine Adresse nicht akzeptiert. Selbst mein kostenpflichtiges E-Mail-Konto bei HostEurope erlaubt das nicht. Oder muss ich mir dann erst noch einen Provider suchen, bei dem solche Hieroglyphen erlaubt sind?
Hierogylphen sind das nicht - die finden sich in U+130000 aufwärts.
--> Wer mit mir in Kontakt treten will soll dafür sorgen, dass dies auch möglich ist.
Gut, dass du keine potentiellen Kunden hast.
-
--> Wer mit mir in Kontakt treten will soll dafür sorgen, dass dies auch möglich ist.
Gut, dass du keine potentiellen Kunden hast.
Was soll ich deiner Meinung nach tun, wenn ich auf so eine Adresse gar nicht antworten kann? Und ich bezweifle, dass die Mehrheit das könnte.
Wer sich so gut auskennt, dass er gezielt einen Provider findet, bei dem solche Adressen erlaubt sind, muss sich auch dessen bewusst sein, dass es damit zwangsläufig Probleme geben wird. Das brauchst du nicht mir in die Schuhe schieben.
Wenn du jemanden kennst, der so eine Adresse für seinen regelmäßigen Schriftverkehr benutzt, sag Bescheid.
-
Wer sich so gut auskennt, dass er gezielt einen Provider findet, bei dem solche Adressen erlaubt sind, muss sich auch dessen bewusst sein, dass es damit zwangsläufig Probleme geben wird.
Stimmt. Man wird zwangsläufig mit Seiten Probleme bekommen, die auf wild selbstgebaute (und letztlich sinnfreie) Regexe zur Validierung eingegebener E-Mail-Adressen setzen.
-
Stimmt. Man wird zwangsläufig mit Seiten Probleme bekommen, die auf wild selbstgebaute (und letztlich sinnfreie) Regexe zur Validierung eingegebener E-Mail-Adressen setzen.
Nein, man bekommt Probleme, weil quasi niemand auf so E-Mailadresse antworten kann.
<ironie>Eigentlich ist es ja sogar von Vorteil wenn ich ihn schon bei der Eingabe darauf hinweise, dass die E-Mail nicht akzeptiert wird. Eine Antwort würde er ja so oder so nicht erhalten können.</ironie>
Wie gesagt/gefragt: "Was soll ich [..] tun, wenn ich auf so eine Adresse gar nicht antworten kann?"
Wieso soll ich als Homepagebetreiber darauf achten, dass irgendein "Freak" mir mit seiner unseriösen E-Mailadresse eine Nachricht zukommen lassen kann? Vielleicht kommt auch ohne Regex die E-Mail nie bei mir an, weil mein Provider sie vorher schon ablehnt ohne, dass ich darauf reagieren kann?
Ich bleibe dabei: wer so fahrlässig handelt, muss mit Problemen rechnen, auf die ich als Empfänger gar keinen Einfluss habe. Da braucht mir auch niemand erzählen, dass man so einen bestimmten Nutzerkreis ausperrt; so jemand sperrt sich ja quasi selbst aus.
Ich wage auch zu behaupten, dass hier niemand bspw. ein Forum nennen kann, wo man sich mit so einer Adresse registrieren könnte. Sei es aus Unwissenheit der Seitenbetreiber (zugegeben, ich wusste auch nicht, dass diese Zeichen erlaubt sind), oder weil es beim Versand einfach irgendwo haken wird. Ebenso wäre ich an einem E-Mailprovider interessiert, der so eine E-Mailadresse als Empfänger akzeptiert.
-
Nein, man bekommt Probleme, weil quasi niemand auf so E-Mailadresse antworten kann.
Wie kommstn da drauf?
Wie gesagt/gefragt: "Was soll ich [..] tun, wenn ich auf so eine Adresse gar nicht antworten kann?"
Das wirst du sicher eh erst wissen, _nachdem_ du es probiert hast - und genau das ist der entscheidende Punkt, warum die Prüferei sinnfrei ist. Oder kannst du per regex prüfen, ob der User nen Vertipper produziert hat? angela.mekrel@example.com
Ich wage auch zu behaupten, dass hier niemand bspw. ein Forum nennen kann, wo man sich mit so einer Adresse registrieren könnte.
Twitter habe ich gerade mal mit suits Beispielen probiert. Alle akzeptiert! Die müssen ganz schön doof sein, wo es doch so einfach wäre, das mit nem supi Regexp zu verhindern ;-)
-
Nein, man bekommt Probleme, weil quasi niemand auf so E-Mailadresse antworten kann.
Wie kommstn da drauf?
Weil ich's bei gängigen Free-Emailprovidern (bspw. WEB.de, GMX, Googlemail, Arcor, Freenet, Yahoo) und wie gesagt meinem kostenpflichtigen Account probiert habe. Jaja, das sind natürlich nicht "quasi alle", aber ich denke das sieht fast überall so aus. Entweder wird so eine kryptische Adresse noch vorm Versand blockiert oder man erhält umgehend eine Meldung dass die Mail nicht zugestellt werden konnte.
Ich würde auch gerne wissen was passiert, wenn mir jemand von so einer Adresse eine Mail schickt. Ich bezweifle, dass die ankommt.
-
Weil ich's bei gängigen Free-Emailprovidern (bspw. WEB.de, GMX, Googlemail, Arcor, Freenet, Yahoo) und wie gesagt meinem kostenpflichtigen Account probiert habe.
WEB.de und GMX (bzw. das komplette United Internet Graffl) nutzen qmail, das kann problemlos damit umgehen, allerdings ist das von denen künstlich kastriert, Groß- und Kleinschreibung werden ignoriert und sämtliche Sonderzeichen mit Ausnahme des . gibts auch nicht. Da wirst du auch ein problem mit rené@example.com haben - was dein Ausdruck aber zuließe. Deine Argumente werden also immer dünner.
Google kastriert seine Mailaccounts sogar soweit, dass foo.bar[at]gmail.com dasselbe ist wie foobar[at]gmail.com
-
Weil ich's bei gängigen Free-Emailprovidern (bspw. WEB.de, GMX, Googlemail, Arcor, Freenet, Yahoo) und wie gesagt meinem kostenpflichtigen Account probiert habe.
WEB.de und GMX (bzw. das komplette United Internet Graffl) nutzen qmail, das kann problemlos damit umgehen, allerdings ist das von denen künstlich kastriert, Groß- und Kleinschreibung werden ignoriert und sämtliche Sonderzeichen mit Ausnahme des . gibts auch nicht. Da wirst du auch ein problem mit rené@example.com haben - was dein Ausdruck aber zuließe. Deine Argumente werden also immer dünner.
Google kastriert seine Mailaccounts sogar soweit, dass foo.bar[at]gmail.com dasselbe ist wie foobar[at]gmail.com
Und was ist mit der Tatsache, dass $?^_`.!#{|}%&'*+-/=~ nie bei trash-mail ankommt, obwohl diese Mail ja offensichtlich bei Twitter akzeptiert wird? Ist es kundenfreundlicher, dass die Mail akzeptiert wird, aber im Anschluss nie eine Mail von Twitter ankommen wird, weil die Mail sonstwo verschwindet?
Ich fühle mich eher darin bestätigt, dass ich mich nicht um $?^_
.!#{|}%&'\*+-/=~ o.ä. kümmern muss, weil die Mail so oder so irgendwo in den Tiefen des Netzes verloren gehen wird. Wenn rené@example.com bei mir akzpetiert wird und $?^\_.!#{|}%&'*+-/=~@example.com nicht soll mir das auch recht sein - aber auch hierbei bezweifle ich, dass man einen Emailprovider findet, der é zulässt. Beide machen Probleme (der eine bekommt immerhin einen Hinweis, dass die Mail - aus gutem Grund - nicht erlaubt ist).-
Und was ist mit der Tatsache, dass $?^_`.!#{|}%&'*+-/=~ nie bei trash-mail ankommt, obwohl diese Mail ja offensichtlich bei Twitter akzeptiert wird? Ist es kundenfreundlicher, dass die Mail akzeptiert wird, aber im Anschluss nie eine Mail von Twitter ankommen wird, weil die Mail sonstwo verschwindet?
Ich kenne die Geschäftsgebaren von Twitter nicht, das musst du schon die dort fragen.
aber auch hierbei bezweifle ich, dass man einen Emailprovider findet, der é zulässt.
Ich bezweifle noch immer noch, dass dir die Tragweite bewusst ist und vor allem, was in Zukunft alles möglich sein wird: http://idn.icann.org/E-mail_test
Wenn du eine PHP-Interne Funktion verwendest, kannst du davon ausgehen, dass diese am aktuellen Stand gehalten wird und immer zuverlässig funktioniert - auch bei künftigen Erweiterungen.
Bei selbstgestrickten Funktionen ist das nicht der Fall, die musst du selbst warten und ggf. auf den aktuellen Stand bringen.
Was du hier machst ist etwa so schlimm wie an der API eines Betriebssystems vorbeizuprogrammieren, weil man lieber sein eigenen Ding durchzieht. Siehe z.B. den Firefix mit seiner XUL-Oberfläche die Performance Ende nie frisst und inkonsistent zur GUI des jeweiligen Betriebssystems ist.
Sogar Apple hat beim Safari 4 mittlerweile (teilweise) gelernt, dass das eine dämliche Idee ist.
In jedem Fall ist hier für mich EOD.
-
In jedem Fall ist hier für mich EOD.
War mir klar, dass meine Fragen wohl offen bleiben.
Wie dem auch sei; es wurde ja gezeigt, dass jemand, der meint er müsse sich mit so einer Adresse durchs Internet bewegen, damit nicht weit kommt - ganz unabhängig davon ob ich so einen Filter benutze oder nicht.
-
-
-
-
-
Twitter habe ich gerade mal mit suits Beispielen probiert. Alle akzeptiert! Die müssen ganz schön doof sein, wo es doch so einfach wäre, das mit nem supi Regexp zu verhindern ;-)
Ach ja .. die Bestätigungsmail von Twitter ist immer noch nicht bei $?^_`.!#{|}%&'*+-/=~@trash-mail angekommen; eine andere bei Yahoo zum Vergleich dagegen schon. Aber das ist sicher Zufall.
-
Hi!
Ach ja .. die Bestätigungsmail von Twitter ist immer noch nicht bei $?^_`.!#{|}%&'*+-/=~@trash-mail angekommen; eine andere bei Yahoo zum Vergleich dagegen schon. Aber das ist sicher Zufall.
Der Punkt bei einer Email-Adressen-Prüfung ist eigentlich nicht, ob eine ungewöhnlich aussehende aber im Prinzip korrekte Adresse abgelehnt oder angenommen wird, sondern dass du selbst bei gewöhnlich aussehenden Adressen eine Aussage über die Gültigkeit nur dann treffen kannst, wenn eine an diese Adresse gesendete Mail auch tatsächlich dort angekommen ist und nicht beispielsweise wegen Nichtexistenz eines entsprechenden Postfachs abgelehnt wird. Diese Aussage ist auch nur eine einmalige. Eine Aussage über die weitere Gültigkeit in der Zukunft (inklusive ob die Adresse immer noch dem gleichen Adressaten zugeordnet ist) kann auch nicht getroffen werden. Also, egal was deine einmalige syntaktische Prüfung ergibt, sie ergibt jedenfalls keine Aussage über die Gültigkeit der Adresse, jetzt und in Zukunft. Sinnvoll wäre bei "komisch aussehenden" Adressen eine Rückfrage, ob die Adresse wirklich so stimmt und - je nachdem, wie wichtig dir die Angabe ist - der Versand einer Probe-Mail um wenigstens die aktuelle Gültigkeit bestätigt zu bekommen.
Lo!
-
Hi!
Sinnvoll wäre bei "komisch aussehenden" Adressen eine Rückfrage, ob die Adresse wirklich so stimmt und - je nachdem, wie wichtig dir die Angabe ist - der Versand einer Probe-Mail um wenigstens die aktuelle Gültigkeit bestätigt zu bekommen.Lo!
Da hast du recht, das werd ich mir mal überlegen, danke.
-
-
-
-
-
-
-
-
-
-
-
[latex]Mae govannen![/latex]
Folgende werden ausgefiltert, sind syntaktisch aber völlig ok.
[...]
Folgende geht durch, [...]
Und vor allem wird das hier durchgelassen:
hans.muster@example.com,fred_irgendwer@example.com,peter@example.com
Dem Betrieb als Spamschleuder steht nichts im Weg.
Cü,
Kai
--
Deutsches Liedgut international:
In early rope to mountain we pull
Foren-Stylesheet Site Selfzeug JS-Lookup
SelfCode: sh:( fo:| ch:? rl:( br:< n4:( ie:{ mo:| va:) js:| de:> zu:) fl:( ss:| ls:?
-
-
-
-
-
Auch hier ist eine Einschränkung mit vorsicht zu geniessen.
Insbesondere Annahmen bezäglich der TLD am Ende können Sorgen bereiten.filter_var() verwenden ;) verwendet zwar ebenfalls einen Regulären Ausdruck, aber der ist im PHP core.
-