input --> pattern: Kann man die ausschließliche Eingabe von Leerzeichen verhindern?

[Mr. Wolf]

Guten Tag,

folgendes Problem: Bei der Validierung eines Eingabefeldes mittels 'pattern' möchte ich Buchstaben, Zahlen und Leerzeichen (auch mehrere) zulassen − soweit kein Problem. Ich möchte aber zusätzlich noch verhindern, dass ausschließlich Leerzeichen eingegeben werden. Die serverseitige Validierung mittels php ist bereits realisiert, die Eingabe soll aber bereits vor Absendung kontrolliert werden. Als Workaround würde ich die Eingabe eine Leerzeichens am Anfang ausschließen, mir wäre aber beschriebene Variante lieber.

Ich bin dankbar für Eure Ideen!

Gruß Wolf

[Gunnar Bittersmann]

@@Mr. Wolf

Validierung eines Eingabefeldes mittels 'pattern' […] verhindern, dass ausschließlich Leerzeichen eingegeben werden.

Dein pattern wäre also: beliebig viele (auch 0) beliebige Zeichen gefolgt von einem Nicht-Whitespace-Zeichen gefolgt von beliebig vielen (auch 0) beliebigen Zeichen.

Die Frage, die sich mir stellt, ist aber: Warum sollten Nutzer ein Feld mit Leerzeichen füllen anstatt es ganz leer zu lassen? Der Nutzer will dort keine Daten eingeben; der Seitenbetreiber meint aber, das Feld zum Pflichtfeld zu machen?

Was hat der Seitenbetreiber davon, wenn die Nutzer das Feld anstatt mit Leerzeichen mit „xxx“ füllen?

LLAP 🖖

[Mr. Wolf]

@Gunnar Bittersmann

Entschuldige bitte, ich hatte vergessen zu erwähnen, dass dieses InputFeld auch das Attribut 'required' hat. Ich möchte schon, dass da etwas eingegeben wird und die Validierung nicht durch ein (vielleicht versehentlich eingegebenes) Leerzeichen versagt. Vielleicht bin ich ja zu paranoid, aber folgenden Fall halte ich schon für möglich. Nutzer gibt etwas ins Feld ein, löscht es wieder und vergisst dabei ein Leerzeichen. Dann würde meine Validierung nicht anschlagen: Leerzeichen ist ja erlaubt und 'required' meckert nicht, weil das Feld ja nicht leer ist.

[marctrix]

Hej Mr.,

@Gunnar Bittersmann

Entschuldige bitte, ich hatte vergessen zu erwähnen, dass dieses InputFeld auch das Attribut 'required' hat. Ich möchte schon, dass da etwas eingegeben wird

Ob du das möchtest ist nicht so wichtig. Entscheidend ist, ob ein ausfüllen für den weiteren Prozess unerlässlich ist. Sonst lass das required weg.

Die Clientseitige validierung ist ein reines Komfortmerkmal.

Der Fall, dass jemand alles bis auf ein Leerzeichen löscht, ist recht unwahrscheinlich. Daher würde ich den nicht abfangen.

Hier reicht die ohnehin nötige serverseitige validierung, die du ja eh noch musst.

My 2 cents

Marc

[Regina Schaukrug]

Nutzer gibt etwas ins Feld ein, löscht es wieder und vergisst dabei ein Leerzeichen. Dann würde meine Validierung nicht anschlagen: Leerzeichen ist ja erlaubt und 'required' meckert nicht, weil das Feld ja nicht leer ist.

Einfach verlangen, dass irgendwo (also im String/bzw. Input) Deine Ansicht nach genug (hier: 3) aufeinander folgendes Zeichen drin stehen, die keine Leerzeichen sind:

[^ ]{3,}

Alles andere kannst Du serverseitig trimmen und grep_replacen...

[Gunnar Bittersmann]

@@Regina Schaukrug

Einfach verlangen, dass irgendwo (also im String/bzw. Input) Deine Ansicht nach genug (hier: 3) aufeinander folgendes Zeichen drin stehen, die keine Leerzeichen sind:

[^ ]{3,}

Das ist falsch.

Das pattern bezieht sich auf die gesamte Eingabe (so als ob ^ davor und $ danach stehen würde), nicht nur auf einen Teil davon.

LLAP 🖖

[Regina Schaukrug]

Einfach verlangen, dass irgendwo (also im String/bzw. Input) Deine Ansicht nach genug (hier: 3) aufeinander folgendes Zeichen drin stehen, die keine Leerzeichen sind:

[^ ]{3,}

Das ist falsch.

Das pattern bezieht sich auf die gesamte Eingabe (so als ob ^ davor und $ danach stehen würde), nicht nur auf einen Teil davon.

Gute Güte! Dann eben:

 .*[^ ]{3,}.*

