Re: Default input encoding for htmlspecialchars/htmlentities
| From: | Ángel González | Date: | Fri, 24 Aug 2012 21:23:36 +0000 |
| Subject: | Re: Default input encoding for htmlspecialchars/htmlentities | ||
| References: | 1 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-62462@lists.php.net to get a copy of this message | ||
El 23/08/12 18:06, Rasmus Lerdorf escribió:
> htmlspecialchars(), htmlentities(), html_entity_decode() and
> get_html_translation_table() all take an encoding parameter that used to
> default to iso-8859-1. We changed the default in PHP 5.4 to UTF-8. This
> is a much more sensible default and in the case of the encoding
> functions more secure as it prevents invalid UTF-8 from getting through.
> If you use 8859-1 as the default but your app is actually in UTF-8 or
> worse, some encoding that isn't low-ascii compatible then
> htmlspecialchars()/htmlentities() aren't doing what you think they are
> and you have a glaring security hole in your app.
I don't see how passing utf-8 as latin1 gets into a security hole. The
characters
you want to replace (&'"<>) in utf-8 are the same as in latin1, and it
can't
get trickied with synchronizations. If it was passing latin1 to a function
expecting utf-8 or "some encoding that isn't low-ascii compatible" then
I see the hole, but not here.
> So do we create a new default_input_encoding ini directive mid-stream in
> 5.4 for this? Of course with the longer-term in mind that this will be
> part of a unified set of encoding settings in 5.5 and beyond.
Yes