Hi!
Aber es kann ja nicht schaden, dem Problem, ungeachtet dessen, dass es in der Praxis nicht auftreten sollte, generell aus dem Weg zu gehen. Oder zumindest darauf aufmerksam zu machen, dass das Problem existieren kann.
Es gibt noch jede Menge anderer Probleme beim Programmieren zu beachten, auch solche, die mit dem Nichtbeachten von Wertebereichen zu tun haben. All diese Probleme kann man unmöglich aufzählen, weswegen ich mich nur auf solche beschränken will, die unmittelbar mit dem Kontextwechsel zu tun haben. Wenn ich das Problem mit den überlaufenden Integerwerten erwähnen wollte, müsste ich der Vollständigkeit halber alle MySQL-Integer-Typen ansprechen (also auch die kleiner als INT) und daraufhin eine generelle Lösung erstellen. Wie auch immer, die überlaufenden Zahlen erzeugen kein Kontextwechselproblem. Die (String-)Alternative zu intval() ist bereits erwähnt. Ich werde noch zwei Beispiele hinzufügen, ein mit dem Typecast per %d und eins für die Stringvariante.
Wo siehst du denn hier eine Pauschalität? Ich habe doch zwei Argumente genannt - sind die deiner Meinung nach beide so abwegig? Oder anders gefragt: welchen Vorteil versprichst du dir von der integer-Variante, oder welchen Nachteil siehst du in der String-Version?
Die String-Variante ist in deinem Beispiel da, um ein möglicherweise auftretendes Wertebereichsproblem zu umgehen. Dazu muss sie einen Umweg über einen anderen Variablentyp gehen. Dabei ist nicht offensichtlich, warum hier ein String verwendet wird, obwohl doch Zahlen verarbeitet werden sollen. Aus diesem Grunde will ich sie nicht als primäre Lösung darstellen. Auch deshalb nicht, weil andere DBMS anders denken, wenn sie Strings statt Zahlen erhalten.
Das Augenmerk dieses Abschnitts soll sein, den richtigen Kontext zu erkennen, was bei Zahlen gelegentlich mit einem mysql_real_escape_string() auf unquotierte Werte falsch gemacht wird.
das Problem ist, dass eine Nutzereingabe durch intval() ggf. verändert wird. Wenn man auf eine fachliche Prüfung verzichten kann, bzw. es keine fachliche Prüfung gibt, z.B. im Falle von Suchanfragen, ist das eher hinderlich. Daher ist es meiner Meinung nach falsch, Nutzereingaben pauschal in Zahlenwerte zu konvertieren, auch dann, wenn man Zahlenwerte erwartet.
Dieses Argument scheint mir nicht nachvollziehbar. Suchanfragen in Zahlenfeldern werden kein sinnvolles Ergebnis bringen, wenn man sie mit Nicht-Zahlen-Strings vergleicht. Wenn jemand einen falschen Wert eingibt, kann er nicht erwarten, ein richtiges Ergebnis zu erhalten. Insofern sehe ich es als gerechtfertigt, Eingaben in Zahlenwerte zwangszukonvertieren, wenn diese für die Weiterverarbeitung benötigt werden. Außerdem geht es hier nicht um pauschale Umwandlung für sämtliche Datentypen (wie man deinen Satz interpretieren kann), sondern um eine solche im Falle von Zahlen.
Lo!