nach sonderzeichen in einem string suchen

[venty]

Hi,

habe gerade einpaar probleme ein Email Feld zu kontrollieren. Deshalb frag ich mal euch ob ihr mir weiterhelfen könnt.

Ich suche nach einer Funktion mit der man Sonderzeichen in einem String ermitteln kann. Wenn möglich sogar mit der Möglichkeit Ausnahmen zu vermerken.

Hat jemand vielleicht ein gutes Anwenderbeispiel. Das von SelfHTML füllt noch nicht ganz meine erwartungen.

Mfg Venty

[ChrisB]

Hi,

Ich suche nach einer Funktion mit der man Sonderzeichen in einem String ermitteln kann. Wenn möglich sogar mit der Möglichkeit Ausnahmen zu vermerken.

Definiere: Sonderzeichen, ermitteln.

MfG ChrisB

[venty]

Definiere: Sonderzeichen, ermitteln.

Im forderen teil, also allem vor dem @ zeichen, dürfen nur Buchstaben, Zahlen punkt und unterstrich sein. Eben nur zeichen die in einer gültigen Email-Adresse enthalten sein dürfen. Wenn da noch ein anderes zeichen ist soll die Funktion false zurückgeben.

Etwa so habe ich mir das vorgestellt:

  
STRING.sonderzeichen("_",".");  

gibt es soetwas oder etwas änliches?

Mfg Venty

[Deus Figendi]

Im forderen teil, also allem vor dem @ zeichen, dürfen nur Buchstaben, Zahlen punkt und unterstrich sein. Eben nur zeichen die in einer gültigen Email-Adresse enthalten sein dürfen. Wenn da noch ein anderes zeichen ist soll die Funktion false zurückgeben.

Oha, du wagst dich an eine Meister-Aufgabe!
Email-Adrssen dürfen deutlich mehr im _v_orderen Teil beinhalten. Der Reguläre Ausdruck um das zu prüfen schwirrt irgendwo im Netz rum und ist irgendwas bei 2000 Zeichen lang und wahrscheinlich ist er nicht perfekt.
Mit anderen Worten:

gibt es soetwas oder etwas änliches?

Ja!

[Deus Figendi]

