Sonderzeichen in einem Formular
Markus Hametner
- php
Hallo,
ich habe ein Problem mit Sonderzeichen in einem Formular:
Auf Seite A füllt jemand ein Formular aus. Auf Seite B werden die Eingaben der Felder aus Seite A in eine Datenbank gespeichert und per Mail an mich versandt.
Das Problem ist nun, wenn jemand z.B. aus Polen polnische Sonderzeichen im Formular verwendet, stehen im Mail an mich die Sonderzeichen als HTML-kodiert (z.B. heißt jemand dann "Wośnak"). Dasselbe passiert auch, wenn ich via PHP die Datenbank als CSV-Datei ausgeben lasse.
Gibt es irgendeine Möglichkeit, diese HTML-Kodierung der Sonderzeichen zu "umgehen" (/etc.), damit im Mail die Eingaben so erscheinen, wie sie tatsächlich eingegeben wurden?
Hallo Markus,
Hallo,
ich habe ein Problem mit Sonderzeichen in einem Formular:
Auf Seite A füllt jemand ein Formular aus. Auf Seite B werden die Eingaben der Felder aus Seite A in eine Datenbank gespeichert und per Mail an mich versandt.
Das Problem ist nun, wenn jemand z.B. aus Polen polnische Sonderzeichen im Formular verwendet, stehen im Mail an mich die Sonderzeichen als HTML-kodiert (z.B. heißt jemand dann "Wośnak"). Dasselbe passiert auch, wenn ich via PHP die Datenbank als CSV-Datei ausgeben lasse.
Gibt es irgendeine Möglichkeit, diese HTML-Kodierung der Sonderzeichen zu "umgehen" (/etc.), damit im Mail die Eingaben so erscheinen, wie sie tatsächlich eingegeben wurden?
Offensichtlich hast du irgendwo in deinem PHP-Skript die Funktion http://de2.php.net/manual/de/function.htmlentities.php@htmlentities() verwendet, AFAIK werden in PHP Sonderzeichen nicht automatisch kodiert.
Lasse diesen Befehl weg, aber du musst unbedingt aufpassen dass du die E-Mail dann als text/plain verschickst - als text/html können die User nämlich sonst HTML-E-Mails an dich verfassen.
Bis dann!
Marc Reichelt || http://www.marcreichelt.de/
Hallo,
sorry - der Link lautet so:
http://de2.php.net/manual/de/function.htmlentities.php
Bis dann!
Marc Reichelt || http://www.marcreichelt.de/
Offensichtlich hast du irgendwo in deinem PHP-Skript die Funktion htmlentities() verwendet, AFAIK werden in PHP Sonderzeichen nicht automatisch kodiert.
Nein, habe ich nicht (habe bis heute diese Funktion gar nicht gekannt, sondern bin erst nach einigem Googeln darauf gestoßen). Was ich bräuchte wäre die genaue Umkehrfunktion davon: html_entity_decode(). Allerdings gibt es diese Funktion erst ab PHP4; der Server läuft aber noch unter PHP3 (und ein Umstieg/Portierung ist aus diversen Gründen ausgeschlossen; d.h. die Seite muß auf diesem Server funktionieren).
Da das Problem außerdem nur bei "text/plain"-Dokumenten vorkommt, würde ich eher auf ein Problem mit dem charset tippen (siehe https://forum.selfhtml.org/?t=100990&m=619419).
Was ich bräuchte wäre die genaue Umkehrfunktion davon: html_entity_decode(). Allerdings gibt es diese Funktion erst ab PHP4; der Server läuft aber noch unter PHP3
Schau mal, ob dein PHP recode eingebunden hat. Dann kannst du z.B. recode_string('html..latin1', 'text...') versuchen, aber zaubern kann das auch nicht. Beachte den zweiten Satz:
"Die GNU Recode Bibliothek ermöglicht die Konversion zwischen verschiedenen Zeichensätzen (wie ASCII, ISO Latin-1, IBM-PC und weiteren) und Eingabekonventionen (z.B. HTML oder LaTeX). Wenn eine exakte Umkodierung nicht möglich ist, werden die störenden Zeichen entfernt oder durch Annäherungen ersetzt."
Hello,
das habe ich in ähnlicher Form auch schon oft versucht zu hinterfragen.
Aber wahrscheinlich muss jedes Script auch die HTTP-Header registieren und ggf. mit den Datren zusammen vermerken.
Harzliche Grüße aus http://www.annerschbarrich.de
Tom
Das Problem ist nun, wenn jemand z.B. aus Polen polnische Sonderzeichen im Formular verwendet, stehen im Mail an mich die Sonderzeichen als HTML-kodiert (z.B. heißt jemand dann "Wośnak").
Das konnte ich so nachvollziehen. Dann hab ich mal das Attribut accept-charset="utf-8" in das form-Tag hinzugefügt ... und der Typ hieß wieder Wośnak.
Dasselbe passiert auch, wenn ich via PHP die Datenbank als CSV-Datei ausgeben lasse.
Ähm... ich nehme mal an, dass das dann auch schon so in der DB drinsteht, weil es das Form schon so geliefert hat?
Dann hab ich mal das Attribut accept-charset="utf-8" in das form-Tag hinzugefügt ... und der Typ hieß wieder Wośnak.
Habe Deine Anregung aufgegriffen und ein wenig herumprobiert. Ergebnis: Dein Vorschlag würde tatsächlich helfen ... wenn nicht UTF-8 wiederum Probleme mit anderen Sonderzeichen wie á,é und Umlauten hätte, die dann gar nicht oder als [] ausgegeben werden ...
Wie ich vermutet hatte, tritt dieses Kodierungs-Problem nur dann auf, wenn ich die Formular-Eingaben als "text/plain" ausgeben will. Die Mails könnte ich von PHP ja auch als HTML versenden lassen, womit dieses Problem umgangen wäre, aber den CSV-Export der Datenbank kann ich ja schwerlich als "text/html" ausgeben lassen ...
Hallo,
Habe Deine Anregung aufgegriffen und ein wenig herumprobiert. Ergebnis: Dein Vorschlag würde tatsächlich helfen ... wenn nicht UTF-8 wiederum Probleme mit anderen Sonderzeichen wie á,é und Umlauten hätte, die dann gar nicht oder als [] ausgegeben werden ...
Das passiert nicht, wenn Du konsequent bei UTF-8 bleibst. Es kommt eben UTF-8 vom Formular an und muss auch als solches verarbeitet werden. Deine Beispiele sehen so aus, als würdest Du UTF-8 als irgendwas anderes ausgeben. In welchem Editor (Viewer) passiert das? Welches charset soll denn Deine text/plain-Ausgabe haben? Schau mal hier http://de2.php.net/manual/en/function.utf8-decode.php und lies auch die Kommentare.
Wenn es nur Polnisch unterstützen soll, dann kannst Du der HTML-Seite und/oder dem Formular charset=ISO-8859-2 verpassen. Dann kommen die Textdaten auch in diesem Format vom Formular an. Unbehandelt (wobei ich nicht weiß, ob das mit PHP überhaupt geht oder ob man immer mit http://de.php.net/mbstring arbeiten muss) sollte Deine text/plain-Ausgabe dann auch charset=ISO-8859-2 sein.
Wenn es international sein soll, dann _musst_ Du Unicode (bsp.:UTF-8) verwenden und eben konsequent dabei bleiben. Zu Internationalisierung via PHP siehe http://www.koders.com/?s=charset+i18n&_%3Abtn=Search&_%3Ala=PHP&_%3Ali=*.
viele Grüße
Axel
Wenn es international sein soll, dann _musst_ Du Unicode (bsp.:UTF-8) verwenden und eben konsequent dabei bleiben.
Tja, dafür ist es nun zu spät ... habe schon unzählige Einträge in der Datenbank, bei denen im Formular kein accept-charset="UTF-8" angegeben war, und die somit schätze ich mal iso-8859-1-kodiert sind (das ist jedenfalls als charset der ganzen Seite im Seiten-Header angegeben). Daher kann ich das ganze nur mehr schwer auf UTF-8 umstellen (und ich wüßte auch nicht wie ich da mit den ganzen Datenbankeinträgen verfahren sollte).
Ich frage mich allerdings, wieso die polnischen Sonderzeichen bei der Ausgabe als "text/html" richtig zu sehen sind, bei "text/plain" allerdings als "ś", etc., obwohl bei beiden als charset iso-8859-1 angegeben ist ... ?
hi,
Tja, dafür ist es nun zu spät ... habe schon unzählige Einträge in der Datenbank, bei denen im Formular kein accept-charset="UTF-8" angegeben war, und die somit schätze ich mal iso-8859-1-kodiert sind (das ist jedenfalls als charset der ganzen Seite im Seiten-Header angegeben). Daher kann ich das ganze nur mehr schwer auf UTF-8 umstellen (und ich wüßte auch nicht wie ich da mit den ganzen Datenbankeinträgen verfahren sollte).
utf8_encode() könnte dabei helfen.
gewisse sonderzeichen, die das nicht "packt", müsste man dann ggf. noch per replace nachbearbeiten.
Ich frage mich allerdings, wieso die polnischen Sonderzeichen bei der Ausgabe als "text/html" richtig zu sehen sind, bei "text/plain" allerdings als "ś", etc., obwohl bei beiden als charset iso-8859-1 angegeben ist ... ?
weil du vermutlich bereits die entity-notation ś in deinen daten stehen hast.
wenn ein browser vom user eingegebene zeichen nicht innerhalb des zeichensatzes, den er für das formular benutzen soll, unterbringen kann, greift er meist dazu, für diese zeichen eben gleich die nummerische entity-schreibweise zu übermitteln.
gruß,
wahsaga
Hallo,
Ich frage mich allerdings, wieso die polnischen Sonderzeichen bei der Ausgabe als "text/html" richtig zu sehen sind,
Wo zu sehen sind? Der Browser setzt die Entities natürlich in Zeichen um, wenn er kann, sprich es entsprechende fonts gibt. Im Quelltext steht aber trotzdem "ś". Das ist dann übrigens Unicode, denn ISO-8859-x geht nur von � - ÿ.
bei "text/plain" allerdings als "ś", etc., obwohl bei beiden als charset iso-8859-1 angegeben ist ... ?
Im Text stehen die Zeichen & # 3 4 7.
Mit ISO-8859-1 kannst Du allerdings daraus kein einzelnes Zeichen machen (siehe oben) Das geht nur mit Unicode.
Du kannst natürlich mit
$string = str_replace("ś", "\xb6", $string);
http://de2.php.net/manual/en/function.str-replace.php
aus Unicode wieder Code im Bereich 0-FF machen. Das wäre dann aber ISO-8859-2.
http://www.fileformat.info/info/charset/ISO-8859-2/grid.htm
In ISO-8859-1 gibt es das Zeichen ś gar nicht.
viele Grüße
Axel
Im Quelltext steht aber trotzdem "ś". Das ist dann übrigens Unicode, denn ISO-8859-x geht nur von � - ÿ.
Verstehe ich das richtig: wenn im Formular gar keine accept-charset-Angabe steht (wie es bei mir der Fall war), dann akzeptiert es alle Zeichen - und nach welchem charset sind diese dann kodiert? Nach dem charset, der im Seiten-Header steht (in meinem Fall stand iso-8859-1)?
Wo ist es denn überall notwendig, um die Seite "international" zu machen, als charset UTF-8 anzugeben?
-Im Seitenheader
-Im Formular (ist das wirklich erforderlich?)
-Im PHP-Email-Header
-Datenbank ???
-?? sonst noch wo ??
Hallo,
Verstehe ich das richtig: wenn im Formular gar keine accept-charset-Angabe steht (wie es bei mir der Fall war), dann akzeptiert es alle Zeichen
Zunächst kann man in ein Formular alle Zeichen eingeben, die man über die Tastatur erzeugen kann. Ob die dann dort (clientseitig) auch angezeigt werden, hängt davon ab, ob der Browser das kann.
- und nach welchem charset sind diese dann kodiert? Nach dem charset, der im Seiten-Header steht (in meinem Fall stand iso-8859-1)?
Ja. Zumindest der IE akzeptiert dort auch keinen Unterschied. Du kannst also das Formular nicht anders codieren als das Dokument.
Bleiben wir bei charset=ISO-8859-1:
Solche Zeichen, die nicht US-ASCII sind, aber im charset werden URL-codiert. Bsp.: ü = %FC. Die Serverseite macht daraus dann wieder ISO-8859-1, also ü.
Zeichen, die nicht in ISO-8859-1 enthalten sind, werden URL-codiert als Entity gesendet. Bsp.: ś = %26%23347%3B. Die Serverseite macht daraus die _6_ Zeichen & # 3 4 7 ;. HTML erkennt das natürlich als Entity.
Mit charset="UTF-8" sendet der Browser Unicode UTF-8 codiert.
Bsp.: ü = %C3%BC
11000011 10111100
110xxxxx 10xxxxxx
00011 111100
%FC
und ś = %C5%9B
11000101 10011011
110xxxxx 10xxxxxx
101 011011
%15B
347
http://www.ietf.org/rfc/rfc3629.txt
Wie Du siehst hat UTF-8 unicode Ähnlichkeiten mit URL-Encoding, darf aber nicht als solches decodiert werden.
Wo ist es denn überall notwendig, um die Seite "international" zu machen, als charset UTF-8 anzugeben?
-Im Seitenheader
Ja.
-Im Formular (ist das wirklich erforderlich?)
Jain ;-)
-Im PHP-Email-Header
-Datenbank ???
Es muss jedenfalls dort überall als UTF-8 betrachtet werden.
Serverseitig wirst Du nicht einfach einen charset-Eintrag setzen können. Die eingesetzte Sofware muss mit UTF-8 umgehen können. Hierfür einfach ins Manual von PHP, MySQL &Co schauen.
viele Grüße
Axel