Zeichenkodierung und Maskierung
heinetz
- html
0 suit0 ichbinich0 heinetz0 dedlfix
0 Der Martin
0 dedlfix
Hallo Forum,
mit dem Thema Zeichenkodierung habe ich mich nun immer wieder
auseinandergesetzt und verstehe es nun mehr und mehr. Früher
habe ich mich nicht um korrekte Zeichnkodierung geschehrt und
alle möglichen HTML-Sonderzeichen maskiert. Jetzt, wo ich
begriffen habe, dass ein 'ä' im XHTML-Quellcode auch wie ein
'ä' dargestellt wird, wenn nur alle Angaben zur Zeichenkodierung
korrekt sind, vermeide ich die Maskierung nach Möglichkeit.
Und hier kommt mein Problem/meine Frage:
Wie geht man korrekt mit einem Anführungszeichen um, dass in
der MySQL-DB als sollches gespeichert ist und in einem
Formularfeld angezeigt werden soll ?
dank und beste gruesse,
heinetz
mit dem Thema Zeichenkodierung habe ich mich nun immer wieder
auseinandergesetzt und verstehe es nun mehr und mehr. Früher
habe ich mich nicht um korrekte Zeichnkodierung geschehrt und
alle möglichen HTML-Sonderzeichen maskiert.
Das waren nie mehr als 5 :)
Jetzt, wo ich
begriffen habe, dass ein 'ä' im XHTML-Quellcode auch wie ein
'ä' dargestellt wird, wenn nur alle Angaben zur Zeichenkodierung
korrekt sind, vermeide ich die Maskierung nach Möglichkeit.
Auch in HTML wird ein ä wie ein ä dargestellt - mit XHTML hat das nichts zu tun.
Und hier kommt mein Problem/meine Frage:
Wie geht man korrekt mit einem Anführungszeichen um, dass in
der MySQL-DB als sollches gespeichert ist und in einem
Formularfeld angezeigt werden soll ?
Das gehört zu den 5 HTML-Sonderzeichen. Die sollte man zur Sicherheit immer maskieren - auch wenn es unter umständen nicht notwendig ist.
<a href='#' title='fo"bar'>Blah</a>
hier muss das Anführungszeichen z.B. nicht maskiert werden, es schadet aber nicht, dort $quot; zu notieren.
Ggf solltest du diesen Artikel lesen:
http://www.w3.org/International/questions/qa-escapes
Hallo,
<a href='#' title='fo"bar'>Blah</a>
hier muss das Anführungszeichen z.B. nicht maskiert werden, es schadet aber nicht, dort $quot; zu notieren.
besser "
vg ichbinich
besser "
Wozu? Auf die Fehlerkorrektur des Browser zu hoffen macht mehr Spass :p
hi,
Das waren nie mehr als 5 :)
Jetzt, wo ich
begriffen habe, dass ein 'ä' im XHTML-Quellcode auch wie ein
'ä' dargestellt wird, wenn nur alle Angaben zur Zeichenkodierung
korrekt sind, vermeide ich die Maskierung nach Möglichkeit.Auch in HTML wird ein ä wie ein ä dargestellt - mit XHTML hat das nichts zu tun.
schon klar.
Ich habe irgendwann mal gelesen, dass man htmlspecialchars()
im Grunde nicht benötigt und immer htmlentities() verwenden
soll. Nun habe ich in meinem System halt gerade die ganzen
Maskierungen von 'ä','ü' usw eliminiert und stelle fest, dass
mir ein Anführungszeichen einen Strich durch die Rechnung
macht. Daher die Frage. Ich habe den Sinn von htmlspecialchars()
jetzt so verstanden, dass es sich eben um das Anführungszeichen
(und die anderen 4) schon kümmert, aber 'ä' und 'ü' in Ruhe
lässt. Und es sieht so aus, als solle ich das verwenden.
beste gruesse,
heinetz
Hi!
Ich habe irgendwann mal gelesen, dass man htmlspecialchars() im Grunde nicht benötigt und immer htmlentities() verwenden soll.
Der Autor hatte vermutlich eine Wissenslücke. htmlspecialchars() ist das Minimum[*], htmlentities() braucht man nur, wenn man Probleme mit der Zeichenkodierung nicht ordentlich lösen will oder kann.
[*] Wie gesagt, man muss nicht immer in allen Situationen alle 4 Zeichen berücksichtigen, es schadet aber auch nicht.
Lo!
Hallo,
Ich habe irgendwann mal gelesen, dass man htmlspecialchars() im Grunde nicht benötigt und immer htmlentities() verwenden soll.
wenn überhaupt, dann wohl eher umgekehrt ...
Ciao,
Martin
Hi!
Wie geht man korrekt mit einem Anführungszeichen um, dass in der MySQL-DB als sollches gespeichert ist und in einem Formularfeld angezeigt werden soll ?
Kontextgerecht. Immer.
HTML verlangt in einigen Situationen, dass ein " als " (und noch zwei anderen Schreibweisen) zu schreiben ist. Eine solche Situation hast du mit dem Formularfeld: value=""". Es ginge auch: value='"', dann aber value=''' für ein '. Es gibt htmlspecialchars(), das immer richtig arbeitet, solange du "" für die Attributbegrenzung nimmst.
MySQL kennt auch Regeln, wie Strings zu notieren sind. Üblich ist, die String in '' einzufassen, wobei das " unproblematisch ist. Das ' wäre dann zu beachten. Die MySQL-API kennt die Funktion mysql_real_escape_string(), die sich für Strings um alle Zeichen mit Sonderbedeutung kümmert.
Lo!
Es gibt htmlspecialchars(), das immer richtig arbeitet, solange du "" für die Attributbegrenzung nimmst.
Nicht wirklich - ENT_NOQUOTES darf nicht gesetzt sein ;)
Aber ansonsten hast du recht - da <, >, ", ' und & in sämlichen unterstützen Zeichencodierungen an derselben Stelle liegen, ist es bei htmlspecialchars() tatsächlich egal.
Bei htmlentities() muss man hingegen schon aufpassen.
@@suit:
nuqneH
da <, >, ", ' und & in sämlichen unterstützen Zeichencodierungen an derselben Stelle liegen
Vorsicht, es soll Zeichencodierungen geben, die im Bereich 0 bis x7F nicht mit ASCII übereinstimmen.
Qapla'
Vorsicht, es soll Zeichencodierungen geben, die im Bereich 0 bis x7F nicht mit ASCII übereinstimmen.
Recht hast du, mein Fehler:
"For the purposes of this function, the charsets ISO-8859-1, ISO-8859-15, UTF-8, cp866, cp1251, cp1252, and KOI8-R are effectively equivalent, as the characters affected by htmlspecialchars() occupy the same positions in all of these charsets."
d.h. bei BIG5, GB2312, BIG5-HKSCS, Shift_JIS und EUC-JP - also bei chinesischenund japanische Kodierungen - ist Vorsicht geboten.
Hi!
da <, >, ", ' und & in sämlichen unterstützen Zeichencodierungen an derselben Stelle liegen
Vorsicht, es soll Zeichencodierungen geben, die im Bereich 0 bis x7F nicht mit ASCII übereinstimmen.
Ja, eine armenische beispielsweise. Aber wie pflege ich sonst immer einzuschränken: für alle ISO-8859 und UTF-8. Denn alles andere will man heutzutage nicht verwenden oder kommt hierzulande selten damit in Berührung.
Lo!