Hinter dem ersten Google-Treffer habe ich dies gefunden:
(?:[a-z0-9!#$%&'*+/=?^_{|}~-]+(?:\.[a-z0-9!#$%&'\*+/=?^\_{|}~-]+)*|"(?:[\x01-\x08\x0b\x0c\x0e-\x1f\x21\x23-\x5b\x5d-\x7f]|\[\x01-\x09\x0b\x0c\x0e-\x7f])*")@(?:(?:a-z0-9?.)+a-z0-9?|[(?:(?:25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?).){3}(?:25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?|[a-z0-9-]*[a-z0-9]:(?:[\x01-\x08\x0b\x0c\x0e-\x1f\x21-\x5a\x53-\x7f]|\[\x01-\x09\x0b\x0c\x0e-\x7f])+)])
Okay sind nur 426 Zeichen und ich weiß nicht ob sie "passt" der Autor empfiehlt auch andere, performantere Ausdrücke zu verwenden (siehe Link)
im RFC 2822 ist in Sektion 3.4 definiert wie eine Mail-Adresse auszusehen hat. (lies ggf. auch das SMTP-RFC ich meine da stünde auch noch was zum Thema drin)

[suit]

Okay sind nur 426 Zeichen und ich weiß nicht ob sie "passt" der Autor empfiehlt auch andere, performantere Ausdrücke zu verwenden (siehe Link)

Der dürfte nichtmal ansatzweise korrekt sein - PHP verwendet momentan diesen hier:

/^(?!(?:(?:\x22?\x5C[\x00-\x7E]\x22?)|(?:\x22?[^\x5C\x22]\x22?)){255,})(?!(?:(?:\x22?\x5C[\x00-\x7E]\x22?)|(?:\x22?[^\x5C\x22]\x22?)){65,}@)(?:(?:[\x21\x23-\x27\x2A\x2B\x2D\x2F-\x39\x3D\x3F\x5E-\x7E]+)|(?:\x22(?:[\x01-\x08\x0B\x0C\x0E-\x1F\x21\x23-\x5B\x5D-\x7F]|(?:\x5C[\x00-\x7F]))*\x22))(?:\.(?:(?:[\x21\x23-\x27\x2A\x2B\x2D\x2F-\x39\x3D\x3F\x5E-\x7E]+)|(?:\x22(?:[\x01-\x08\x0B\x0C\x0E-\x1F\x21\x23-\x5B\x5D-\x7F]|(?:\x5C[\x00-\x7F]))*\x22)))*@(?:(?:(?!.*[^.]{64,})(?:(?:(?:xn--)?[a-z0-9]+(?:-[a-z0-9]+)*\.){1,126}){1,}(?:(?:[a-z][a-z0-9]*)|(?:(?:xn--)[a-z0-9]+))(?:-[a-z0-9]+)*)|(?:\[(?:(?:IPv6:(?:(?:[a-f0-9]{1,4}(?::[a-f0-9]{1,4}){7})|(?:(?!(?:.*[a-f0-9][:\]]){7,})(?:[a-f0-9]{1,4}(?::[a-f0-9]{1,4}){0,5})?::(?:[a-f0-9]{1,4}(?::[a-f0-9]{1,4}){0,5})?)))|(?:(?:IPv6:(?:(?:[a-f0-9]{1,4}(?::[a-f0-9]{1,4}){5}:)|(?:(?!(?:.*[a-f0-9]:){5,})(?:[a-f0-9]{1,4}(?::[a-f0-9]{1,4}){0,3})?::(?:[a-f0-9]{1,4}(?::[a-f0-9]{1,4}){0,3}:)?)))?(?:(?:25[0-5])|(?:2[0-4][0-9])|(?:1[0-9]{2})|(?:[1-9]?[0-9]))(?:\.(?:(?:25[0-5])|(?:2[0-4][0-9])|(?:1[0-9]{2})|(?:[1-9]?[0-9]))){3}))\]))$/iD

Zu finden in folgendem File:
http://svn.php.net/viewvc/php/php-src/trunk/ext/filter/logical_filters.c?revision=297353&view=markup

Dennoch ist auch dieser nicht komplett: er prüft immer noch nicht RFC 5321 Abschnitt 4.5.3.1.

[bleicher]

Grüße,
so verbissen - die tolle regexplösung zu finden, dabei wurde uns mit html5 doch ein mail-inputfeld gegeben - wieso mags keiner?
MFG
bleicher

[Deus Figendi]

so verbissen - die tolle regexplösung zu finden, dabei wurde uns mit html5 doch ein mail-inputfeld gegeben - wieso mags keiner?

stimmt, geht ja um JavaScript ^^ da kann man natürlich besser das HTML-Element benutzen :)
Du siehst es schon richtig, verbissen... kontext-blind
Kann das schon jemand außer Opera? Naja wenn nicht wäre es auch egal.
(Da ich befürchte man könnte diesen Beitrag ironisch auffassen: Er enthält keine Ironie! Wenn ich Ironie verwende markiere ich ich sie auch mit Doppelpunkt-Minus-KlammerZu)

[suit]

Wenn ich Ironie verwende markiere ich ich sie auch mit Doppelpunkt-Minus-KlammerZu)

Wenn ich Ironie, Zynismus oder Sarkasmus verwende, verzichte ich oft absichtlich auf eine entsprechende Kenzeichnung durch Doppelpunkt-Klammer oder Doppelpunkt-klein-P :p ... FAIL.

[bleicher]

Grüße,
es ist hier IMHO eher Regel als Ausnahme, dass der Bereich und die bessere Lösung nicht korrelieren, allein die "mehrere frames ansteuern" im html oder "userinteraktion live" im php bereich sind statistisch viel wert^^.

was er will, kann man mit JS machen, aber man könnte dies schmerzlos durch mail-input absichern - in dem Fall könnten browser die es beherrschen die Aufgabe auch übernhemen, was in Zukunft schmerzloses abschalten von dieser monster regexp ermöglicht.

aber von mir raus darfst du im furrfox t-shirt vor dem Rechner Fahnen schwingen und jede einzelne Technik die dieser nicht unterstützt verdammen.
Opera und web-kit Browser unterstützen es nämlich afaik, ob furrfox es tut ist inzwischen zunehmend weniger wichtig :)

MFG
bleicher