[Gunnar Bittersmann]

@@Regina Schaukrug

Gute Güte! Dann eben:

 .*[^ ]{3,}.*

Das sagte ich bereits — im Prinzip; nur nicht mit 3 Zeichen, sondern mit einem; und nicht mit Nicht-Leerzeichen, sondern mit Nicht-Whitespace-Zeichen. Ein einsames Tabulator-Zeichen bspw. will man sicher auch nicht zulassen. Aber „um 1 pm“ sicherlich doch; die 3 ist also falsch.

LLAP 🖖

[Regina Schaukrug]

Ein einsames Tabulator-Zeichen bspw. will man sicher auch nicht zulassen.

Mag sein. Aber da mindestens 3 Nichtleerzeichen gefordert sind, müssten das schon mal mindestens 3 Tabulator-Zeichen sein. Und die sind bei einem input dann doch so schwierig einzugeben, dass es nichts macht, wenn die erst bei der serverseitigen Validierung auffallen.

[Gunnar Bittersmann]

@@Regina Schaukrug

Ein einsames Tabulator-Zeichen bspw. will man sicher auch nicht zulassen.

Mag sein. Aber da mindestens 3 Nichtleerzeichen gefordert sind

Ist es das? Wie auch immer, dass deine Umsetzung davon falsch ist, hatte ich in meinem Posting noch nachträglich ergänzt.

LLAP 🖖

[Regina Schaukrug]

dass deine Umsetzung davon falsch ist

Nö.

[Regina Schaukrug]

Aber „um 1 pm“ sicherlich doch; die 3 ist also falsch.

Aus diesem Grund hatte ich geschrieben, er möge die Zahl an seine Ansicht anpassen:

Einfach verlangen, dass irgendwo (also im String/bzw. Input) Deine Ansicht nach genug (hier: 3) aufeinander folgendes Zeichen drin stehen, die keine Leerzeichen sind:

Deswegen ist "falsch" vorliegend falsch.

[Mr. Wolf]

Vielen Dank für die Hilfe vor allem an Regina Schaukrug für die schnelle, geniale Lösung und auch an Gunnar Bittersmann für die Anmerkungen. Ich ahbe das Ganze jetzt mit

pattern=".*[^\s]{1,}.*"

umgesetzt. Der Vorschlag mit den drei Zeichen ist natürlich auch gut, würde aber auch bei 'ab cd ef' zu einer Fehlermeldung führen.

Vielen Dank und Grüße von Wolf

[Gunnar Bittersmann]

@@Mr. Wolf

Vielen Dank für die Hilfe vor allem an Regina Schaukrug für die schnelle, geniale Lösung und auch an Gunnar Bittersmann für die Anmerkungen. Ich ahbe das Ganze jetzt mit pattern=".*[^\s]{1,}.*" umgesetzt.

Das ist genau das, was ich eingangs sagte. Wer hat’s erfunden?

[^\s] kannst du kürzer haben: \S.

{1,} kannst du kürzer haben: +.

LLAP 🖖

[Regina Schaukrug]

Wer hat’s erfunden?

Das kommt immer darauf an, wen man fragt.

Eigentlich die Finnen. Einer hier würde wohl behaupten die Sowjets, wenn nicht Stalin persönlich. Ein israelischer Autor wird wohl behaupten ein besonders strenggläubiger Jude. In China wirst bekommst Du einen Abzug von 2000 Sozialpunkten wenn Du nicht anerkennst, dass eine solche Erfindung nur ein Chinese gemacht haben kann. Gleich hinter der Grenze zum tollsten Land der Welt war es natürlich einer der drei großen Führer, von denen jeder für alle Zeiten der Stärkste, Klügste, Mutigste, Größte und Beste ist. In Saudiarabien wird man sich darauf festlegen, dass es jedenfalls kein Iraner war. Im Iran: "Bei Gott! Kein Sunnit!" Und in Amerika wird Dir Trump schon twittern, dass jede Behauptung, es sei kein Republikaner gewesen, "Fake News" sind.

Aber ich verrate Dir was: Das Geheimnis ist es, eine Erfindung zu verkaufen. Komplizierte Erklärungen sind dabei "längst nicht immer hilfreich".

Und heul nicht. Du hast genug Punkte. Denk an die 2^15-Grenze.

[Gunnar Bittersmann]

@@Regina Schaukrug

Wer hat’s erfunden? Eigentlich die Finnen.

Ich zieh dir gleich dein Handtuch weg.

Und heul nicht. Du hast genug Punkte. Denk an die 2^15-Grenze.

Die gibt’s nicht. The sky is the limit.

LLAP 🖖

[Mr. Wolf]

@Gunnar Bittersmann,

entschuldige bitte, ich hatte nicht begriffen, dass

