| 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.