Pavell: 5.000 € Notice: A non well formed numeric value encountered

Hello,

ich arbeite an einem Problem. Über Formular ich gebe ein Betrag.

5.000 € dann übermitteln an php scripte, doch hier dann Fehler!

Wie ich mache wieder eine normale Zahl daraus ohne .,€.

danke

Pavell

  1. Hallo Pavell,

    ich arbeite an einem Problem. Über Formular ich gebe ein Betrag.

    5.000 € dann übermitteln an php scripte, doch hier dann Fehler!

    Wie ich mache wieder eine normale Zahl daraus ohne .,€.

    Verwende

    <label>Betrag (€):
      <input type="number" name="amount">
    </label>
    

    Bis demnächst
    Matthias

    --
    Du kannst das Projekt SELFHTML unterstützen,
    indem du bei Amazon-Einkäufen Amazon smile (Was ist das?) nutzt.
    1. Verwende

      <label>Betrag (€):
        <input type="number" name="amount">
      </label>
      

      Das wäre ein erster Schritt. Aber letztendlich weiß niemand, ob ein verwendeter Browser das type="number" beachtet oder ob gar jemand böswillig Daten mit cURL, wget & Co. sendet. Ausgehend von einer früheren Diskussion habe ich mich mit dem Thema damals befasst und für die stets mit zu programmierende serverseitige Lösung einen Vorschlag erarbeitet: Input-Spekulator für Zahlen und Währungen

      Wie auf der Seite beschrieben sollte außerdem eine Plausibiliätzprüfung erfolgen (negative Anzahl, Preise etc.)

      1. Hallo Raketenwissenschaftler,

        Input-Spekulator für Zahlen und Währungen

        Magst du daraus was für unser Wiki oder unseren Blog machen?

        Bis demnächst
        Matthias

        --
        Du kannst das Projekt SELFHTML unterstützen,
        indem du bei Amazon-Einkäufen Amazon smile (Was ist das?) nutzt.
        1. Magst du daraus was für unser Wiki oder unseren Blog machen?

          Nun, das Thema birgt die Unlösbarkeit in sich. Der einzige, unter allen Aspekten richtige, Satz im Blog oder Wiki wäre die Aussage dass es eine allgemeingültige Lösung für dieses Problem nicht geben kann - außer natürlich alle nicht erwarteten Eingaben nach kleinlicher Prüfung (Stichworte: Integer, Float, Negativ, min, max, not [null,0]) „brutal“ zurück zu weisen.

          1. Hallo Raketenphilosoph,

            Magst du daraus was für unser Wiki oder unseren Blog machen?

            Nun, das Thema birgt die Unlösbarkeit in sich.

            Schon klar. Die Spekulation finde ich trotzdem aus logischen Überlegungen heraus interessant.

            Der einzige, unter allen Aspekten richtige, Satz im Blog oder Wiki wäre die Aussage dass es eine allgemeingültige Lösung für dieses Problem nicht geben kann

            Und auch nicht geben soll. Aber wenn nach einer nicht eindeutigen Übermittlung das Affenformular ein "Meinen Sie 45,75 €" enthält, würde das meiner Meinung nach ein Schritt in die richtige Richtung sein.

            Bis demnächst
            Matthias

            --
            Du kannst das Projekt SELFHTML unterstützen,
            indem du bei Amazon-Einkäufen Amazon smile (Was ist das?) nutzt.
            1. Hallo Matthias,

              Nun, das Thema birgt die Unlösbarkeit in sich.

              Schon klar. Die Spekulation finde ich trotzdem aus logischen Überlegungen heraus interessant.

              ich auch, zumal man mit einer minimalen KI schon in vielen Fällen richtig raten kann.

              Aber wenn nach einer nicht eindeutigen Übermittlung das Affenformular ein "Meinen Sie 45,75 €" enthält, würde das meiner Meinung nach ein Schritt in die richtige Richtung sein.

              ... die dann aber beim Anwender eventuell mit einem frustrierten "Nein, ich meinte 45.75 EUR" beschieden wird.

              Story am Rande: Wir müssen in der Firma Tag für Tag in SAP "zurückmelden", wieviele Stunden wir für welches Projekt aufgewendet haben. Ich habe in den ersten paar Tagen mal unseren IT-Support so weit verunsichert ("Nein, manche Eingaben werden einfach als fehlerhaft abgewiesen"), dass sich schließlich einer als Zuschauer auf meinem Rechner angeschaut hat, was da passiert. Ganz einfach: Ich hatte aus tiefer Gewohnheit Zeiten z.B. als 2.5 Stunden eingegeben. Schließlich hatte ich ja auf meinem PC auch den Punkt als Dezimaltrennzeichen eingestellt.
              Kann ich ahnen, dass SAP diese Einstellung einfach ignoriert?!

              Live long and pros healthy,
               Martin

              --
              Ich stamme aus Ironien, einem Land am sarkastischen Ozean.
      2. Hallo,

        was macht denn dein Script aus

        123.456,789

        bzw. aus

        123,456.789 ?

        Hier hänge ich noch.

        Gruß
        Jürgen

          1. Hallo,

            das sieht so aus, als ob du Tausendertrenner nur vor, aber nicht hinter dem Dezimalzeichen vorgesehen hast.

            0,123.456 = 0,123456 wird nicht angezeigt, sondern

            0,123.456 = 123.456

            Gruß
            Jürgen

            1. Hallo,

              das sieht so aus, als ob du Tausendertrenner nur vor, aber nicht hinter dem Dezimalzeichen vorgesehen hast.

              das wären dann ja auch Tausendsteltrenner…

              Im Ernst: ist das ein realistisches Szenario? Werden beim Eintippen von Zahlen wirklich Trenner mit eingetippt?

              Gruß
              Kalk

              1. Hallo Tabellenkalk,

                Werden beim Eintippen von Zahlen wirklich Trenner mit eingetippt?

                Habe ich auch schon überlegt - und ich würde sagen: Copy+Paste kann definitiv dazu führen. Daher kann auch das Währungszeichen und Spaces kommen.

                Rolf

                --
                sumpsi - posui - obstruxi
                1. Hallo

                  … Währungszeichen …

                  wobei das Währungszeichen nicht einfach über so ewtas wie parseFloat oder replace ignoriert werden kann, es muss schon berücksichtigt werden.

                  Gruß
                  Jürgen

              2. Hallo,

                das sieht so aus, als ob du Tausendertrenner nur vor, aber nicht hinter dem Dezimalzeichen vorgesehen hast.

                das wären dann ja auch Tausendsteltrenner…

                Sachen gibt's 😀. Ich habe amerikanische Signalgeneratoren, die verwenden in der Anzeige für die Frequenz einen Tausendsteltrenner. Immer wieder spannend, was die Studierenden da einstellen bzw. ablesen.

                Im Ernst: ist das ein realistisches Szenario? Werden beim Eintippen von Zahlen wirklich Trenner mit eingetippt?

                Die meisten Fragen zu meinem Tabellensortierer beziehen auf den Tausendertrenner/Tausendsteltrenner. Wobei ich zugeben muss, dass Zahlen mit 6 oder mehr Nachkommastellen im normalen Leben sehr selten sind. Aber wer den Punkt oder das Komma als Tausendertrenner zulässt, muss das auch für den Tausendsteltrenner tun.

                Gruß
                Jürgen

                1. Aber wer den Punkt oder das Komma als Tausendertrenner zulässt, muss das auch für den Tausendsteltrenner tun.

                  Mit 5.001,002,003 oder 5,001.002.003 oder klappt das. Mit 5.001,002 und 5,001.002 (da wäre das Komma wohl in Amerika das „tausendstel-Trennzeichen“) kommt jetzt 5001.002 raus. Ebenso bei 5,000 und 5.000 kommt es auf die Spracheinstellung des Browsers an. Wie schon geschrieben: das Ding kann in vielen Situationen nur spekulieren. „Shit-In -> Shit-out“ ist eines der Grundgesetze der Informatik.

                  Andere Tausender- und tausendstel-Trennzeichen (Akzent, schmale und breite Leerzeichen) werden (wie jeder andere „Nicht-Zahlen-Kram“) jetzt brutal gelöscht. Das mag auch deshalb genügen, weil die Chose noch einigermaßen performant bleiben muss.

                  Noch ein Fehler behoben: Auf 32-Bit-Systemen (Raspi) war dank (int) bei etwas mehr als 2 Millionen „Schluss mit lustig“. echo $PHP_INT_MAX gibt Auskunft, warum das so ist.

              3. Tach!

                Im Ernst: ist das ein realistisches Szenario? Werden beim Eintippen von Zahlen wirklich Trenner mit eingetippt?

                Vielleicht, vielleicht auch nicht. Aber für mich als Eingebenden ist es einfacher, an einer Zahl mit Trennzeichen zu erkennen, ob ich den richtigen Wert eingegeben oder mich vertippt habe. Leider steht dem so ein <input type=number> teilweise entgegen. Der Chrome lässt mich keine anderen Zeichen als den Dezimalpunkt eingeben. Allerdings nimmt er auch sowas wie 127.0.0.1 als Zahl an.

                dedlfix.

            2. Ja. Man kann daran unendlich Kritik üben, weil das Problem unendlich ist. Es ist halt ein „Spekulator“, also etwas, was „spekuliert“. Diese explizite Wortwahl bedeutet zwingend, dass das Ergebnis unrichtig sein kann.

              Ich habe zwischenzeitlich auch was geändert:

              Der „Spekulator“ untersucht, ob es sowohl potentielle Tausender-Trennzeichen als potentielle Kommas gibt. Ist das nicht der Fall, dann schaut er, ob eventuell deutsch die bevorzugte Sprache ist und stellt also das Komma entsprechend ein.

              Vorher hat er NUR auf [',', '.'] untersucht.

              Das hatte aber zur Folge, dass sowohl 5.000 als 5,000 als 5 erkannt werden. Jetzt erkennt er, bei deutscher Spracheinstellung 5,000 als 5 und 5.000 als 5000. Bei jeder anderen 5,000 als 5000 und 5.000 als 5.

              Dein 0,123.456 erkennt er als 123.456 weil das Komma der weiter links stehende dot ist.

              1. Hallo,

                … „Spekulator“ …

                ja, das Lesen von Zahlen ist nicht einfach und an der Grenze des unmöglichen, wenn man beim Dezimalzeichen und beim Tausendertrenner großzügig ist. Nicht umsonst wird vom „.“ bzw. „,“ als Tausendertrenner abgeraten und die Normen sehen nur ein schmales Leerzeichen vor, das man aber auf der Tastatur nicht findet und das vom Browser als normales Leerzeichen angezeigt wird.

                … Sprache …

                dahin gehen auch meine momentanen Ideen. Allerdings denke ich da an die Dokumentensprache, also an das lang-Attribut.

                Wenns nicht zu kompliziert wird, baue ich es in den Tabellensortierer im Wiki noch mit ein.

                Gruß
                Jürgen

                1. @@JürgenB

                  Nicht umsonst wird vom „.“ bzw. „,“ als Tausendertrenner abgeraten und die Normen sehen nur ein schmales Leerzeichen vor

                  Und zwar ein nicht umbrechendes: U+202F narrow no-break space

                  Sieht man leider immer mal wieder, dass ein Zeilenumbruch eine Zahl auseinanderreißt:

                  1 000 Mal ist nichts passiert; 1
                  001 Nacht & es hat 💥 gemacht

                  das man aber auf der Tastatur nicht findet

                  U+202F findet man nicht einmal in den HTML-Enities; &nnbsp; gibt’s nicht.

                  und das vom Browser als normales Leerzeichen angezeigt wird.

                  Dass die schmalen Leerzeichen genauso breit dargestellt werden wie normal, ist ein Ärgernis. Ist das die Schuld der Browser oder nicht doch der Schriftarten?

                  🖖 Stay hard! Stay hungry! Stay alive! Stay home!

                  --
                  Home Office ist so frustierend, weil man jetzt noch viel stärker bemerkt mit wievielen Menschen man zu tun hat, die nicht sinnerfassend lesen können. (@Grantscheam)
                2. an der Grenze des unmöglichen

                  Allerdings denke ich da an die Dokumentensprache, also an das lang-Attribut.

                  Tja. Da haben wir es wieder. Es ist unmöglich zu wissen, ob der konkrete, die Eingabe tätigende Besucher sich an der Sprache des Dokuments, oder an der in seinem OS (oder, in Spezialfällen, im Browser) eingestellten Sprache oder halt am Stand des Mondes orientiert.

                  „An“ der Grenze des Unmöglichen ist man auch, wenn man über diese „hinweg“ ist (Anders ausgedrückt: „fast vorbei“ ist auch „getroffen“.)

                  Aus einem ähnlichen Grund hab ich auch die Währungen (oder andere Größen) rausgeworfen. Hier weiß ich nicht, was der Verwender dann machen will: Eintrag in eine Datenbank? Geht schief (String). Weitere Berechnungen? Gehen schief (String). Umrechnen in eine andere Währung? Da stellen sich die Fragen a) in welche und b) zu welchem Kurs.

        1. Hallo JürgenB,

          kommt auf die eingestellte Rundung an 😉

          Bei hinreichend großen Angaben kommt beide Male der float-Wert 123456.789 raus. Das hab ich dem Code nicht angesehen, ich habe ihn in die Sandbox geworfen.

          Das Script ist allerdings nicht so ganz perfekt. Die is_int und is_float Abfragen sind etwas, worauf ich auch schon reingefallen bin. Sie prüfen nicht, ob der Wert eines Strings als int oder float interpretierbar ist, sondern sie prüfen, ob die Variable den Typ int oder float hat. Bei einem string liefern sie immer false.

          Ob es gutes Design ist, einem "Number Guesser" auch noch die Aufgabe zu übertragen, Leerzeichen zu entfernen und sich damit in UTF-8 Feinheiten zu vertiefen - hm. Reine Lehre ist es nicht, aber praktisch mag es sein.

          Rolf

          --
          sumpsi - posui - obstruxi
      3. @@Raketenwissenschaftler

        Input-Spekulator für Zahlen und Währungen

        Wenn’s um Geld geht, ist nicht die Stelle zu spekulieren, was der Nutzer mit der Eingabe gemeint haben könnte. Da sollte es klare Vorgaben an das Eingabeformat geben und alles, was sich nicht daran hält, wird abgewiesen. Mag nutzerunfreundlich sein, aber wohl besser als einen tausendfach zu hohen Betrag vom Konto abzubuchen.

        🖖 Stay hard! Stay hungry! Stay alive! Stay home!

        --
        Home Office ist so frustierend, weil man jetzt noch viel stärker bemerkt mit wievielen Menschen man zu tun hat, die nicht sinnerfassend lesen können. (@Grantscheam)
        1. Wenn’s um Geld geht, ... Betrag vom Konto abzubuchen.

          Jaja. Ich hab ja nicht grundlos mehrfach Warnungen eingebaut. (Schon im Name: „Spekulator“!)

          Das „Wenn’s um Geld geht" hat aber durchaus einen viel weiteren Wirkbereich. Oft genug geht es z.B. auch darum, aus solchen Angaben ein Diagramm zusammenzukloppen. Ich sag nur „Generation PowerPoint“. Dafür kann man das wohl nehmen.

          Was hab ich schon über solche Statistiken gelacht - selbst wenn die Zahlen stimmen, haut es einen bei dem hergestellten Zusammenhängen um.

          Ich sag nur: Covid-19 und die (reichlich abartige) Vermutung, dass Raucher daran signifikant seltener schwer erkranken. (Das waren Wissenschaftler, die nicht bedacht haben, dass die Riskogruppe auf Grund der Vorschädigung signifikant weniger raucht - und ganz ernsthaft den Raucheranteil der Gesamtbevölkerung mit dem der schwer erkrankten verglichen…)

          1. @@Raketenwissenschaftler

            Was hab ich schon über solche Statistiken gelacht - selbst wenn die Zahlen stimmen, haut es einen bei dem hergestellten Zusammenhängen um.

            Ich sag nur: Covid-19 und die (reichlich abartige) Vermutung, dass Raucher daran signifikant seltener schwer erkranken. (Das waren Wissenschaftler, die nicht bedacht haben, dass die Riskogruppe auf Grund der Vorschädigung signifikant weniger raucht - und ganz ernsthaft den Raucheranteil der Gesamtbevölkerung mit dem der schwer erkrankten verglichen…)

            Um das zu verdeutlichen, ein Rechenbeispiel: 1000 Infizierte, davon 500 Raucher, 500 Nichtraucher.

            Von den 1000 hat jeder Fünfte eine Vorerkrankung, also 200. Die verteilen sich nun aber nicht gleichmäßig auf Raucher und Nichtraucher, sondern: 50 Raucher mit Vorerkrankung, 150 Nichtraucher mit Vorerkrankung. Warum? Weil wegen ihrer Vorerkrankung 50 Leute schon seit langem aufgehört haben zu rauchen.

            Der Anteil derer, die schwerer erkranken, sei bei denen ohne Vorerkrankung 10%, bei denen mit Vorerkrankung 50%.

            Wir haben also:

            NR ohne V NR mit V R ohne V R mit V
            Infizierte 350 150 450 50
            Erkrankte 35 75 45 25

            110 erkrankte Nichtraucher, aber nur 70 erkrankte Raucher. Da ist sie, die „die (reichlich abartige) Vermutung, dass Raucher daran signifikant seltener schwer erkranken.“

            🖖 Stay hard! Stay hungry! Stay alive! Stay home!

            --
            Home Office ist so frustierend, weil man jetzt noch viel stärker bemerkt mit wievielen Menschen man zu tun hat, die nicht sinnerfassend lesen können. (@Grantscheam)
            1. Ja. Danke. Ich dachte schon, die Sperre sei wegen des „Generation PowerPoint“ erfolgt. Offenbar hat jemand gedacht, ich verbreite Verschwörungstheorien.

            2. Hi,

              Um das zu verdeutlichen, ein Rechenbeispiel: 1000 Infizierte, davon 500 Raucher, 500 Nichtraucher.

              Von den 1000 hat jeder Fünfte eine Vorerkrankung, also 200.

              Hm. Eben waren es noch 500 Vorerkrankte (a/k/a Raucher) 😉

              cu,
              Andreas a/k/a MudGuard

              1. @@MudGuard

                Um das zu verdeutlichen, ein Rechenbeispiel: 1000 Infizierte, davon 500 Raucher, 500 Nichtraucher.

                Von den 1000 hat jeder Fünfte eine Vorerkrankung, also 200.

                Hm. Eben waren es noch 500 Vorerkrankte (a/k/a Raucher) 😉

                😄 Raucher stinken. (Sebastian Krämer)

                🖖 Stay hard! Stay hungry! Stay alive! Stay home!

                --
                Home Office ist so frustierend, weil man jetzt noch viel stärker bemerkt mit wievielen Menschen man zu tun hat, die nicht sinnerfassend lesen können. (@Grantscheam)
        2. Mag nutzerunfreundlich sein, aber wohl besser als einen tausendfach zu hohen Betrag vom Konto abzubuchen.

          Naja. Da der TO nichts über die Anwendung erwähnt hat und es viele Möglichkeiten gibt, die Einträge irgendwelcher monetärer Beträge in irgendwelche Formulare zu verwerten - ohne dass es zu solchen Problemen kommt (Umsatzlisten, wie aktuell in meinem Fokus: Pokerspielerdatenbanken, … ), habe ich das Skript vorgestellt.

          • Wenn er damit Mist macht, dann kann ja sein Chef oder Auftraggeber direkt bei mir anrufen...
      4. Achso. Wer sich das anschauen will sollte [F5] drücken. Grund: Ich habe ein brutales Browsercaching von 3 Tagen (72 Stunden) voreingestellt.

  2. Hallo Pavell,

    wenn deine Anwender einen Tausenderpunkt und ein Währungssymbol eingeben, dann musst Du das ggf. auf der PHP Seite säubern.

    Frage ist natürlich, ob sie das müssen. Matthias Vorschlag läuft darauf hinaus, dass Du die Währung vorgibst und die Anwender sie nicht eingeben können.

    Mit Tausendertrennzeichen tut input="number" sich auch schwer.

    Rolf

    --
    sumpsi - posui - obstruxi