note 83935 deleted from function.utf8-decode by cmb
| From: | cmb@php.net | Date: | Sun, 11 Dec 2016 11:29:05 +0000 |
| Subject: | note 83935 deleted from function.utf8-decode by cmb | ||
| References: | 1 | Groups: | php.notes |
| Request: | Send a blank email to php-notes+get-208522@lists.php.net to get a copy of this message | ||
Note Submitter: webmaster at lapstore dot de
----
[EDITED BY cataphract AT php DOT net - NOTE: This has been fixed
in PHP 5.3.4 and 5.2.15.]
Warning!
This function contains a possible security risk when you try to convert escaped strings (see
addslashes() and related functions).
It reacts nasty on broken multibyte sequences. In UTF-8, follow-up bytes ALWAYS have the binary
pattern 10xxxxxx, but this fact is not handled by utf8_decode in the way you would expect: If you
pass a start byte (110xxxxx, 1110xxxx, 11110xxx - or even invalid sequences like 11111100), followed
by one or more non-multibyte chars (0xxxxxxx), the start sequence "char" will be replaced
by '?' (0x3F) and up to three following chars will disappear even if they are
single-byte-chars (0xxxxxxx). So if you escape a string with a typical escape char like backslash,
you would expect that your escaping would always survive a call to utf8decode because the escape
char is in the assumed safe ascii range 0-127, but that is NOT the case!
Try things like utf8_decode("test: ü\\\"123456") to check it out.
To avoid problems take care that string-escaping always is the last step of data manipulation when
you depend on leak-proof escaping.