Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:67999
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain nebm.ist.utl.pt from 193.136.128.21 cause and error)
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8;
 format=flowed
Content-Transfer-Encoding: 7bit
Date: Fri, 28 Jun 2013 07:21:54 +0200
To: <internals@lists.php.net>
Organization: =?UTF-8?Q?N=C3=BAcleo_de_Engenharia_Biom=C3=A9dica_do_Insti?=
 =?UTF-8?Q?tuto_Superior_T=C3=A9cnico?=
In-Reply-To: <CAKOpQSxgey=GydmZbKc7Dgo6sQdDq+wBZ5u+O5rNZmH6FfgDmw@mail.gmail.com>
References: <CAKOpQSxbapKMkdSKA7QNC+c1Ydo4m3Tyfb7nuZQBJre4B1rABw@mail.gmail.com>
 <CAGa2bXb=GwSGVNrD97WLYn=LjEwZF3fOm-cjKJ0Vb1aSV3P0Vw@mail.gmail.com>
 <CAKOpQSz6EooixAJsLBdCzYsU5OFqx=zqRCeEpDC3hPqvTffkMA@mail.gmail.com>
 <CAGa2bXawVkq+Qz+ZGFb5pXq5Z-SSOmgX4vtrR=_Z-btAgosX4A@mail.gmail.com>
 <CAKOpQSxgey=GydmZbKc7Dgo6sQdDq+wBZ5u+O5rNZmH6FfgDmw@mail.gmail.com>
Message-ID: <682a8bb626dd810bed4112eb939d14c3@nebm.ist.utl.pt>
User-Agent: RoundCube Webmail/0.8-rc
Subject: Re: [PHP-DEV] =?UTF-8?Q?ENT=5FALL=20or=20similar=20option=20for?=
 =?UTF-8?Q?=20htmlspecialchars=5B=5Fdecode=5D=3F?=
From: glopes@nebm.ist.utl.pt (Gustavo Lopes)

Em 2013-06-28 4:10, Kris Craig escreveu:
> On Thu, Jun 27, 2013 at 6:43 PM, Yasuo Ohgaki <yohgaki@ohgaki.net> 
> wrote:
>
>> 2013/6/27 Kris Craig <kris.craig@gmail.com>
>>
>>> Yeah I tried html_entity_decode already, but it just returned NULL. 
>>> On
>>> the same input string, htmlspecialchars_decode returned the input 
>>> string
>>> but with *some* special characters decoded; 10 and 13 ("\r\n", I 
>>> think)
>>> were left in their encoded state.  I'm not sure why there wouldn't 
>>> be an
>>> option to decode all html special characters.
>>>

You are missing the design purpose of htmlspecialchars_decode and 
html_entity_decode. Thruth is, they are not useful as they might seem. 
Their purpose is not to decode all the entities, like a browser would 
do. We do not implement anything approaching the sort parsing a browser 
would do; for instance, html 5 says you should accept certain entities 
not terminated with ; and parse the stream in a certain way and we don't 
do it at all. The purpose of those two functions is just to provide 
something approaching an inverse function for htmlspecialchars() and 
htmlentities(). html_entity_decode() has somewhat deviated from this 
(for instance, it decodes all numeric entites), but I think this should 
nevertheless be the proper way one should think about those two 
functions.

>>
>> Not only HTML entities, we really needs to add several 
>> decoder/encoder to
>> core.
>> For instance, Javascript \uXXXX, HTML &#XX/&#XXXX, etc.
>> I hope someone is working on it :)
>>
>
> Would you be interested in co-authoring an RFC with me for this?
>

See http://php.net/manual/en/transliterator.transliterate.php For HTML 
entities, out of the box, only a transliterator for numeric entities is 
provided (hex-any/XML10), but you can easily build your ruleset for the 
named entities. The performance will be below of that of a dedicated 
algorithm, though. And it only supports UTF-8.

-- 
Gustavo Lopes