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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