Dein pattern wäre also: beliebig viele (auch 0) beliebige Zeichen gefolgt von einem Nicht-Whitespace-Zeichen gefolgt von beliebig vielen (auch 0) beliebigen Zeichen.>

der Lösungsweg für mein Problem war. Ich hatte es irrtümlicherweise für eine Einleitung zu 'Wozu braucht man das denn?' gehalten. Mein Fehler.

Also nochmal vielen Dank für die schnelle kompetente Hilfe und noch einen schönen Tag!

Gruß Wolf

[beatovich]

hallo

Guten Tag,

folgendes Problem: Bei der Validierung eines Eingabefeldes mittels 'pattern' möchte ich Buchstaben, Zahlen und Leerzeichen (auch mehrere) zulassen − soweit kein Problem. Ich möchte aber zusätzlich noch verhindern, dass ausschließlich Leerzeichen eingegeben werden. Die serverseitige Validierung mittels php ist bereits realisiert, die Eingabe soll aber bereits vor Absendung kontrolliert werden. Als Workaround würde ich die Eingabe eine Leerzeichens am Anfang ausschließen, mir wäre aber beschriebene Variante lieber.

pattern="\S+(\s\S+)*"

Dieses Pattern stellt sicher, dass nicht mehrere \s nacheinander oder am Ende oder Beginn vorkommen.

[Gunnar Bittersmann]

@@beatovich

pattern="\S+(\s\S+)*"

Dieses Pattern stellt sicher, dass nicht mehrere \s nacheinander oder am Ende oder Beginn vorkommen.

Das war aber nicht die Aufgabe.

Außerdem tut dieses Pattern mehr: Es stellt sicher, dass überhaupt keine \s nacheinander oder am Ende oder Beginn vorkommen.

Das war schon gar nicht die Aufgabe.

LLAP 🖖

[beatovich]

hallo

@@beatovich

pattern="\S+(\s\S+)*"

Dieses Pattern stellt sicher, dass nicht mehrere \s nacheinander oder am Ende oder Beginn vorkommen.

Das war aber nicht die Aufgabe.

wem sagst du das…

Außerdem tut dieses Pattern mehr: Es stellt sicher, dass überhaupt keine \s nacheinander oder am Ende oder Beginn vorkommen.

Das lässt sich ja einfach fixen.

[pl]

hallo

Guten Tag,

pattern="\S+(\s\S+)*"

Dieses Pattern stellt sicher, dass nicht mehrere \s nacheinander oder am Ende oder Beginn vorkommen.

Für sowas gibt es die trim() Funktion. Und danach gucken ob was übriggeblieben ist. z.B. mit length().

Fertig.

[MudGuard]

Hi,

Für sowas gibt es die trim() Funktion. Und danach gucken ob was übriggeblieben ist. z.B. mit length().

und die trim-Funktio rufst Du wie aus dem pattern-Attribut (siehe Aufgabenstellung) auf?

cu,
Andreas a/k/a MudGuard

[Mr. Wolf]

@MudGuard

und die trim-Funktion rufst Du wie aus dem pattern-Attribut (siehe Aufgabenstellung) auf?

Danke, du hast mir die Antwort schon abgenommen. Die serverseitige Validierung (Sicherheitsaspekt) mit trim und length (und noch vielem andern mehr) habe ich ja schon umgesetzt. Ich würde aber die gleiche Validierung auch schon clientseitig (Komfortaspekt) vornehmen wollen. Vielleicht meint 'pl' ja auch trim und length mittels Javascript - darauf wollte ich aber möglichst verzichten.

Einen schönen Tag

Gruß Wolf

[Henry]

Hallo Mr.,

Die serverseitige Validierung (Sicherheitsaspekt) mit trim und length (und noch vielem andern mehr) habe ich ja schon umgesetzt.

Warum nutzt du trim bzw. was erhoffst du damit serverseitig (PHP?) zu erreichen?

Gruss
Henry

[Mr. Wolf]

Hallo Henry,

da hast du recht, trim() ist jetzt nicht unbedingt sicherheitstechnisch relevant. Aber zum einen macht es die weitere Verarbeitung und Ausgabe sauberer, wenn z. B. bei Namen, Zahlen oder auch E-Mailadressen Leerzeichen und dgl. an Anfang und Ende entfernt werden. Zum anderen kann ich so serverseitig erkennen, wenn jemand z. B. aufgrund eines vergessenen Leerzeichens eine sinnlose Eingabe getätigt bzw. ganz diese ganz vergessen hat.

Übrigens, was beatovich weiter unten bemerkt, war genau mein Ziel:

Im Idealfall decken sich serverseitig Prüfung und pattern.>

Gruß Wolf

[Henry]

Hallo Mr.,

