Ilja: regulärer Ausdruck

moin,

ich suche einen regulären ausdruck, der prüft, ob eine string aus werten zwischen 01 und 49 besteht (Lottozahlen). führende 0 sollten vorkommen, müssen aber nicht zwangsweise. also an der ersten stelle zahlen von 0-4 und die zweite zahlen von 0-9. allerdings darf die 00 nicht vorkommen. was ich bisher habe ist das :

^[[:digit:]]{1,2}$

allerdings prüft das nur auf zwei zahlen ganz allgemein und danach frage ich noch ab, ob sie zwischen 1 und 49 liegen in einem extra ausdruck, was ich als nicht so elegant empfinde. hat jemand für mich eine lösung, wie ich das beides schon im regulären ausdruck abfackeln kann ?

Ilja

  1. Hi Ilja!

    Reicht dir eine wörtliche Beschreibung?

    ( optionale [0] gefolgt von [1-9] ) OR ( [1-4] gefolgt von [0-9] )

    MfG H☼psel

    Selfcode: ie:% fl:( br:> va:) ls:& fo:) rl:? n4:& ss:| de:] js:| ch:? sh:( mo:) zu:)

    -- "It's amazing I won. I was running against peace, prosperity, and incumbency."
    George W. Bush speaking to Swedish Prime Minister unaware a live television camera was still rolling, June 14, 2001
    1. Hi Ingrid!

      ( optionale [0] gefolgt von [1-9] ) OR ( [1-4] gefolgt von [0-9] )

      Vergiss das mal ganz schnell wieder.

      Die beiden anderen haben natürlich Recht!

      Aber ich bin ja auch nur die Putze... =)

      MfG H☼psel

      Selfcode: ie:% fl:( br:> va:) ls:& fo:) rl:? n4:& ss:| de:] js:| ch:? sh:( mo:) zu:)

      -- "It's amazing I won. I was running against peace, prosperity, and incumbency."
      George W. Bush speaking to Swedish Prime Minister unaware a live television camera was still rolling, June 14, 2001
      1. moin hopsel,

        falls du noch den genauen regulären ausdruck für mich hast, würde mir helfen. oftmals ist die putze nützlicher als die architekten....

        Ilja

        1. Hi Ilja!

          falls du noch den genauen regulären ausdruck für mich hast, [...]

          So z. B.:
          ^(?:(?:0?[1-9])|(?:[1-4][0-9]))$

          MfG H☼psel

          Selfcode: ie:% fl:( br:> va:) ls:& fo:) rl:? n4:& ss:| de:] js:| ch:? sh:( mo:) zu:)

          -- "It's amazing I won. I was running against peace, prosperity, and incumbency."
          George W. Bush speaking to Swedish Prime Minister unaware a live television camera was still rolling, June 14, 2001
  2. Hi,

    ich suche einen regulären ausdruck, der prüft, ob eine string aus werten zwischen 01 und 49 besteht (Lottozahlen).

    warum willst Du hierzu ausgerechnet eine Regular Expression verwenden? Das ist überhaupt kein Anwendungsfall dazu. Wertebereiche sind keine Muster.

    was ich bisher habe ist das :
    ^[[:digit:]]{1,2}$

    Abgesehen davon, dass "[[:digit:]]" der Steinzeit entstammt und sich in Wirklichkeit "\d" schreibt: Damit hast Du eine formale Prüfung, ob der gegebene Wert theoretisch die Anforderungen erfüllen kann. Ob diese Prüfung notwendig ist, darfst Du selbst entscheiden; denn mit und ohne sie wirst Du anschließend völlig identisch vorgehen: Wert in Zahl umwandeln, Zahl mit Wertebereich vergleichen.

    hat jemand für mich eine lösung, wie ich das beides schon im regulären ausdruck abfackeln kann ?

    Frage erst nach Regular Expressions, wenn Du ein _Muster_ suchst. Du haust Dir ja auch nicht prophylaktisch mit dem Hammer auf die Hand, bevor Du ermittelt hast, ob Du mit einem Nagel oder einer Schraube arbeitest. Oder?

    Cheatah

    --
    X-Self-Code: sh:( fo:} ch:~ rl:| br:> n4:& ie:% mo:) va:) de:] zu:) fl:{ ss:) ls:~ js:|
    X-Self-Code-Url: http://emmanuel.dammerer.at/selfcode.html
    X-Will-Answer-Email: No
    X-Please-Search-Archive-First: Absolutely Yes

  3. Reguläre Ausdrücke sind keine vernünftige Lösung für irreguläre Probleme.
    Zahlenwerte ermittelt man am Besten, indem man nach Zahlenwerten sucht. In JavaScript würdest Du bspw. parseInt(string, 10) verwenden - bitte die Zahlenbasis nicht vergessen, weil sonst "08" bzw. "09" einen Fehler auslösen, da sie nicht als Oktalzahlen erkannt werden können. Nun brauchst Du nur noch 3 Abfragen:

    • !isNaN(zahl)
    • zahl > 0
    • zahl < 50

    Bekommst Du das in der Sprache, die Du verwendest, hin?

    Gruß, LX

    -- RFC 1925, Satz 8: Es ist komplizierter als man denkt.
    1. Reguläre Ausdrücke sind keine vernünftige Lösung für irreguläre Probleme.

      Nur als Anmerkung: Das gestellte Problem ist kein irreguläres (im Sinne von nicht-regulär also mindestens kontextfrei). Es existiert also sehr wohl ein („vernünftiger“) regulärer Ausdruck für das Problem.

  4. ich antworte mal allen hier. noch kurz zum verstädnis, es geht um SQL. in eine zahl umwandeln und dann mit dem wertebereich von 1 - 49 prüfen geht nicht, da dies auf 1,5 auch zutreffen würde.

    Ilja

    1. Hi,

      ich antworte mal allen hier. noch kurz zum verstädnis, es geht um SQL. in eine zahl umwandeln und dann mit dem wertebereich von 1 - 49 prüfen geht nicht, da dies auf 1,5 auch zutreffen würde.

      dann ist es zunächst einmal sehr, sehr verwunderlich, dass in dem Datenfeld überhaupt andere Werte stehen können. Nachdem (und *erst* nachdem) Du bewiesen hast, dass hieran keine Änderung möglich ist, kannst Du genau das tun, was Dir bereits vorgeschlagen wurde: auf die formale Prüfung einen Vergleich mit dem Wertebereich folgen lassen.

      Cheatah

      --
      X-Self-Code: sh:( fo:} ch:~ rl:| br:> n4:& ie:% mo:) va:) de:] zu:) fl:{ ss:) ls:~ js:|
      X-Self-Code-Url: http://emmanuel.dammerer.at/selfcode.html
      X-Will-Answer-Email: No
      X-Please-Search-Archive-First: Absolutely Yes

      1. moin,

        dann ist es zunächst einmal sehr, sehr verwunderlich, dass in dem Datenfeld überhaupt andere Werte stehen können.

        ist einfach und schnell erklärt, die daten kommen von aussen, ich habe also keine kontrolle darüber, was im dem feld steht, aber ich muss prüfen, ob das richtige dort steht.

        ich stehe ein wenig vor dem problem, in SQL zu prüfen, ob der String ein INTEGER wert ist, ohne das mit die Abfrage um die ohren fliegt. ich müsste mir dazu eine funktion bauen, was natürlich möglich ist, dachte aber mit regulären ausdruck wäre es einfacher.

        Ilja

        1. Hi,

          ist einfach und schnell erklärt, die daten kommen von aussen, ich habe also keine kontrolle darüber, was im dem feld steht,

          Datentyp und ggf. Constraints helfen hierbei.

          ich stehe ein wenig vor dem problem, in SQL zu prüfen, ob der String ein INTEGER wert ist, ohne das mit die Abfrage um die ohren fliegt.

          Das "um die Ohren fliegen" nennt sich Exception und ist eine Möglichkeit, die Du nutzen kannst.

          [...] dachte aber mit regulären ausdruck wäre es einfacher.

          Jupp.

          Cheatah

          --
          X-Self-Code: sh:( fo:} ch:~ rl:| br:> n4:& ie:% mo:) va:) de:] zu:) fl:{ ss:) ls:~ js:|
          X-Self-Code-Url: http://emmanuel.dammerer.at/selfcode.html
          X-Will-Answer-Email: No
          X-Please-Search-Archive-First: Absolutely Yes

          1. moin,

            Datentyp und ggf. Constraints helfen hierbei.

            nein, das geht nicht und wäre eine schlechte lösung. die daten sollen in das system rein, egal ob mit falschen oder richtigen werten. danach erfolgt erst die prüfung auf richtigkeit und darum geht es gerade.

            Das "um die Ohren fliegen" nennt sich Exception und ist eine Möglichkeit, die Du nutzen kannst.

            klar, es geht mit exception, aber dafür muss ich dann eine extra funktion bauen, in der die exception auftritt. und ich könnte mir das einfach mit einem regulären ausdruck sparen.

            Ilja

            1. Hi,

              klar, es geht mit exception, aber dafür muss ich dann eine extra funktion bauen, in der die exception auftritt. und ich könnte mir das einfach mit einem regulären ausdruck sparen.

              auf die Gefahr hin, mich zu wiederholen: Jupp.

              Cheatah

              --
              X-Self-Code: sh:( fo:} ch:~ rl:| br:> n4:& ie:% mo:) va:) de:] zu:) fl:{ ss:) ls:~ js:|
              X-Self-Code-Url: http://emmanuel.dammerer.at/selfcode.html
              X-Will-Answer-Email: No
              X-Please-Search-Archive-First: Absolutely Yes

              1. moin,

                auf die Gefahr hin, mich zu wiederholen: Jupp.

                hmm, habe es jetzt mit der Funktion und der Exception gemacht, aber mir gefällt eben nicht, dass es jetzt zwei schritte sind. liegt aber wohl in der natur der sache

                Ilja

                1. Hi,

                  hmm, habe es jetzt mit der Funktion und der Exception gemacht, aber mir gefällt eben nicht, dass es jetzt zwei schritte sind. liegt aber wohl in der natur der sache

                  ich sehe das Problem in dem Umstand, dass Daten ungefiltert in die DB gespeichert werden. Hier hätte bereits eine Prüfung geschehen müssen.

                  Cheatah

                  --
                  X-Self-Code: sh:( fo:} ch:~ rl:| br:> n4:& ie:% mo:) va:) de:] zu:) fl:{ ss:) ls:~ js:|
                  X-Self-Code-Url: http://emmanuel.dammerer.at/selfcode.html
                  X-Will-Answer-Email: No
                  X-Please-Search-Archive-First: Absolutely Yes

                  1. moin,

                    ich sehe das Problem in dem Umstand, dass Daten ungefiltert in die DB gespeichert werden. Hier hätte bereits eine Prüfung geschehen müssen.

                    das ist gewollt und ein feature und kein problem.

                    Ilja

                    1. Hi,

                      ich sehe das Problem in dem Umstand, dass Daten ungefiltert in die DB gespeichert werden. Hier hätte bereits eine Prüfung geschehen müssen.

                      das ist gewollt und ein feature und kein problem.

                      doch, ist es. Die eintreffenden Daten persistent zu speichern ist etwas anderes, als die (interpretierten) Lottozahlen daraus bereit zu stellen.

                      Cheatah

                      --
                      X-Self-Code: sh:( fo:} ch:~ rl:| br:> n4:& ie:% mo:) va:) de:] zu:) fl:{ ss:) ls:~ js:|
                      X-Self-Code-Url: http://emmanuel.dammerer.at/selfcode.html
                      X-Will-Answer-Email: No
                      X-Please-Search-Archive-First: Absolutely Yes

                      1. moin,

                        doch, ist es. Die eintreffenden Daten persistent zu speichern ist etwas anderes, als die (interpretierten) Lottozahlen daraus bereit zu stellen.

                        ungefilfert müssen die daten sowieso in die datenbank rein, es macht wenig sinn, gleich einen filter anzusetzen, wenn ich sie eh alle haben will. oder wo liegt das problem ?

                        Ilja

                        1. Hi,

                          doch, ist es. Die eintreffenden Daten persistent zu speichern ist etwas anderes, als die (interpretierten) Lottozahlen daraus bereit zu stellen.

                          ungefilfert müssen die daten sowieso in die datenbank rein

                          darunter verstehe ich ein Log. Warum führst du das nicht separat? Und nach erfolgreicher Prüfung kommen die Daten halt zusätzlich in die Auswertung. Die Daten ständig aus dem Log zu pflücken halte ich ebenfalls nicht für guten Stil.

                          Gruß,
                          Andreas.

                          1. moin,

                            darunter verstehe ich ein Log. Warum führst du das nicht separat? Und nach erfolgreicher Prüfung kommen die Daten halt zusätzlich in die Auswertung. Die Daten ständig aus dem Log zu pflücken halte ich ebenfalls nicht für guten Stil.

                            das ist doch schall und rauch, ob ich es nun log nenne oder dem kind einem anderen namen gebe. und ich denke du hast eine falsche vorstellung, vom dem was passiert. die "log" daten werden später nur noch für reports der importe benutzt. ich würde es nicht log nennen, weil es komplett den bereich importe abdeckt, also in gewisser weise über ein logging hinaus geht. bei uns ist das eben das import modul.

                            was passiert ist, dass die daten für den operativen bereich getrennt vorliegen, sogar unter einem anderen benutzer verwaltet werden. und genau darum ging es mir, es erfolgen diverse prüfungen, welche daten von der gesamtheit des import prozess den weg bis zum ziel schaffen in den operativen bereich hinein. dort werden sie dann persistiert, also nicht jedesmal wieder auf das import modul zurück gegriffen. und die vorgaben für den operativen bereich sind eben wesentlich restriktiver. in diesem falle eine zweistellige zahl von 1 bis 49 mit führender null (streng genommen ein string aus zwei zeichen nur mit den zahlen als domäne).

                            Ilja

                            1. Hi Ilja,

                              konnte ich ja nicht wissen, weil du etwas weiter oben auf die Antwort von Cheatah

                              [...], als die (interpretierten) Lottozahlen daraus bereit zu stellen.

                              noch nicht erklärt hast, dass die Daten getrennt vorliegen (sollen). Aber egal, jetzt habe ich es verstanden. Der reguläre Ausdruck für dein Problem könnte etwa so aussehen:

                              /^0?[1-9]$|^[1-4][0-9]$/

                              / Delimiter
                              ^ Stringanfang
                              0?[1-9] optionale 0 gefolgt von 1-9
                              $ Stringende
                              | alternativ
                              ^ Stringanfang
                              [1-4][0-9] 1-4 gefolgt von 0-9
                              $ Stringende
                              / Delimiter

                              Gruß,
                              Andreas.

                              1. moin Andreas,

                                /^0?[1-9]$|^[1-4][0-9]$/

                                das hilft mir, vor allem mit der schönen legende, danke dir.

                                Ilja

            2. Hi Ilja.

              die daten sollen in das system rein, egal ob mit falschen oder richtigen werten.

              Das heisst, die Eingabe wird als String gespeichert, egal, wie sie aussieht? Dann ist die Pruefung keine Pruefung auf einen Wertebereich, sondern eine Syntax-Pruefung eines Strings, und es spricht nichts gegen Regular Expressions zur Validierung.

              Aber mal zwei neugierige Fragen:

              1.: Warum sollen

              die daten [...] in das system rein, egal ob mit falschen oder richtigen werten

              ?

              2.:

              danach erfolgt erst die prüfung auf richtigkeit [...].

              Wann und wozu?

              Viele Gruesse,
              der Bademeister

              1. moin,

                Das heisst, die Eingabe wird als String gespeichert, egal, wie sie aussieht? Dann ist die Pruefung keine Pruefung auf einen Wertebereich, sondern eine Syntax-Pruefung eines Strings, und es spricht nichts gegen Regular Expressions zur Validierung.

                genau und so hätte ich es auch gesehen.

                1.: Warum sollen

                die daten [...] in das system rein, egal ob mit falschen oder richtigen werten

                ?

                wie bereits geschrieben, ein feature. die daten kommen von aussen, also es gibt keine kontrolle über die korrekheit der daten. ich (wir) wollen aber persistieren, welche daten zu uns gekommen sind, egal ob semantisch oder auch syntaktisch richtig oder falsch. der grund liegt dafür, dass wir dann einen fehlerreport machen können und zwar so, dass er auch später abrufbar und nachvollziehbar ist.

                2.:

                danach erfolgt erst die prüfung auf richtigkeit [...].

                Wann und wozu?

                die daten können ja wie gesagt grundsätzlich richtig kommen oder eben auch falsch. und dazu muss ich die guten daten von den bösen treffen, wie eben aschenputtel. die guten kommen dann in tabellen, die eben keine "globalen" strings mehr aufnehmen können, sondern dort liegen andere datentypen, eventuell constraints etc. drauf. deswegen kann ich nicht wie wild sie einfügen, sondern muss sie vorher prüfen.

                Ilja