Summary | broken php htmlspecialchars workaround needed |
Queue | Horde Framework Packages |
Queue Version | FRAMEWORK_3 |
Type | Bug |
State | Not A Bug |
Priority | 1. Low |
Owners | |
Requester | viljo.viitanen (at) helsinki (dot) fi |
Created | 09/08/2008 (6149 days ago) |
Due | |
Updated | 09/10/2008 (6147 days ago) |
Assigned | |
Resolved | 09/08/2008 (6149 days ago) |
Github Issue Link | |
Github Pull Request | |
Milestone | |
Patch | No |
If I understand correctly, according to comment "[18 Jul 12:10am UTC]
moriyoshi at php.net" php developers does not consider this to be a
php bug or even consider fixing this in php. So, the application
calling htmlspecialchars need to check that input is valid utf-8 (when
using utf-8 charset argument).
State ⇒ Not A Bug
Priority ⇒ 1. Low
with user submitted content.
Priority ⇒ 3. High
New Attachment: horde-text-filter-text2html-htmlspecialchars.txt
Patch ⇒ No
Milestone ⇒
Queue ⇒ Horde Framework Packages
Summary ⇒ broken php htmlspecialchars workaround needed
Type ⇒ Bug
State ⇒ Unconfirmed
character data (e.g. raw latin1 'รค') and encoding is set to utf-8
(also possibly other multibyte encodings), htmlspecialchars returns
empty string (http://bugs.php.net/bug.php?id=43896).
horde should compensate for this, as not showing anything in an email
when it contains broken utf-8 data is just plain wrong.
So, before using htmlspecialchars with charset utf-8, data should be
checked that it is (at least) valid utf-8.
Not sure if this is horde or imp bug. In our local installation I
fixed the problem with attached patch to
lib/Horde/Text/Filter/text2html.php. We get a lot of messages with
broken utf-8, unfortunately.