da hast du recht, trim() ist jetzt nicht unbedingt sicherheitstechnisch relevant. Aber zum einen macht es die weitere Verarbeitung und Ausgabe sauberer, wenn z. B. bei Namen, Zahlen oder auch E-Mailadressen Leerzeichen und dgl. an Anfang und Ende entfernt werden. Zum anderen kann ich so serverseitig erkennen, wenn jemand z. B. aufgrund eines vergessenen Leerzeichens eine sinnlose Eingabe getätigt bzw. ganz diese ganz vergessen hat.

genau, wollte nur sicher gehen, dass du weist was Trim bewirkt bzw. vermeintlich bewirkt. Zu empfehlen ist trim absolut, nur beim 2. Parameter ist Verständnis geboten. Insofern, alles gut 😉

Gruss
Henry

[pl]

hi

Vielleicht meint 'pl' ja auch trim und length mittels Javascript - darauf wollte ich aber möglichst verzichten.

Solltest Du auch. Weil es unnötiger Aufwand ist, denn eine Prüfung muss grundsätzlich so erfolgen daß sie nicht umgangen werden kann: Serverseitig.

MfG

[marctrix]

Hej pl,

Danke, du hast mir die Antwort schon abgenommen. Die serverseitige Validierung (Sicherheitsaspekt) mit trim und length (und noch vielem andern mehr) habe ich ja schon umgesetzt. Ich würde aber die gleiche Validierung auch schon clientseitig (Komfortaspekt) vornehmen wollen. […] Vielleicht meint 'pl' ja auch trim und length mittels Javascript - darauf wollte ich aber möglichst verzichten.

eine Prüfung muss grundsätzlich so erfolgen daß sie nicht umgangen werden kann: Serverseitig.

Hallo? Jemand zu Hause?!? 😉

Marc

[beatovich]

hallo

Hej pl,

Danke, du hast mir die Antwort schon abgenommen. Die serverseitige Validierung (Sicherheitsaspekt) mit trim und length (und noch vielem andern mehr) habe ich ja schon umgesetzt. Ich würde aber die gleiche Validierung auch schon clientseitig (Komfortaspekt) vornehmen wollen. […] Vielleicht meint 'pl' ja auch trim und length mittels Javascript - darauf wollte ich aber möglichst verzichten.

eine Prüfung muss grundsätzlich so erfolgen daß sie nicht umgangen werden kann: Serverseitig.

Hallo? Jemand zu Hause?!? 😉

Es ist wichtig zwischen Input-Validierung und User-Assistierung zu unterscheiden.

Gute Pattern assistieren den Anwender lediglich, um validen Input zu erreichen.

[marctrix]

Hej beatovich,

Danke, du hast mir die Antwort schon abgenommen. Die serverseitige Validierung (Sicherheitsaspekt) mit trim und length (und noch vielem andern mehr) habe ich ja schon umgesetzt. Ich würde aber die gleiche Validierung auch schon clientseitig (Komfortaspekt) vornehmen wollen. […] Vielleicht meint 'pl' ja auch trim und length mittels Javascript - darauf wollte ich aber möglichst verzichten.

eine Prüfung muss grundsätzlich so erfolgen daß sie nicht umgangen werden kann: Serverseitig.

Hallo? Jemand zu Hause?!? 😉

Es ist wichtig zwischen Input-Validierung und User-Assistierung zu unterscheiden.

Gute Pattern assistieren den Anwender lediglich, um validen Input zu erreichen.

Ja, aber Wolf macht das doch schon vorbildlich! - pl schlägt da eine Verschlimmbesserung vor. Na ist ja auch Wurscht.

Marc

[beatovich]

hallo

Es ist wichtig zwischen Input-Validierung und User-Assistierung zu unterscheiden.

Gute Pattern assistieren den Anwender lediglich, um validen Input zu erreichen.

Ja, aber Wolf macht das doch schon vorbildlich! - pl schlägt da eine Verschlimmbesserung vor. Na ist ja auch Wurscht.

War auch an pl gerichtet.

Ob Wolf das vorbildlich macht, kann ich nicht entscheiden.

Im Idealfall decken sich serverseitig Prüfung und pattern.

[Henry]

Hallo beatovich,

Im Idealfall decken sich serverseitig Prüfung und pattern.

Im Idealfall, bräuchte es keine Trennung zwischen Servers/clientseitig, dank XMLHttpRequest. Wie gesagt Idealfall, muss aber gestehen, dass es mir den Aufwand auch oft nicht wert ist.

Gruss
Henry

[beatovich]

hallo

Im Idealfall decken sich serverseitig Prüfung und pattern.

Im Idealfall, bräuchte es keine Trennung zwischen Servers/clientseitig, dank XMLHttpRequest. Wie gesagt Idealfall, muss aber gestehen, dass es mir den Aufwand auch oft nicht wert ist.

