Req #66264 [Com]: htmlspecialchars_decode() does not take an encoding argument.

From: Date: Mon, 07 May 2018 03:31:45 +0000
Subject: Req #66264 [Com]: htmlspecialchars_decode() does not take an encoding argument.
References: 1  Groups: php.bugs 
Request: Send a blank email to php-bugs+get-215139@lists.php.net to get a copy of this message
Edit report at https://bugs.php.net/bug.php?id=66264&edit=1 ID: 66264 Comment by: spam2 at rhsoft dot net Reported by: lyle dot mantooth at primasupply dot com Summary: htmlspecialchars_decode() does not take an encoding argument. Status: Open Type: Feature/Change Request Package: Strings related Operating System: Linux Mint PHP Version: 5.4.22 Block user comment: N Private report: N New Comment: @yohgaki@php.net: you are compleltly off-topic with PHP 5.4 the default was changed away from latin in PHP with PHP 5.6 that terrible BC was mitigated with default_charset (way too late) the workaround for existing applications in 5.4 was to spit 'ISO8859-1' as $encoding param for htmlentities(), html_entity_decode() and friends all around the codebase and the funtion in question is lacking that param Previous Comments: ------------------------------------------------------------------------ [2018-05-06 22:52:58] yohgaki@php.net The best practice is normalize and validate encoding at application input processing code. i.e. Normalize and validate encoding as fast as it can. With MVC model, controllers should take care encoding normalization and validation. Encoding validation by this function is still useful as multilayer protection, but it is rather optional. Instead of promoting bad practices (too late encoding validations), it may be better to promote encoding validation with Fail Fast principle. ------------------------------------------------------------------------ [2018-05-06 20:46:08] cmb@php.net Since all supported character encodings[1] are ASCII compatible (i.e. they are supersets of ASCII), and all "htmlspecialchars" are ASCII characters, the actual encoding doesn't really matter for htmlspecialchars_decode(). So adding an $encoding parameter would be useless, maybe except for checking whether the given string is valid for the given encoding. [1] <https://github.com/php/php-src/blob/PHP-7.2.5/ext/standard/html_tables.h#L44-L78> ------------------------------------------------------------------------ [2013-12-11 18:10:32] aharvey@php.net Transmogrifying into a feature request: htmlspecialchars_decode() doesn't currently support a character set parameter (although the internal php_unescape_html_entities() function it calls does). ------------------------------------------------------------------------ [2013-12-11 14:41:21] lyle dot mantooth at primasupply dot com Description: ------------ --- From manual page: http://www.php.net/function.htmlspecialchars-decode --- Of all the functions that handle converting HTML entities to and from their character equivalents, htmlspecialchars_decode() is the only one that doesn't seem to care about the string encoding. * htmlspecialchars(), $encoding parameter added in PHP 4.1.0. * htmlentities(), $encoding parameter added in PHP 4.1.0. * html_entity_decode(), function added in PHP 4.3.0, presumably with $encoding parameter from the beginning. * hmtlspecialchars_decode(), function added in PHP 5.1.0, but no $encoding parameter. This may be only a documentation problem, but if it isn't, then it's a real problem working with this API without even knowing what the default encoding is. Did it change in PHP 5.4.0 for this function, like it did for the others? I still don't know. ------------------------------------------------------------------------ -- Edit this bug report at https://bugs.php.net/bug.php?id=66264&edit=1

« previous php.bugs (#215139) next »