[Deus Figendi]

aber von mir raus darfst du im furrfox t-shirt vor dem Rechner Fahnen schwingen und jede einzelne Technik die dieser nicht unterstützt verdammen.
Opera und web-kit Browser unterstützen es nämlich afaik, ob furrfox es tut ist inzwischen zunehmend weniger wichtig :)

Vielleicht hast du mich da missverstanden, ich schrieb ja "wenn nicht ist auch egal", denn die Browserschaft wird nachziehen. Der Weg ist nicht Techniken, die der favorisierte (oder oft wahrscheinlich nur der gewohnte) Browser nicht unterstützt zu verdammen, wie kommst du darauf, dass das meine Aussage gewesen wäre?
Im Gegenteil, ich stimmte dir eigentlich in Gänze zu. Eine serverseitige Prüfung ist in jedem Falle nötig (und wenn es nur eine Test-Mail ist) und die clientseitige kann man in der Tat der Browserengine überlassen.
"Der Weg" dürfte sein den Entwicklern des favorisierten Browsers auf die Füße zu treten oder unter Umständen bei quelloffenen selber machen (ggf. über Erweiterungen/Plugins...).
Im Moment warte ich einfach ab, HTML5 ist noch nicht fertig und da braucht man keinem Entwickler vorwerfen, dass ER noch nicht fertig ist. Aber "Verdammung" ist hier nicht angebracht, weder gegenüber der Technik noch dem Interpreter gegenüber.

Oh, da steht ein Kaffee...

[Jens Holzkämper]

Tach,

so verbissen - die tolle regexplösung zu finden, dabei wurde uns mit html5 doch ein mail-inputfeld gegeben - wieso mags keiner?

haben sie dabei wirklich IDN vergessen oder war das Absicht?

http://dev.w3.org/html5/markup/datatypes.html#form.data.emailaddress sagt:

1*( atext / "." ) "@" ldh-str 1*( "." ldh-str )

…where atext is as defined in RFC 5322 [RFC5322], and ldh-str is as defined in RFC 1034 [RFC1034].

und ldh-str ist dann in der RFC 1034 definiert als:

<ldh-str> ::= <let-dig-hyp> | <let-dig-hyp> <ldh-str>
<let-dig-hyp> ::= <let-dig> | "-"
<let-dig> ::= <letter> | <digit>
<letter> ::= any one of the 52 alphabetic characters A through Z in upper case and a through z in lower case
<digit> ::= any one of the ten digits 0 through 9

Die atext-Definition in RFC 5322 ist auch nur eine Teilmenge der theoretisch verwendbaren Adressen.

Insgesamt sieht es so aus, als hätte man es sich einfach machen wollen.

mfg
Woodfighter

[Jens Holzkämper]

Tach,

Insgesamt sieht es so aus, als hätte man es sich einfach machen wollen.

ah, sehe schon, die WhatWG-Spec ist Aussagekräftiger:

"User agents may transform the value for display and editing (e.g. converting punycode in the value to IDN in the display and vice versa)." und "This requirement is a willful violation  of RFC 5322, which defines a syntax for e-mail addresses that is simultaneously too strict (before the "@" character), too vague (after the "@" character), and too lax (allowing comments, white space characters, and quoted strings in manners unfamiliar to most users) to be of practical use here."

mfg
Woodfighter

[venty]

Hi,

Also danke an alle! Hab wieder ne menge gelernt *puh*

Allerdings verstehe ich diese langen angaben nicht. Ich habe es jetzt nach dem dem Google-Treffer gemacht.

/^[a-zA-Z0-9._]+@[a-zA-Z0-9._]+\.[a-zA-Z0-9]+$/

btw: wenn ihr noch Google verwendet solltet ihr vielleicht eine seite wie diese testen. Hat auch eine SelfHTML-Suchfunktion, ebenso wie eine PHP.net-Suchfunktion!

Danke nochmal!

Mfg Venty

[Gunnar Bittersmann]

@@venty:

nuqneH

/^[a-zA-Z0-9._]+@[a-zA-Z0-9._]+\.[a-zA-Z0-9]+$/

Das ist Unsinn, du lässt viele E-Mail-Adressen nicht zu. Domainnamen dürfen auch andere Zeichen außer [a-zA-Z0-9._] enthalten; auch TLDs. Und das sind auch keine Sonderzeichen.

