zuerst einmal: Ich beschäftige mich mit PHP immer nur insofern ich es für mein Hobby brauche. Ich kann zwar PHP-Code ein wenig anpassen und einbinden - aber das war’s schon.
Ich möchte auf meiner Seite einen Formmailer in Form einer Postkarte verwenden. Das funktioniert auch solange einwandfrei wie der Benutzer in seinem Namen oder seiner Nachricht keine Umlaute verwendet. Sobald diese vorkommen wird das Feld bei der Übertragung scheinbar ignoriert. Wäre jemand von euch so lieb und könnte mal über den Quellcode schauen was daran geändert werden müsste?
[code]<?php
// Kontaktformular by www.caosweb.de - Einstellungen:
$deinname = “Jörg Keul”; // hier deinen Namen eingeben // so wirst du in der Email angesprochen
$deineemail = "joergkeul@web.de"; // hier deine E-mail Adresse eingeben // hier werden die Emails hingesendet
$imagepath = “image”; // ohne abschließenden “/” // Pfad zu den Bildern der Fehlermeldung und Captcha
// Adressfeld für den Absenderadresse:
$adressanrede = “Herr”; // Anrede (z.b. Herr / Frau / Firma
$adressname = “Jörg Keul”; // Name oder Firmenname
$adressstrasse = “Hollerer Str. 4a”; // Strasse oder Postfach
$adressplzort = “56412 Niederelbert”; // Postleitzahl und Ort
Tja, es könnte sich lohnen, in kontakt.php testweise ein paar Ausgaben reinzubasteln, um zu sehen, welche POST-Parameter wirklich ankommen. Zunächstmal gibt es keinen Grund, die eingetragenen Werte an sich zu ignorieren, nur weil sie irgendwelche besonderen Zeichen enthalten (zudem scheint die Kodierung konsistent ISO… zu sein, von daher also in Ordnung).
Das Darstellungsprogramm sollte sie sicher senden, unabhängig von eventuellen Kodierungsproblemen, das Dienstprogramm auch bekommen, bleibt also die Verarbeitung der Werte im Skript selbst.
Im Skript gibt es zwar einige Überprüfungen, etwa der email-Adresse, die nicht notwendig kompatibel mit allen heute erlaubten email-Adressen sein muß. soweit ich das sehe, ist aber die Verarbeitung von ‘name’ und ‘message’ recht harmlos und überschaubar. Man könnte allenfalls mal gucken, wie htmlspecialchars auf Umlaute reagiert - ich glaube, ich hatte da auch schon mal Probleme, wo die Funktion ab irgendeiner PHP-Version an die falsche Kodierung geglaubt hat, weil die das rückwärtsinkompatibel geändert oder erweitert haben. Eventuell sollte man da die verwendete Kodierung explizit angeben, um auf der sicheren Seite zu sein.
wenn du mir jetzt noch verrätst was ich wo ändern muss bzw. wo ich die umlaute explizit einfügen muss werde ich dich heut abend lobend in mein nachtgebet mit einschliessen
Mein Vorschlag wäre, du bastelst ein Testskript, in dem bei Verwendung derselben Kodierung
die Funktion htmlspecialchars auf solche Umlaute in der von dir bevorzugten Kodierung angewendet wird.
Mit dem Testskript kannst du herumprobieren und gucken, ob die Angabe der Kodierung
einen Unterschied macht. Wenn dem so ist, gibst du ISO-8859-15 bei jedem htmlspecialchars
als Parameter an - kannst natürlich die anderen Parameter auch noch ausprobieren.
Wenn das Testskript kein Problem mit der Kodierung offenbart, liegt der Fehler doch an anderen Sachen. Weil ab PHP 5 diverse Sachen mittendrin verändert wurden, solltest du das
direkt hier auf dem Dienstrechner ausprobieren, weil das Ergebnis oder auch die Verwendbarkeit der Kosntanten von der aktuell verwendeten PHP-Version abhängen kann.
Da meine Rechner eine andere PHP-Version verwenden als der hiesige, hat mich das irgendwann so genervt, daß ich htmlentities, bei dem das Problem bei mir auftrat, komplett durch eine eigene Prozedur ersetzt habe ;o)
Warning: htmlspecialchars() [function.htmlspecialchars]: charset `-8874’ not supported, assuming utf-8 in /users/tierwelten/www/home/kontakt/test.php on line 5
Ohne Kodierungsangabe:
Mit Kodierungsangabe:
Was immer das bedeuten mag
Hab aber jetzt mal den charset im kontaktformular auf 8 geändert und bekomme dann in der mail folgenden Text:
Name: Jörg Keul
E-Mail: XXXXXXX
IP-Adresse: XXXXXXX
Da fehlten bei dem Testskript wohl Anführungsstriche:
htmlspecialchars($text, ENT_QUOTES, ‘ISO-8859-15’);
UTF-8 bringt dir nur was, wenn du auch die Seite mit dem Formular als UTF-8 kodierst und so
vom Dienstprogramm ausliefern läßt. Sonst müßtest du es vor der Auswertung umkodieren, was
auch albern ist.
Derzeit benutzt du offenbar wirklich ISO-8859-15, von daher ist das entweder überall zu ändern oder gar nicht ;o)
Wenn du bereits viel Inhalt als ISO-8859-15 hast, wirst du das kaum umstellen wollen.
Hast du nur wenig Inhalt als ISO-8859-15 kann eine Umkodierung auf UTF-8 derartigen Ärger
wie diese PHP-Versions-Schlampereien durch rückwärtsinkompatible Änderungen allerdings vermeiden ;o)
Vor Version 5.4 war die Kodierung für htmlspecialchars ohne Angabe wohl ISO-8859-1,
jetzt ist sie UTF-8. Ich vermute mal, daß das hiesige Dienstprogramm PHP in Version 5…4 oder
neuer verwendet (habe es nicht nachgesehen), weswegen es zu Problemen kommt, wenn
man keine Angabe zur Kodierung macht, aber kein UTF-8 verwendet. Das heißt aber auch,
hat es früher ohne Angabe mal funktioniert, hat solch ein Skript dann stillschweigend die
Funktion eingestellt, seit auf PHP 5.4 umgestellt wurde ;o)
Offenbar fügst du bei jeder Verwendung von htmlspecialchars die Kodierungsangabe hinzu.
Weil man wohl von der Reihenfolge der Angaben für htmlspecialchars den zweiten Parameter nicht weglassen kann, darfst du dir da einen aussuchen, den du auch einsetzt. Ich habe es nicht ausprobiert, wenn man den Platz zwischen den beiden Kommata einfach wegläßt, kannst du ja auch versuchen.
Mit einer Suchfunktion deines Texteditors oder auch hier mit dem Brauser solltest du doch alle Stellen finden, wo htmlspecialchars im Quelltext steht, wo ist also das Problem? ;o)
Hinsichtlich UTF-8-Umstellung: Wenn es kein Problem ist, solltest du das wohl stattdessen für das gesamte Projekt tun.
Ich habe viele Seiten mit ISO-Kodierung, daher kommt das für mich leider nicht in Frage
erstmal danke für deine Hilfe.
Ich habe jetzt folgendes eingefügt:
Jetzt wird zwar wenigstens schonmal was übertragen. Aber das Ergebnis sieht dann wieder so aus: Test äöü Da sollte aber eigentlich Test äöü stehen
Wenn ich versuche auf UTF-8 umzustellen bekomme ich NACH dem absenden folgenden Fehler:
Warning: htmlspecialchars() [function.htmlspecialchars]: charset `ISO-8859-8’ not supported, assuming utf-8 in /users/tierwelten/www/home/kontakt/postkarte.php on line 38
Warning: htmlspecialchars() [function.htmlspecialchars]: charset `ISO-8859-8’ not supported, assuming utf-8 in /users/tierwelten/www/home/kontakt/postkarte.php on line 44
Hast du vielleicht noch eine Idee? Würde nur sehr ungerne auf ein anderes Kontaktformular ausweichen da dieses hier viel besser zu meiner Seite passt als die modernen.
[quote=“Gockel”]Wenn ich versuche auf UTF-8 umzustellen bekomme ich NACH dem absenden folgenden Fehler:
Warning: htmlspecialchars() [function.htmlspecialchars]: charset `ISO-8859-8’ not supported[/quote]
Du hast einfach die letzte Nummer der ISO-Kodierung durch ‘8’ ersetzt, und glaubst das würde dann UTF-8 bedeuten …?
Nein, ‘UTF-8’ bedeutet UTF-8, nicht ‘ISO-irgendwas’.
äöü sind numerische Maskierungen von äöü .
Sofern du ein Programm verwendest, welches XML oder HTML interpretieren kann, so werden die Sachen als die gewünschten Umlaute dargestellt. Warum die Funktion das ebenfalls konvertiert und nicht, wie der Name nahelegt, nur Zeichen, die spezifisch für XML/HTML sind, bleibt allerdings ein Geheimnis der Entwickler.
Sollte bei einer Interpretation als XML oder HTML der Kram nicht als Umlaute dargestellt werden, sondern als solch eine Zeichenfolge, ist vermutlich doppelt maskiert worden, also in einem zweiten Durchlauf das & nochmal ;o) Um das zu vermeiden, kann man wohl hinten noch einen Parameter anhängen:
htmlspecialchars($text, ENT_XML1 ,‘ISO-8859-15’, true)
In der Praxis kann es auch reichen, statt dieser nunmehr vergurkten Funktionen einfach die bedenklichen Zeichen <, > und & durch ihre XML-Entitäten zu ersetzen.
Hinsichtlich UTF-8 - ja in der Tat, das sollte man dann auch angeben und nicht irgendwas anderes - und dabei vor allem konsistent vorgehen, sonst bekommt man da noch hübscheren Zeichensalat.
Was funktioniert jetzt genau nicht?
Die Umstellung auf UTF-8?
Die Ausgabe des Testskriptes? (das könntest du natürlich auch auf UTF-8 umstellen, um zu gucken, was dann passiert, dafür muß man oben im header die Angabe zu charset ändern. Da dort ferner text/plain steht, werden maskierte Zeichen vom Brauser nicht interpretiert, man sieht also wirklich die Maskierung, um beurteilen zu können, ob das alles wie beabsichtigt funktioniert.
Man müßte bei dem Skript zu text/html wechseln, um zu sehen, was ein HTML-Markierungssuppen-parser daraus macht (sollte jedenfalls die maskierten Zeichen interpretieren).
Das sollte aber nur beim Eurozeichen und wenigen anderen einen Unterschied machen, sonst sind die gleich und haben beide auch nichts mit UTF-8 zu tun …
Ein Problem zu lösen aber nicht zu wissen warum es gelöst ist, ist doch ziemlich lästig. Wenn man das Problem nicht verstanden hat, weiß man ja nicht ob es in Zukunft wieder auftreten wird.
Geb ich dir eigentlich recht.Aber ich hatte ja schon am Anfang erwähnt das es mir weniger um das Programmieren als vielmehr um den Inhalt der Seite geht. Sollte das Teil nochmal versagen fliegt es raus und es kommt ein anderes.