Inwiefern glaubst du, dass XHR dir die serverseitige Prüfung oder browserseitige Assistierung abnimmt?

[Henry]

Hallo beatovich,

Inwiefern glaubst du, dass XHR dir die serverseitige Prüfung oder browserseitige Assistierung abnimmt?

Tut es ja auch nicht, lediglich die Trennung. Die serverseitige ist ein MUSS. Die clientseitige Prüfung (ersetzt durch serveranfrage) hingegen kann simulatan die serverseitige Kontrolle ansprechen und die entsprechende Rückmeldung verarbeiten/anzeigen.

*Nachtrag
Nichts anderes siehst du ja auch bei der (von mir verhassten) automatischen Suchwortvervollständigung bei Suchmaschinen.

Gruss
Henry

[beatovich]

hallo

Hallo beatovich,

Inwiefern glaubst du, dass XHR dir die serverseitige Prüfung oder browserseitige Assistierung abnimmt?

Tut es ja auch nicht, lediglich die Trennung. Die serverseitige ist ein MUSS. Die clientseitige Prüfung hingegen kann simulatan die serverseitige Kontrolle ansprechen und die entsprechende Rückmeldung verarbeiten/anzeigen.

Wie weit soll/darf diese simultane Rückmeldung gehen? Und willst du bei jedem keyup durchführen? inklusive Datenbankabfrage, ob diese Email Adresse bereits registriert ist?

[Henry]

Hallo beatovich,

Wie weit soll/darf diese simultane Rückmeldung gehen?

Hängt vom jeweiligen Forumlar ab.

Und willst du bei jedem keyup durchführen?

Eher beim Verlassen des Feldes oder aktivieren des Nachfolgefeldes oder usw., aber wie schon gesagt hängt vom Forumlar ab, also sehr individuell warum ich mir den Aufwand ja auch nicht jedes mal mache.

inklusive Datenbankabfrage, ob diese Email Adresse bereits registriert ist?

Warum das denn? Würde eine clientseitige Prüfung das machen? Bei den serverseitigen Routinen beachte ich eine Hierarchie, bei der DB-Anfragen erst an letzter Stelle stehen und ein EXIT bereits vorher erfolgt, welche für clientseitig bereits ausreicht.

Gruss
Henry

[beatovich]

hallo

Hallo beatovich,

Wie weit soll/darf diese simultane Rückmeldung gehen?

Hängt vom jeweiligen Forumlar ab.

Und willst du bei jedem keyup durchführen?

Eher beim Verlassen des Feldes oder aktivieren des Nachfolgefeldes oder usw., aber wie schon gesagt hängt vom Forumlar ab, also sehr individuell warum ich mir den Aufwand ja auch nicht jedes mal mache.

inklusive Datenbankabfrage, ob diese Email Adresse bereits registriert ist?

Warum das denn? Würde eine clientseitige Prüfung das machen? Bei den serverseitigen Routinen beachte ich eine Hierarchie, bei der DB-Anfragen erst an letzter Stelle stehen und ein EXIT bereits vorher erfolgt, welche für clientseitig bereits ausreicht.

ja wir müssen den konkreten Fall beachten.

Entscheidend ist, dass Validierung mehr ist als nur formale Datentyp-Überprüfung.

Meiner Meinung nach kann man die Datentypüberprüfung oft einfach mit einem schlichten pattern Attribut vornehmen, manchmal aber auch nur mit etwas javascript.

[Rolf B]

Hallo Mr. Wolf,

ich habe nochmal experimentiert: Das Problem ist mit einer negativen vorausschauenden Zusicherung (negative lookahead-assertion) lösbar:

<input type="text" pattern="(?!^\s+$)[a-zA-Z0-9 ]*">

Das Zusicherungsmuster ^\s+$ ist erfüllt, wenn das Eingabefeld nur Leerstellen (mindestens 1) enthält, und führt dann dazu, dass das Pattern nicht mehr matcht.

Dieses Pattern kannst Du dann auch für die serverseitige Validierung verwenden.

Getestet in Chrome, FF und IE11

Rolf

[Gunnar Bittersmann]

@@Rolf B

<input type="text" pattern="(?!^\s+$)[a-zA-Z0-9 ]*">

Nö!

LLAP 🖖

[Mr. Wolf]

Hallo Gunnar,

erklärst du mir (Anfänger) bitte den Fehler an Rolfs Lösung? In diese Richtung hatte ich nämlich auch experimentiert, allerdings mit weniger Erfolg als Rolf.

Danke!

Gruß Wolf

[Gunnar Bittersmann]

@@Mr. Wolf

erklärst du mir (Anfänger) bitte den Fehler an Rolfs Lösung?

Meine Antwort war selbsterklärend. 😉

Versuch sie doch mal als Eingabe!

