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

0 63

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

Mr. Wolf
  • formulare
  • html
  1. 0
    Gunnar Bittersmann
    1. 0
      Mr. Wolf
      1. 0
        marctrix
      2. 1
        Regina Schaukrug
        1. 0
          Gunnar Bittersmann
          1. 0
            Regina Schaukrug
            1. 0
              Gunnar Bittersmann
              1. 0
                Regina Schaukrug
                1. 0
                  Gunnar Bittersmann
                  1. 0
                    Regina Schaukrug
              2. 0
                Regina Schaukrug
            2. 0
              Mr. Wolf
              1. 0
                Gunnar Bittersmann
                1. 0

                  Zu: Wer hat’s erfunden?

                  Regina Schaukrug
                  1. 0
                    Gunnar Bittersmann
                    • menschelei
                2. 0
                  Mr. Wolf
  2. 0
    beatovich
    1. 0
      Gunnar Bittersmann
      1. 0
        beatovich
    2. 0
      pl
      1. 0
        MudGuard
        1. 0
          Mr. Wolf
          1. 0
            Henry
            1. 0
              Mr. Wolf
              1. 0
                Henry
          2. 0
            pl
            1. 0
              marctrix
              1. 0
                beatovich
                1. 0
                  marctrix
                  1. 0
                    beatovich
                    1. 0
                      Henry
                      1. 0
                        beatovich
                        1. 0
                          Henry
                          1. 0
                            beatovich
                            1. 0
                              Henry
                              1. 0
                                beatovich
  3. 0
    Rolf B
    1. 0
      Gunnar Bittersmann
      1. 0
        Mr. Wolf
        1. 0
          Gunnar Bittersmann
      2. 0
        Rolf B
        1. 0
          beatovich
        2. 0
          Mr. Wolf
          1. 0
            beatovich
            1. 0
              Mr. Wolf
              1. 0
                beatovich
                1. 0
                  dedlfix
                  1. 0
                    beatovich
                    1. 0
                      dedlfix
                      1. 0
                        beatovich
              2. 0
                Matthias Apsel
                1. 0
                  dedlfix
              3. 0
                Gunnar Bittersmann
          2. 0
            Gunnar Bittersmann
            1. 0
              Rolf B
              1. 0
                Gunnar Bittersmann
            2. 0
              Mr. Wolf
              1. 0
                Gunnar Bittersmann
                1. 0
                  dedlfix
                  1. 0
                    Gunnar Bittersmann
          3. 0
            MudGuard
  4. 2

    Danke!

    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

akzeptierte Antworten

  1. @@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 🖖

    --
    „Wer durch Wissen und Erfahrung der Klügere ist, der sollte nicht nachgeben. Und nicht aufgeben.“ —Kurt Weidemann
    1. @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.

      1. 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

      2. 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...

        1. @@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 🖖

          --
          „Wer durch Wissen und Erfahrung der Klügere ist, der sollte nicht nachgeben. Und nicht aufgeben.“ —Kurt Weidemann
          1. 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,}.*
            
            1. @@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 🖖

              --
              „Wer durch Wissen und Erfahrung der Klügere ist, der sollte nicht nachgeben. Und nicht aufgeben.“ —Kurt Weidemann
              1. 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.

                1. @@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 🖖

                  --
                  „Wer durch Wissen und Erfahrung der Klügere ist, der sollte nicht nachgeben. Und nicht aufgeben.“ —Kurt Weidemann
                  1. dass deine Umsetzung davon falsch ist

                    .

              2. 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.

            2. 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

              1. @@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 🖖

                --
                „Wer durch Wissen und Erfahrung der Klügere ist, der sollte nicht nachgeben. Und nicht aufgeben.“ —Kurt Weidemann
                1. 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.

                  1. @@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 🖖

                    --
                    „Wer durch Wissen und Erfahrung der Klügere ist, der sollte nicht nachgeben. Und nicht aufgeben.“ —Kurt Weidemann
                2. @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

  2. 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.

    1. @@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 🖖

      --
      „Wer durch Wissen und Erfahrung der Klügere ist, der sollte nicht nachgeben. Und nicht aufgeben.“ —Kurt Weidemann
      1. 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.

    2. 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.

      1. 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

        1. @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

          1. 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

            --
            Meine Meinung zu DSGVO & Co:
            „Principiis obsta. Sero medicina parata, cum mala per longas convaluere moras.“
            1. 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

              1. 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

                --
                Meine Meinung zu DSGVO & Co:
                „Principiis obsta. Sero medicina parata, cum mala per longas convaluere moras.“
          2. 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

            1. 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

              1. 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.

                1. 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

                  1. 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.

                    1. 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

                      --
                      Meine Meinung zu DSGVO & Co:
                      „Principiis obsta. Sero medicina parata, cum mala per longas convaluere moras.“
                      1. 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?

                        1. 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

                          --
                          Meine Meinung zu DSGVO & Co:
                          „Principiis obsta. Sero medicina parata, cum mala per longas convaluere moras.“
                          1. 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?

                            1. 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

                              --
                              Meine Meinung zu DSGVO & Co:
                              „Principiis obsta. Sero medicina parata, cum mala per longas convaluere moras.“
                              1. 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.

  3. 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

    --
    sumpsi - posui - clusi
    1. @@Rolf B

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

      Nö!

      LLAP 🖖

      --
      „Wer durch Wissen und Erfahrung der Klügere ist, der sollte nicht nachgeben. Und nicht aufgeben.“ —Kurt Weidemann
      1. 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

        1. @@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 🖖

          --
          „Wer durch Wissen und Erfahrung der Klügere ist, der sollte nicht nachgeben. Und nicht aufgeben.“ —Kurt Weidemann
      2. 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

        --
        sumpsi - posui - clusi
        1. 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.

        2. 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.

          1. 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.

            1. 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...

              1. 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.

                1. 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.

                  1. 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.

                    1. 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.

                      1. 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

              2. 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

                --
                Rosen sind rot.
                1. 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.

              3. @@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 🖖

                --
                „Wer durch Wissen und Erfahrung der Klügere ist, der sollte nicht nachgeben. Und nicht aufgeben.“ —Kurt Weidemann
          2. @@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 🖖

            --
            „Wer durch Wissen und Erfahrung der Klügere ist, der sollte nicht nachgeben. Und nicht aufgeben.“ —Kurt Weidemann
            1. Hallo Gunnar,

              also doch \p{Latin}

              Rolf

              --
              sumpsi - posui - clusi
              1. @@Rolf B

                also doch \p{Latin}

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

                LLAP 🖖

                --
                „Wer durch Wissen und Erfahrung der Klügere ist, der sollte nicht nachgeben. Und nicht aufgeben.“ —Kurt Weidemann
            2. 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

              1. @@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 🖖

                --
                „Wer durch Wissen und Erfahrung der Klügere ist, der sollte nicht nachgeben. Und nicht aufgeben.“ —Kurt Weidemann
                1. 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.

                  1. @@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 🖖

                    --
                    „Wer durch Wissen und Erfahrung der Klügere ist, der sollte nicht nachgeben. Und nicht aufgeben.“ —Kurt Weidemann
          3. 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

  4. 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