Qapla'

[Deus Figendi]

Das ist Unsinn, du lässt viele E-Mail-Adressen nicht zu. Domainnamen dürfen auch andere Zeichen außer [a-zA-Z0-9._] enthalten; auch TLDs. Und das sind auch keine Sonderzeichen.

Naja naja, ich würde es nicht in Stein gemeißelt sehen, was man als "Sonderzeichen" sieht und was nicht. Wikipedia meint es seien "Satzzeichen, die nicht zu den in Schriftzeichen festgehaltenen Lauten des Alphabets gehören." und scheint dabei explizit Umlaute einzuschließen. (Die englische Wikipedia definiert es gar nicht).
Andere mögen sagen es sind _nur_ "controls" also nicht-druckbare Zeichen, dabei stellt sich aber die Frage ob das whitespaces einschließt und wenn ja welche.
Man mag auch die Ansicht vertreten alles was nicht im ursprünglichen ASCII(7) steht ist ein Sonderzeichen.
Oder aber wie oben mal erwähnt vielleicht auch alles was von \W erfasst wird (bzw. von \w nicht erfasst wird).
Was ich sagen will: Ich glaube nicht dass irgendwie definiert ist was "Sonderzeichen" sind und was nicht. Es kommt wahrscheinlich auf den Kontext an, sowie auf die Ansicht des "Senders" (Sprechenden). Ich fürchte man muss raten was gemeint ist :)

[Gunnar Bittersmann]

@@Deus Figendi:

nuqneH

link:http://de.wikipedia.org/wiki/Sonderzeichen@title=Wikipedia] meint es seien "Satzzeichen, die nicht zu den in Schriftzeichen festgehaltenen Lauten des Alphabets gehören." und scheint dabei explizit Umlaute einzuschließen.

Natürlich sind Umlaute stinknormale Buchstaben des deutschen Alphabets, also mitnichten Sonderzeichen.

(Die englische Wikipedia definiert es gar nicht).

Warum wundert das nicht? S.u.

Oder aber wie oben mal erwähnt vielleicht auch alles was von \W erfasst wird (bzw. von \w nicht erfasst wird).

Das dürfte von den Locale-Einstellungen abhängen.

Was ich sagen will: Ich glaube nicht dass irgendwie definiert ist was "Sonderzeichen" sind und was nicht. Es kommt wahrscheinlich auf den Kontext an

Natürlich tut es das. Im Kontext E-Mail ist '@' ein Sonderzeichen, im Kontext Domainname '.'. Im Kontext XML sind '<', '>', '&', '"' und "'" Sonderzeichen.

sowie auf die Ansicht des "Senders" (Sprechenden).

Wenn der Sprechende 'ä' als Sonderzeichen ansieht, outet er sich als Englischsprecher* mit beschränktem Horizont.

Qapla'

* Es gibt wohl nur sehr wenige lateinisch geschriebene Sprachen, die nur [A-Za-z] verwenden. In einer Konversation wies mich Richard Ishida noch auf Malaiisch/Indonesisch hin. Aber selbst im Englichen wird naïve zur Kennzeichnung der getrennten Aussprache der Vokale mit Trema geschrieben.

[dedlfix]

Hi!

Natürlich sind Umlaute stinknormale Buchstaben des deutschen Alphabets, also mitnichten Sonderzeichen.

Das zeigt sich ja schon daran, dass sie beim Aufsagen des Alphabets mit erwähnt werden und - wie alle anderen Buchstaben auch - eine Ersatzschreibweise haben (ae, oe, ue ss, sz) ...

Der Kontext hier ist nicht deutsche Sprache sondern Computerei, und da sind es nunmal Zeichen, die jenseits der amerikanischen Vorstellung von Normalität existieren. Auch allen Unicode-Bestrebungen zum Trotz werden es (noch lange) Zeichen bleiben, die man als Programmierer deutlich mehr beachten muss als ASCII-Buchstaben. Selbst in einer reinen Unicode-Welt hat man mit den Combining Diacritical Marks versus "Lateinisch, erweitert-A" und B, etc. eine Sonderstellung geschaffen. Es gibt schonmal zwei Wege, sie zu notieren, was als zu beachtende Besonderheit reichen sollte, um sie aus der "Normalität" herauszuholen.