LLAP 🖖

[Rolf B]

Hallo Gunnar,

okay okay, ich bin in die ASCII-Falle getappt. Die „große“ Unicode-Version wäre

[\p{L}\p{Nd}\s] statt [a-zA-Z0-9 ].

Wobei sich bei \p{Nd} die Frage stellt, wie weit Mr. Wolf das serverseitig verarbeiten kann. Keine Ahnung, was da noch alles außer [0-9] hinzukommt.

Und es stellt sich die Frage, ob er alle Buchstaben dieser Welt verarbeiten kann und will. Vielleicht wäre \p{Latin} besser.

Mangels thailändischer oder georgischer Tastatur mag ich allerdings nicht per Zeichentabelle testen, wie weit das im Brauser funktioniert.

Rolf

[beatovich]

hallo

Und es stellt sich die Frage, ob er alle Buchstaben dieser Welt verarbeiten kann und will. Vielleicht wäre \p{Latin} besser...

Wir müssen die auf dem Server angwendeten Methoden erfahren.

Ich glaube bis hierher war mein Ansatz nicht der schlechteste.

[Mr. Wolf]

Hallo Gunnar, hallo Rolf,

mir war schon klar, dass ich bei Rolfs Beispiel noch [a-zA-Z0-9 ] für Umlaute etc. erweitern muss. Mir schwebt übrigens für Vor- und Zunamen [a-zA-ZäöüÄÖÜßáé-\s] bzw. für Ortsnamen (Deutschland) [a-zA-ZäöüÄÖÜß()-\s] vor.

Dank an euch beide!

Gruß Wolf

PS @Gunnar Bittersmann: Kann sein, dass du ein sehr exakter Mensch bist, welcher gern um die Ecke denkt? Das ist natürlich als Kompliment gemeint.

[beatovich]

hallo

Hallo Gunnar, hallo Rolf,

mir war schon klar, dass ich bei Rolfs Beispiel noch [a-zA-Z0-9 ] für Umlaute etc. erweitern muss. Mir schwebt übrigens für Vor- und Zunamen [a-zA-ZäöüÄÖÜßáé-\s] bzw. für Ortsnamen (Deutschland) [a-zA-ZäöüÄÖÜß()-\s] vor.

Denke daran dass in Deutschland auch Menschen mit sehr undeutschen Namen leben. Wie das mit Ortsnamen ist, wird die Zukunft zeigen.

Sei liberal mit Angaben.

[Mr. Wolf]

Hallo Beat,

da hast du sicherlich recht. Aber was wäre die Alternative? Alles zulassen?

Gruß Wolf

PS: Mir ist gerade aufgefallen, dass bei den Ortsname noch ein / fehlt. Zum Beispiel wegen der Menschen in Frankfurt...

[beatovich]

hallo

Hallo Beat,

da hast du sicherlich recht. Aber was wäre die Alternative? Alles zulassen?

Nein, ich finde Trim sehr zulässig

Ich kann mir auch nicht vorstellen, dass Namen 2 oder mehr aufeinander folgende Whitespace Character enthalten.

Gewiss kann man Längengrenzen vorsehen, nur denke man da an das längst mögliche, dass man sich ausdenken kann und multipliziere es dann mal 2.

PS: Mir ist gerade aufgefallen, dass bei den Ortsname noch ein / fehlt. Zum Beispiel wegen der Menschen in Frankfurt...

Wie wichtig ist denn die Validität der Angaben? Ich kann nämlich auch bei [A-Za-z]+ den Ortsnamen Nafzenschlutzelingen angeben.

[dedlfix]

Tach!

Ich kann mir auch nicht vorstellen, dass Namen 2 oder mehr aufeinander folgende Whitespace Character enthalten.

Eigentlich enthalten sie gar keine Leerzeichen. Leerzeichen sind nur ein technisches Hilfskonstrukt, um Abstand zwischen Namensbestandteilen zu kennzeichnen, die nicht zusammengeschrieben werden.

dedlfix.

[beatovich]

hallo

Tach!

Ich kann mir auch nicht vorstellen, dass Namen 2 oder mehr aufeinander folgende Whitespace Character enthalten.

Eigentlich enthalten sie gar keine Leerzeichen. Leerzeichen sind nur ein technisches Hilfskonstrukt, um Abstand zwischen Namensbestandteilen zu kennzeichnen, die nicht zusammengeschrieben werden.

Vielleicht, vielleicht auch nicht. Was weiss ich über andere Sprachen und Kulturen.

[dedlfix]

Tach!

Eigentlich enthalten sie gar keine Leerzeichen. Leerzeichen sind nur ein technisches Hilfskonstrukt, um Abstand zwischen Namensbestandteilen zu kennzeichnen, die nicht zusammengeschrieben werden.

