Tach!
Zum einen bekommst Du Daten aus einer nicht vertrauenswürdigen Quelle, dem Formular. Hier wäre abzusichern, das keine SQL-Attacke eingeschleust werden kann, sondern nur die Daten.
Es ist völlig unerheblich, wo Daten herkommen. Sie müssen sie immer kontextgerecht ausgegeben/eingefügt werden. Die einzig vertrauenswürdigen Daten sind Literale im Quelltext, und selbst bei denen muss man die Sonderzeichen beachten.
Verwende einen DB-Treiber, der mit Platzhaltern arbeitet, da werden die Eingaben der DB-Engine entsprechend automatisch so gequoted, dass nur passive Daten ankommen (PDO, mysqli).
Quoten bezeichnet das Einrahmen in Stringbegrenzungszeichen (meist Anführungszeichen). Passive Daten? Gibt es auch aktive? Was jedenfalls mit den Daten konkret passiert, ist Blackbox - nicht sichtbar. Der Treiber beziehungsweise die DBMS-API kümmert sich um die gefahrlose Übertragung. Wie sie konkret übertragen werden, ist dabei unerheblich. Ob sie dafür gequotet werden müssen oder nicht, spielt keine Rolle.
"Mit Platzhaltern arbeiten" heißt konkret "Prepared Statements". Und es reicht nicht, dass der Treiber sie anbietet, man muss auch damit arbeiten. Abgesehen davon sollte man wirklich auf mysqli oder PDO umsteigen, weil die herkömmlichen mysql_*-Funktionen bereits in der nächsten Version von PHP (5.5) als missbilligt gelten und irgendwann ganz rausfliegen werden.
Das Nächste ist die Zeichenkodierung. Hierzu ist in erster Linie die Quelle zu beachten,
Nicht nur, die gesamte Verarbeitungskette ist zu beachten. Und zwar jedes beteiligte System und jede Übergabe in ein anderes System gleichermaßen. Es ist ja nicht so, dass einmal richtig kodierte Daten nicht auch durch Verarbeitungsfehler verunstaltet werden können.
Betrachten wir des Weiteren HTML Entities. Eine DB Engine kennt sowas gar nicht, der ist das völlig Wurscht. Ergo kannst Du darauf verzichten.
Das ist nicht nur ein "kann". Ein Empfänger braucht die für die Maskierung zusätzlichen/geänderten Zeichen, um die eigentlichen Werte aus dem Datenstrom korrekt identifizieren zu können. Wenn der Empfänger einer bestimmte Maskierungsart aber nicht unmittelbar erreicht werden soll, sondern noch in weiter Ferne ist, hat man die im Moment nicht notwendigen Zeichen mitten in den eigentlichen Daten stehen, was nicht nur unnötig Platz belegt, sondern auch die Verarbeitung in diesem System erschwert. Das Problem wird auch nicht einfacher, wenn die Daten am Ende gar einen ganz anderen Empfänger erreichen sollen.
dedlfix.