Backslashs in REGEXP
johny7
1 0 dedlfix
0
Backslashs in REGEXP
johny7
Gunnar BittersmannMoin allerseits,
ich habe aus einer JavaScript-Datei folgende RegExp geholt:
/^((([a-z]|\d|[!#\$%&'\*\+\-\/=\?\^_`{\|}~]|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])+(\.([a-z]|\d|[!#\$%&'\*\+\-\/=\?\^_`{\|}~]|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])+)*)|((\x22)((((\x20|\x09)*(\x0d\x0a))?(\x20|\x09)+)?(([\x01-\x08\x0b\x0c\x0e-\x1f\x7f]|\x21|[\x23-\x5b]|[\x5d-\x7e]|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])|(\\([\x01-\x09\x0b\x0c\x0d-\x7f]|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF]))))*(((\x20|\x09)*(\x0d\x0a))?(\x20|\x09)+)?(\x22)))@((([a-z]|\d|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])|(([a-z]|\d|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])([a-z]|\d|-|\.|_|~|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])*([a-z]|\d|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])))\.)+(([a-z]|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])|(([a-z]|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])([a-z]|\d|-|\.|_|~|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])*([a-z]|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])))\.?$/i
Mit diesem Ausdruck werden E-Mail-Adressen validiert.
Diesen Ausdruck will ich jetzt in PHP mit preg_match() einsetzen. Allerdings wird überhaupt keine Eingabe mehr akzeptiert. Könnte es daran liege, dass noch irgendwelches Zeichen mit einem zusätzlichen Backslash versehen werden müssen? Kann mir jemand sagen, um welche es sich dabei handelt und ob es evtl. auch ein Tool gibt, mit dem man solche Anpassungen schnell machen kann.
Hintergrund:
Ich verwende jQuery-Validate um Formulareingaben zu prüfen. Auf Server-Seite prüfe ich die Eingaben auch noch einmal. Deshalb muss ich dieselbe Prüfung auf beiden Seiten machen. Vorher hatte ich nämlich auf PHP-Seite eine andere Abfrage.
Grüße, JN
--
ie:{ fl:( br:^ va:| ls:[ fo:| rl:? n4:? ss:| de:] js:| ch:? sh:( mo:| zu:)
http://www.johny7.de
ie:{ fl:( br:^ va:| ls:[ fo:| rl:? n4:? ss:| de:] js:| ch:? sh:( mo:| zu:)
http://www.johny7.de
-
Diesen Ausdruck will ich jetzt in PHP mit preg_match() einsetzen.
Vergiss das wieder - der von PHP verwendete Ausdruck ist zwar nicht perfekt[1], vermutlich aber wesentlich besser als das was du verwendest.
Ich verwende jQuery-Validate um Formulareingaben zu prüfen. Auf Server-Seite prüfe ich die Eingaben auch noch einmal. Deshalb muss ich dieselbe Prüfung auf beiden Seiten machen.
Warm lässt du nicht in beiden Fällen den Server prüfen? Ajax ist dir doch ein Begriff.
DRY!
[1] er bezeichnet IDN-Mailadressen als ungültig - aber die würden ohnehin praktisch nicht funktionieren.
-
@@suit:
nuqneH
[1] er bezeichnet IDN-Mailadressen als ungültig
Eben, ist also unbrauchbar. I18n fail.
aber die würden ohnehin praktisch nicht funktionieren.
?? Warum sollten sie nicht funktionieren?
Qapla'
--
Gut sein ist edel. Andere lehren, gut zu sein, ist noch edler. Und einfacher.
(Mark Twain)-
[1] er bezeichnet IDN-Mailadressen als ungültig
Eben, ist also unbrauchbar. I18n fail.
Du solltest dringend einen Bugnote in den PHP-Bugtracker schreiben.
aber die würden ohnehin praktisch nicht funktionieren.
?? Warum sollten sie nicht funktionieren?
Viele Mailserver und Mailclients die im Umlauf sind, unterstützen sie nicht richtig - afaik immer noch alles im Testbetrieb.
-
@@suit:
nuqneH
Viele Mailserver und Mailclients die im Umlauf sind, unterstützen sie nicht richtig - afaik immer noch alles im Testbetrieb.
Hm, muss ein Mailserver das? Sollten nicht IDNs schon vom Mailclient in Punycode umgewandelt werden?
Qapla'
--
Gut sein ist edel. Andere lehren, gut zu sein, ist noch edler. Und einfacher.
(Mark Twain)-
Viele Mailserver und Mailclients die im Umlauf sind, unterstützen sie nicht richtig - afaik immer noch alles im Testbetrieb.
Hm, muss ein Mailserver das? Sollten nicht IDNs schon vom Mailclient in Punycode umgewandelt werden?
Ansich ja - aber der local-part muss nicht Kodiert werden.
Die Frage ist ob filter_var() nicht zumindest den domain-part entsprechend in punycode übersetzen müsste.
-
@@suit:
nuqneH
Ansich ja - aber der local-part muss nicht Kodiert werden.
AFAIS dürfen dort auch noch keine Nicht-ASCII-Zeichen vorkommmen. Das soll sich natürlich zukünftig ändern. Da war ich wohl in meinen Kommentaren etwas voreilig.
Qapla'
--
Gut sein ist edel. Andere lehren, gut zu sein, ist noch edler. Und einfacher.
(Mark Twain)
-
-
-
-
-
-
Hi!
ich habe aus einer JavaScript-Datei folgende RegExp geholt:
Diesen Ausdruck will ich jetzt in PHP mit preg_match() einsetzen.In Javascript wird der Ausdruck als solcher in /.../ eingefasst. In PHP wird er zusätzlich noch als String notiert. Du musst also die String-Maskier-Regeln beachten.
Allerdings wird überhaupt keine Eingabe mehr akzeptiert. Könnte es daran liege, dass noch irgendwelches Zeichen mit einem zusätzlichen Backslash versehen werden müssen?
Kommt unter anderem auf die Art des Strings an, single oder double quoted. Wenn PHP das Zeichen interpretieren kann, wird es direkt und nicht als Escape-Sequenz an den Regexp übergeben. Interpretationsunterschiede scheint es mir zumindest bei \v zu geben, ich hab aber nicht alles untersucht. Wenn etwas keine gültige PHP-Escape-Sequenz ergibt, wird die Zeichenfolge durchgereicht und dann von der Regex-Maschine interpretiert.
Kann mir jemand sagen, um welche es sich dabei handelt und ob es evtl. auch ein Tool gibt, mit dem man solche Anpassungen schnell machen kann.
Nun, zumindest die Backslashes kannst du mit str_replace() verdoppeln, aber das wird dir am Ende nichts bringen, denn das Problem sind die \u-Sequenzen, denn die kennt weder PHP noch die dort eingebaute Regex-Maschine. Wenn du die in UTF-8-Sequenzen umgesetzt bekommst und den UTF-8-Modifier angibst, kann die Regexp-Maschine sie richtig auswerten.
Aber wie suit schon sagte, ist das alles unnötig. Zum einen weil es bereits einen Mechanismus in PHP gibt und zum anderen gibt es unzählige invalide Email-Adressen, die jedoch syntaktisch korrekt sind.
Lo!
-
Moin Moin!
Moin allerseits,
ich habe aus einer JavaScript-Datei folgende RegExp geholt:
/^((([a-z]|\d|[!#$%&'*+-/=?^
{\|}~]|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])+(\.([a-z]|\d|[!#\$%&'\*\+\-\/=\?\^_{|}~]|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])+))|((\x22)((((\x20|\x09)(\x0d\x0a))?(\x20|\x09)+)?(([\x01-\x08\x0b\x0c\x0e-\x1f\x7f]|\x21|[\x23-\x5b]|[\x5d-\x7e]|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])|(\([\x01-\x09\x0b\x0c\x0d-\x7f]|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF]))))(((\x20|\x09)(\x0d\x0a))?(\x20|\x09)+)?(\x22)))@((([a-z]|\d|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])|(([a-z]|\d|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])([a-z]|\d|-|.||~|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])([a-z]|\d|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF]))).)+(([a-z]|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])|(([a-z]|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])([a-z]|\d|-|.|_|~|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])([a-z]|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF]))).?$/i> Mit diesem Ausdruck werden E-Mail-Adressen validiert. Ich bezweifle, dass das richtig ist, schon allein weil die RE so kurz ist. Eine RE (in [ckaddr.gz](http://www.cpan.org/authors/Tom_Christiansen/scripts/ckaddr.gz) versteckt), von der der Autor behauptet, sie würde RFC 822 abdecken, ist 5 KByte groß. Hast Du überprüft, was diese RE prüft? Ganz trivial matcht diese RE z.B. für "foo@bar.baz.", das wäre also eine gültige E-Mail-Adresse. Ist es aber nicht. Es gibt keine TLD "baz". Die RE ist also kaputt. Anderer Punkt: spam@example.com ist formell eine gültige E-Mail-Adresse. example.com ist aber in RFC2606 explizit für Beispiele reserviert. Ist das nun eine valide E-Mail-Adresse oder nicht? Von anderen Gemeinheiten, die in E-Mail-Adressen durchaus erlaubt sind, hab ich noch gar nicht angefangen. Angefangen damit, dass der Teil vor dem letzten @ fast beliebige Formen annehmen kann. Siehe auch <http://aktuell.de.selfhtml.org/weblog/validierung-von-email-adressen> bzw. <https://forum.selfhtml.org/?t=161038&m=1047554>. Alexander -- Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so".