Vielleicht, vielleicht auch nicht. Was weiss ich über andere Sprachen und Kulturen.

Die werden sich nicht erst seit der Erfindung des Computers entwickelt haben. Auch da wird man kein Zeichen haben, das unausgefüllten Abstand repräsentiert. Und wenn doch, wird es kaum als U+0020 repräsentiert werden, sondern als separates Zeichen im Block für diese Schriftsysteme.

dedlfix.

[beatovich]

hallo

Tach!

Eigentlich enthalten sie gar keine Leerzeichen. Leerzeichen sind nur ein technisches Hilfskonstrukt, um Abstand zwischen Namensbestandteilen zu kennzeichnen, die nicht zusammengeschrieben werden.

Vielleicht, vielleicht auch nicht. Was weiss ich über andere Sprachen und Kulturen.

Die werden sich nicht erst seit der Erfindung des Computers entwickelt haben. Auch da wird man kein Zeichen haben, das unausgefüllten Abstand repräsentiert. Und wenn doch, wird es kaum als U+0020 repräsentiert werden, sondern als separates Zeichen im Block für diese Schriftsysteme.

Also für unsichtbare (oder visuell identische) Zeichen den richtigen Unicode Punkt verwenden, das dürfen Typographen üben.

Formular-User möchte ich nicht mit sowas belasten

[Matthias Apsel]

Hallo Mr. Wolf,

Aber was wäre die Alternative? Alles zulassen?

Ja. Es gibt bei der Eingabe von Namen keinen Grund für ein Pattern. Stell dir vor, du kannst deinen Namen nicht eingeben, weil der Ersteller der Seite irgendeine Besonderheit nicht beachtet hat. Dieser Frust ist vermeidbar.

00000 gibt es etwa als deutsche Postleitzahl, es soll Seiten geben, die eine solche Eingabe nicht zulassen.

Jedes Pattern erzeugt Frust.

Bis demnächst
Matthias

[dedlfix]

Tach!

00000 gibt es etwa als deutsche Postleitzahl, es soll Seiten geben, die eine solche Eingabe nicht zulassen.

Definiere "geben". Soweit ich gelesen habe, gibt es einen Fleck, der hat keine offizielle Postleitzahl, und die 00000 ist nur eine Notlösung, weil man ein Pflichtfeld auszufüllen hatte.

dedlfix.

[Gunnar Bittersmann]

@@Mr. Wolf

PS: Mir ist gerade aufgefallen, dass bei den Ortsname noch ein / fehlt. Zum Beispiel wegen der Menschen in Frankfurt...

Die offizielle Schreibweise ist mit Klammern: Frankfurt (Oder).

LLAP 🖖

[Gunnar Bittersmann]

@@Mr. Wolf

mir war schon klar, dass ich bei Rolfs Beispiel noch [a-zA-Z0-9 ] für Umlaute etc. erweitern muss.

Wenn du an „erweitern“ denkst, bin ich mir ziemlich sicher, dass du bei „etc.“ irgendwas vergisst.

Mir schwebt übrigens für Vor- und Zunamen [a-zA-ZäöüÄÖÜßáé-\s]

Ayşe Bayramoğlu und Łukasz Szymański würden ihre Namen sicher auch gerne richtig schreiben.

bzw. für Ortsnamen (Deutschland) [a-zA-ZäöüÄÖÜß()-\s] vor.

Chóśebuz, Budyšin?

Kann sein, dass du ein sehr exakter Mensch bist, welcher gern um die Ecke denkt?

Beyond tellerrand, immer gerne.

Das ist natürlich als Kompliment gemeint.

Danke.

LLAP 🖖

[Rolf B]

Hallo Gunnar,

also doch \p{Latin}

Rolf

[Gunnar Bittersmann]

@@Rolf B

also doch \p{Latin}

Wenn man Иван Царевич seinen Namen nicht in kyrillischen Buchstaben eingeben lassen möchte …

LLAP 🖖

[Mr. Wolf]

Hallo Gunnar, hallo Beat,

gut bei den Namen ist dein Einwand sicher berechtigt. Was hältst du übrigens z. B. von \s+$)[A-zÀ-ž\s\-\.]{1,30} für den Vornamen? Damit hätte ich vom lateinischen Zeichensatz neben der Basis einen großen Teil der Ergänzung 1 sowie die Erweiterung A zugelassen.

Die Längenbegrenzung ist notwendig, da der Name später in ein Schriftstück eingetragen werden soll. Wenn nun der Herr zu Guttenberg auf der Website vorbeischaut (und alle seine Vornamen eingeben will), hat er eben Pech.

Bei den Ortsnamen folge ich dir nicht unbedingt. Selbst die traditionsbewussten sorbischen Einwohner von Chóśebuz und Budyšin sind sicherlich gewohnt bei Ihrer Postanschrift Cottbus bzw. Bautzen anzugeben.