Lo!

[Gunnar Bittersmann]

@@dedlfix:

nuqneH

Der Kontext hier ist nicht deutsche Sprache sondern Computerei,

Computerei ist kein Selbstzweck, sondern immer nur Mittel zum Zweck.

Der Kontext ist Textverarbeitung (unabhängig vom Computer als verwendetem Werkzeug), und da ist 'ä' kein Sonderzeichen. 'ю', 'ξ', 'א' auch nicht.

und da sind es nunmal Zeichen, die jenseits der amerikanischen Vorstellung von Normalität existieren.

Beschränkte Vorstellungen sind nicht das Maß aller Dinge.

Auch allen Unicode-Bestrebungen zum Trotz werden es (noch lange) Zeichen bleiben, die man als Programmierer deutlich mehr beachten muss als ASCII-Buchstaben.

Abhängig von der Beschränktheit (der Entwickler) der Programmiersprache. PHP ist kein rühmliches Beispiel; in JavaScript sehe ich keine Probleme.

Selbst in einer reinen Unicode-Welt hat man mit den Combining Diacritical Marks versus "Lateinisch, erweitert-A" und B, etc. eine Sonderstellung geschaffen.

Ja, Normalisierung ist ein Thema. Aber ein anderes.

Es gibt schonmal zwei Wege, sie zu notieren, was als zu beachtende Besonderheit reichen sollte, um sie aus der "Normalität" herauszuholen.

Vergleiche mal die Anzahl der lateinischen Buchstaben, die sich als solcher (U+00E4 ä) und als Buchstabe + diakritisches Zeichen (U+0061 a U+0308 combining diaresis) darstellen lassen, mit denen ohne diakritische Zeichen. Du wirst sehen, dass [A-Za-z] die Ausnahme (die „Sonderzeichen“) sind.

Qapla'

[dedlfix]

Hi!

Der Kontext ist Textverarbeitung (unabhängig vom Computer als verwendetem Werkzeug), und da ist 'ä' kein Sonderzeichen. 'ю', 'ξ', 'א' auch nicht.

Von außen betrachtet mag das alles stimmen, es sind alles nur Zeichen. Aber der Programmierer unterscheidet dann doch zwischen den Zeichen, sei es aus historischen Gründen oder weil sie in verschiedenen Kontexten verschiedene Bedeutungen haben. Mit der Idealtheorie kommt man beim praktischen Lösen von Aufgabenstellungen nicht sehr weit.

und da sind es nunmal Zeichen, die jenseits der amerikanischen Vorstellung von Normalität existieren.
Beschränkte Vorstellungen sind nicht das Maß aller Dinge.

Die Praxis zu ignorieren auch nicht.

Auch allen Unicode-Bestrebungen zum Trotz werden es (noch lange) Zeichen bleiben, die man als Programmierer deutlich mehr beachten muss als ASCII-Buchstaben.
Abhängig von der Beschränktheit (der Entwickler) der Programmiersprache. [...] in JavaScript sehe ich keine Probleme.

Ich schon:

alert(/\w/.exec('a')); // a
  alert(/\w/.exec('ä')); // null

ä ist aus Javascript also kein Wort-Zeichen.

alert(/f\b/.exec('faden')) // null
  alert(/f\b/.exec('fäden')) // f

Außerdem ist es eine Wortgrenze.

Lo!

[suit]

ä ist aus Javascript also kein Wort-Zeichen.

\w ist in JavaScript hier also sehr beschränkt definiert. In PHP ist bei de_DE als locale sehrwohl ä ein normales Wort-Zeichen.

Wort-Zeichen im Sinne von Unicode hingegen sind viel bereiter gefächert, in der PHP-Variante der PCRE ist dafür z.B. \P{L} vorgesehen, das betrachtet ä als ganz normales "Wort"-Zeichen - unabhängig davon, welche locale-Weret grade gesetzt sind.

[dedlfix]

Hi!

ä ist aus Javascript also kein Wort-Zeichen.
\w ist in JavaScript hier also sehr beschränkt definiert.

