nicht angemeldet
Hallo,
Ja, ich weiß, solche Beckmesserei scheint müßig, aber ich habe da schlechte Erfahrungen und möchte nicht, das anderer Leute Arbeit auf ähnlichen Wegen verschwindet.
Ich bin Dir dankbar, dass Du mich auf so etwas hinweist.
Du hattest gefragt.
Wenn auch nicht gerade in der Erwartung tatsächlicher Schwierigkeiten ;-)
Dann mach aber auch die Benutzung einfach, sonst quengeln die schon wieder ;-)
Wenn man es wirklich richtig macht, dann wird es aber leider auch nicht einfach. :-( Aber wie das ganze Konzept jetzt exakt aussehen soll, überlege ich mir dann noch - schließlich brauche ich jetzt erst einmal Anforderungen an meine Klasse.
Warum kann das nicht einfach werden?
CS_validate_mailaddresssyntax(const char *)
Returns 1 on success or 0 on faillure respectivly.
Reicht doch, oder?
Ich habe übrigens etwas mit so Zeichensätzen experimentiert.
Auha.
Folgendes Problem: Wenn der Zeichensatz, der mit der Seite mit dem Formular mitgeliefert wird, iso-8859-15 ist, dann wird das Euro-Zeichen, das vom Browser an die Verarbeitungsseite geschickt wird, korrekt kodiert (Dezimal 164) Wenn der Zeichensatz ein anderer ohne Euro-Unterstützung ist, dann liefert mir zumindest der Mozilla (andere Browser (noch) nicht getestet) eine HTML-Entity (€) die ja auch korrekt ist. Wenn der Zeichensatz jedoch iso-8859-1 ist und man die Microsoft-Schriftarten verwendet (auch unter Linux) dann wird das Zeichen mit der Nummer 128 geschickt, welches ja eigentlich verboten ist. (ich kenne die Geschichte mit Microsoft und dem ?-Zeichen)
Es gbt keine Serverseitige Lösung für dieses Problem, da es das HTTP nicht vorhergesehen hat.
Dort ist nur ASCII erlaubt.
Es muß also schon auf der Clientseite dafür Sorge getragen werden, das das nicht passiert (Das Eurozeichen kann man z.B. schon vorgeben)
Auch ist es weder in Mailadressen, noch in URIs erlaubt andere Zeichen als aus ASCII zu benutzen.
Die beiden wärst Du also schonmal los ;-)
Und da sich für solch eine Validierung ein modulares Konzept geradezu aufdrängt und die beiden das größte Problem darstellen, wäre ein Gutteil der Arbeit getan, wenn denn beide funktionieren würden.
Folglich bekomme ich entweder
* das Zeichen als "normales" Zeichen geliefert, sofern es im aktuellen Zeichensatz enthalten ist (Eurozeichenausnahmen ausgenommen)
* das Zeichen als HTML-Entity geliefert, sofern es nicht im aktuellen Zeichensatz enthalten ist
Soweit, so richtig.
Wenn ich jetzt aber & eingebe, dann kodiert der Browser das *nicht* als & sondern lässt es nicht kodiert.
Das verstehe ich nicht ganz, bitte um erweiteretes Beispiel.
Die Funktion htmlspecialchars verhält desweiteren nicht ganz korrekt, dass sie das &-Zeichen nur dann maskiert, wenn es vor einer weiteren Entity steht.
Mieser Bug! Wird doch hoffentlich schon dran gearbeitet, oder?
Wenn ich aber z.B. ? in ein Textfeld eingebe und das dann abschicke und dann htmlspecialchars drüber laufen lasse, dann wird das ?-Zeichen als € dargestellt.
So weit, so (ziemlich) korrekt.
Aber wenn diese Funktion so buggy ist, dann schreibe entweder Deine Eigene oder such etwas anderes.
Könntest natürlich auch den Bug fixen ,-)
BTW: möchtest du eigentlich in reinem PHP bleiben? (ich gehe davon aus, frage aber lieber mal ;-)
so short
Christoph Zurnieden