Mein Problem mit dem "alles zulassen" ist aber die fehlende Kontrolle. Bei [a-zA-ZäöüÄÖÜßáé ] kann ich noch problemlos ausprobieren, ob dann mein php-Interpreter damit klarkommt. Beim kompletten lateinischen Zeichensatz ist das schon etwas mehr Aufwand…

Gruß Wolf

[Gunnar Bittersmann]

@@Mr. Wolf

gut bei den Namen ist dein Einwand sicher berechtigt. Was hältst du übrigens z. B. von \s+$)[A-zÀ-ž\s\-\.]{1,30} für den Vornamen?

Abgesehen davon, dass am Anfang was mit dem regulären Ausdruck nicht stimmt: Weder Triết noch Lương werden angenommen (das gibt diplomatische Verwicklungen!); auch nicht Kuʻulei und Leināʻala.

Damit hätte ich vom lateinischen Zeichensatz neben der Basis einen großen Teil der Ergänzung 1 sowie die Erweiterung A zugelassen.

Ich sag doch, dass du was vergisst.

Die Längenbegrenzung ist notwendig, da der Name später in ein Schriftstück eingetragen werden soll. Wenn nun der Herr zu Guttenberg auf der Website vorbeischaut (und alle seine Vornamen eingeben will), hat er eben Pech.

Oder der Designer des Schriftstücks hat Mist gebaut.

Was ist das für ein Schriftstück? Warum willst du überhaupt prüfen, was für Zeichen im Namen sind? Wenn Kim Seulgi ihren Namen (Kim ist der Familienname, Seulgi der Vorname) als 김슬기 angeben will, warum soll sie das nicht tun dürfen?

Mein Problem mit dem "alles zulassen" ist aber die fehlende Kontrolle. Bei [a-zA-ZäöüÄÖÜßáé] kann ich noch problemlos ausprobieren, ob dann mein php-Interpreter damit klarkommt. Beim kompletten lateinischen Zeichensatz ist das schon etwas mehr Aufwand…

?? Wieso sollte? Und wenn ein System mit Unicode nicht klarkommt, wäre der Fehler im System zu beheben.

LLAP 🖖

[dedlfix]

Tach!

Wenn Kim Seulgi ihren Namen (Kim ist der Familienname, Seulgi der Vorname) als 김슬기 angeben will, warum soll sie das nicht tun dürfen?

Es kommt auf den Anwendungsfall an. Was nützt zum Beispiel in einer internationalen Unternehmung ein globales Adressverzeichnis, wenn du einen Teil der Leute nicht finden kannst, weil du ihre Zeichen nicht lesen und eingeben kannst? Versuch dafür mal eine Lösung zu finden, mit der alle leben können, inklusive der Finanzabteilung. Da ist meistens das kleinere Übel, wenn man lateinisierte Namen nimmt. Zumindest wenn der Hauptteil der Kommunikation über Englisch läuft.

Was ist eigentlich der Anwendungsfall, auf den die gesuchte Lösung passen soll?

dedlfix.

[Gunnar Bittersmann]

@@dedlfix

Wenn Kim Seulgi ihren Namen (Kim ist der Familienname, Seulgi der Vorname) als 김슬기 angeben will, warum soll sie das nicht tun dürfen? Es kommt auf den Anwendungsfall an. Was nützt zum Beispiel in einer internationalen Unternehmung ein globales Adressverzeichnis, wenn du einen Teil der Leute nicht finden kannst, weil du ihre Zeichen nicht lesen und eingeben kannst?

Das mit dem Finden könnte etwas schwieriger werden. 김 wird gemeinhin als Kim romanisiert, nicht als Gim. 슬기 könnte aber Seulgi, Seulki, Sulgi oder Sulki geschrieben werden.

LLAP 🖖

[MudGuard]

Hi,

mir war schon klar, dass ich bei Rolfs Beispiel noch [a-zA-Z0-9 ] für Umlaute etc. erweitern muss. Mir schwebt übrigens für Vor- und Zunamen [a-zA-ZäöüÄÖÜßáé-\s] bzw. für Ortsnamen (Deutschland) [a-zA-ZäöüÄÖÜß()-\s] vor.

André aus Hann. Münden wird dagegen sein.

cu,
Andreas a/k/a MudGuard

[Mr. Wolf]

Vielen Dank an alle dir sich etwas Zeit für mein Problem genommen haben, für die schnelle Hilfe aber auch die umfangreichen Anmerkungen zum Thema. Ich hätte nicht gedacht das eine vergleichsweise einfache Frage gleich 60 Beiträge zur Folge haben kann. 😊

Ihr habt mir aber sehr weitergeholfen.

Gruß Wolf