Damit haben wir also ein Problem, wenn Buchstaben gesucht werden. \w ist ungeeignet und \p{xx} steht nicht zur Verfügung. Auch [a-z] umfasst diese diakritischen Zeichen nicht, ganz zu schweigen von den nicht-lateinischen Buchstaben. Man muss sie irgendwie extra notieren, sie also gesondert behandeln. Wenn das aus Programmierersicht nicht den Begriff Sonderzeichen rechtfertigt, dann weiß ich auch nicht weiter.

Lo!

[suit]

Man muss sie irgendwie extra notieren, sie also gesondert behandeln. Wenn das aus Programmierersicht nicht den Begriff Sonderzeichen rechtfertigt, dann weiß ich auch nicht weiter.

Wie Gunnar schon sagte: in einer E-Mail Adresse sind sehr viele Zeichen erlaubt, diejenigen die Nicht erlaubt sind, sind die Sonderzeichen ;)

[suit]

Natürlich sind Umlaute stinknormale Buchstaben des deutschen Alphabets, also mitnichten Sonderzeichen.

Genauer gesagt sind Umlaute stinknormale Buchstaben mit diakritischen Zeichen :)

Aber selbst im Englichen wird naïve zur Kennzeichnung der getrennten Aussprache der Vokale mit Trema geschrieben.

Termata hat man bei uns aber leider schon de facto abgeschafft bzw. sie in zwei Rechtschreibreformen einfach irgnoriert und verschwiegen.

[Kai345]

[latex]Mae  govannen![/latex]

Allerdings verstehe ich diese langen angaben nicht. Ich habe es jetzt nach dem dem Google-Treffer gemacht.

/^[a-zA-Z0-9._]+@[a-zA-Z0-9._]+\.[a-zA-Z0-9]+$/

Der Ausdruck ist Unsinn, es werden hier viele gültige Adressen nicht angenommen. Es hat schon seinen Grund, weshalb die RegEx zur genauen E-Mail-Validation gigantisch ist.

Um nur drei zu nennen, die einen gültigen local-part haben, aber abgewiesen werden:

[e-mail]
[e-mail]
user~[e-mail]

In http://www.rfc-editor.org/rfc/rfc2822.txt (keine Ahnung, ob der noch gilt; ist aber ein Anhaltspunkt)kannst du mal nach atext suchen, dort stehen die erlaubten Zeichen in local-part. Allerdings ist dort noch mehr erlaubt.

Ich würde einfach nur auf ganz grundsätzliche Syntax prüfen, insbesondere kein Komma (um mehrere Adressen zu vermeiden), nur ein @ usw.

Cü,

Kai

[Don P]

Hallo,

Allerdings verstehe ich diese langen angaben nicht. Ich habe es jetzt nach dem dem Google-Treffer gemacht.

/^[a-zA-Z0-9._]+@[a-zA-Z0-9._]+\.[a-zA-Z0-9]+$/

Das sperrt halt viele aus, z.B. o'[e-mail]
Selber schuld wer so einen Namen hat und auch noch in der Mail-Adresse benutzen will ;)

Gruß, Don P

[hotti]

hi,

gibt es soetwas oder etwas änliches?

Ach Gott, wenn eine ungültige eMail-Adresse verwendet wird, dann kommt die Mail ganz einfach nicht an. Wenn irgenwas passieren soll, was Schlimmer ist, dann musst Du das nur entsprechend programmieren ;-)

Hotti

[bleicher]

Grüße,
du braucht ein input vom typ mail, nicht mehr, denn emailadressen dürfen Sonderzeichen enthalten.
MFG
bleicher

[Gunnar Bittersmann]

@@venty:

nuqneH

Eben nur zeichen die in einer gültigen Email-Adresse enthalten sein dürfen.

Die Lektüre von Validierung von eMail-Adressen (Selfforumssieb) sollte dich von deinem unsinnigen Vorhaben abbringen.

Qapla'

[Deus Figendi]

Ich suche nach einer Funktion mit der man Sonderzeichen in einem String ermitteln kann. Wenn möglich sogar mit der Möglichkeit Ausnahmen zu vermerken.

öhm wie wäre es mit dem regulären Ausdruck
\W
Der alle nicht-Wort-Zeichen (also alles was keine Ziffer und kein lateinischer Buchstabe ist) erfasst!? Die gewünschten Ausnahmen lassen sich ja recht leicht mit RegEx hinzufügen.