Moinsen,
dann will ich dir mal schnell Antworten. Als erstes will ich dir mal zwei Links ans Herz legen. Dort findest du schon eine Menge Antworten:
Formulare auslesen und auswerten
For Each Anweisung verstehen
So, damit wären dann schon einmal die Grundlagen geklärt ;-)
Damit kommen wir jetzt zur Antowrt deiner Fragen. Das Durchlaufen aller Formularfelder und die Auswertung mit RegExp ist kein Problem. Wie du selber schon festgestellt hast, geht das mit der for each Anweisung. Das einzige Hinderniss was ich dabei sehe ist, dass nicht alle Felder auf die gleiche Weise verarbeitet werden sollen. Damit meine ich, dass es Buchstabenfelder wie Name, Anschrift gibt, aber auch Zahlenfelder wie PLZ. Oder wie von dir schon besprochen das EMailfeld. Und für all diese Felder gelten andere Bedingungen. Auch kann es vorkommen, dass irgendwelche Angaben in Pflichtfeldern sind. Auch sowas müsste berücksichtigt werden. Und sowas ist von vornherein nicht unbedingt automatisch zu unterscheiden. Dafür würde es sich anbieten, dass du deinen Feldern spezielle Namen gibtst. Damit meine ich, das zum Beispiel das Feld Vorname nicht einfach VORNAME heißt, sondern einen gewissen Code enthält, z.B. PZ_VORNAME, was soviel bedeutet wie Pflichtfeld und Buchstaben erlaubt. Um das wieder herauszufiltern kannst du die Stringfunktionen, wie instr, left, right, usw. verwenden.
Dann ist deine automatische Verarbeitung der Felder kein Problem.
So und nun zu deiner Frage mit dem HTML-Code und Server.HTMLEncode. Klar kannst du HTML-Code entfernen, ist nur die Frage ob das Sinn macht. Außerdem solltest du niemals Server.HTMLEncode vor dem Speichern in eine DB verwenden. HTMLEncode ist sicher wichtig um Hackern keinen Angriffspunkt zu bieten (Stichwort Cross Site Scripting), aber das erfolgt erst an den Punkten wo du die Eingaben aus einer DB wieder anzeigst. Wichtig ist dann nur, dass man nicht vergisst, das Überall zu machen, aber wenn man sich das mal angewöhnt hat, dann macht man das ganz automatisch. OK, jetzt werden vielleicht manche aufschreien und Frage warum nicht schon vor dem Abspeichern in die DB HTMLEncode verwenden. Ich will das mal kurz erklären:
HTMLEncode wandelt alle Zeichen die nicht HTML konform sind um. Das sind jetzt nicht nur Zeichen wie < und > sondern auch alle Umlaute (ä,ö,ü) und genau dabei liegt das Problem. Aus einem ä wird ä, d.h. aus einem Buchstaben wird plötzlich (und unsichtbar für den Nutzer) eine Zeichenkette mit 6 Buchstaben. Und stell dir jetzt vor, du gibtst jetzt eine Maximallänge der Eingaben vor, z.B. 30 Zeichen für Nachname. Der Nutzer hat einen ganz komischen Namen mit ganz vielen Umlauten und schon kann es vorkommen, dass der umgewandelte String länger als 30 Zeichen ist und eine Fehlermeldung wird ausgegeben. Der Nutzer weiß nicht warum, da sein Name nur sagen wir 25 Zeichen lang ist. Das ist das erste Problem dabei. Das zweite Problem ist wenn du die Daten in die DB speicherst. Auch dort haben die Felder eine gewisse Länge und die könnte dann überschritten werden. OK, dafür könnte man das Feld in der DB doppelt so lang machen als die erlaubte Maximalzahl. Aber was wenn jemand anderes (z.B. ein Administrator) direkt Änderungen in der DB machen darf. Dann wären HTML-Codes wieder möglich. Würdest du jetzt bei der Ausgabe nochmals HTMLEncode verwenden würde daraus eine nicht mehr lesbare Buchstabenkombination entstehen. Aus einem & wird & und da kann man sich vorstellen was passiert ;-) Also lieber selber bei der Ausgabe erst konvertieren und in der DB unkonvertiert speichern.
Aber du musst es ja nichtmal soweit kommen lassen mit den HTML-Codes. Du willst ja sowieso deine Formulardaten mit RegExp auswerten. Das ist gut so. Man sollte sowieso niemals Daten ungeprüft in eine DB abspeichern ... NIEMALS! Stichwort hier: SQL Injection (siehe auch ASPheute)
Und mit den regulären Ausdrücken kannst du genau sagen welche Zeichen erlaubt sind und welche nicht. Aber hier solltest du niemals abfragen ob irgendwelche unerlaubte Zeichen im String vorkommen - man vergisst bestimmt etwas - sondern immer den String nach erlaubten Zeichen checken. Dann kannst du dir sicher sein, dass deine Werte sauber sind.
Achja, und weil wir schon bei SQL Injection sind. Niemals einen SQL String dynamisch zusammenbauen. Ich meine damit folgendes:
SQL = "SELECT * FROM XYZ WHERE Wert1=" & Request.Form("ABC")
Das sind genau die Angriffspunkte die Hacker suchen und für SQL Injections ausnutzen. Klar ist die Sache schon etwas sicherer wenn die eingegebenen Werte überprüft sind, aber man kann immer etwas vergessen haben, oder der Hacker schlauer sein und dein Überprüfung umgehen. Daher immer parametrisierte SQL Anweisungen verwenden. Auch wieder genau Nachzulesen auf ASPheute --> Gegengifte für SQL-Injections.
Auch wenn deine Anwendung vielleciht nur im Intranet laufen sollte, auch in einer Firma kann es böse Menschen geben ;-) und die könnten dann einiges zerstören. Außerdem sollte man von Anfang an sauber und sicher programmieren.
So, langer Text, aber ich hoffe, das hilft dir ein wenig weiter.
Schöne Grüße,
Chrisu
