Edit report at http://bugs.php.net/bug.php?id=25927&edit=1

 ID:                 25927
 Updated by:         cataphr...@php.net
 Reported by:        acm at tweakers dot net
 Summary:            get_html_translation_table calls the ' ' instead
                     of '
-Status:             Re-Opened
+Status:             Closed
 Type:               Bug
 Package:            Unknown/Other Function
 Operating System:   Linux
 PHP Version:        4.3.3
 Assigned To:        cataphract
 Block user comment: N

 New Comment:

Fixed for PHP 5.3 and trunk.


Previous Comments:
------------------------------------------------------------------------
[2010-10-12 04:51:15] cataphr...@php.net

Automatic comment from SVN on behalf of cataphract
Revision: http://svn.php.net/viewvc/?view=revision&revision=304340
Log: - Added a 3rd parameter to get_html_translation_table. It now takes
a charset
  hint, like htmlentities et al.
- Fixed bug #49407 (get_html_translation_table doesn't handle UTF-8).
- Fixed bug #25927 (get_html_translation_table calls the ' '
instead of
  ').
- Fixed tests for get_html_translation_table and unified the Windows and
  non-Windows versions of the tests.

------------------------------------------------------------------------
[2003-11-20 14:00:06] mike-php at emerge2 dot com

Does the same in Windows PHP 4.3.4.

------------------------------------------------------------------------
[2003-10-21 05:14:42] acm at tweakers dot net

Well, maybe so.



But I was refering to a function that tries to undo the changes of
htmlspecialchars/htmlentities.



If htmlspecialchars changes ' to ' and you want to depend on
get_html_translation_table to undo all changes, you expect it to return
' = ' instead of ' = ', since that's the change
htmlspecialchars/htmlentities did aswell.

It didn't change it to '



If you really wanted to create a perfect entity-decoder, you'd indeed
have to cope with all those &*; entities, including all the
&#[0-9]{2,3};-like entities.



But for the simple "undo the htmlspecialchars"-like function that is not
necessary.



And again, get_html_translation_table returns "how the
htmlspecialchars/entities functions do it", not "all possible
translations" or "just a valid version, maybe not what our own functions
do", doesn't it? :)



To explain what I mean:

if you do 

echo html_entity_decode(htmlspecialchars("'", ENT_QUOTES));

you get ' back.



If you do:

function my_entity_decoder($string)

{

$trans = array_flip(get_html_translation_table(ENT_HTML_SPECIALCHARS,
ENT_QUOTES));

$original = strtr($encoded, $trans);

}



echo my_entity_decoder(htmlspecialchars("'", ENT_QUOTES));

Where you trust the get_html_translation_table-function to return enough
information to output ' again...



But if it all doesn't matter to you guys, why do the two change at all?

Why does the htmlspecialchars change it to ' why the
get_html_translation_table claims it changes it to ' ??

------------------------------------------------------------------------
[2003-10-20 21:51:42] moriyo...@php.net

Not quite. When you have to write your own html_entity_decode(), you
should cope with any forms of the numeric entity including hexadecimal
style. It's not as simple as the snippet in the manual page.



------------------------------------------------------------------------
[2003-10-20 19:04:17] acm at tweakers dot net

Well, it's cute that both are valid, but that's not the point...

get_html_translation_table is supposed to return "how php's functions
translate it", not "any way which is valid".



And in that way, it _fails_ to do so.

Since the function html_entity_decode is only available as of php-4.3.0,
anyone who has a similar function (based on the php-example on the
documentpage!), finds it broken because of this.



In that sense it is, imho, a bug.

Quoting you're own documentation:

"get_html_translation_table --  Returns the translation table used by
htmlspecialchars() and htmlentities()"

------------------------------------------------------------------------


The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at

    http://bugs.php.net/bug.php?id=25927


-- 
Edit this bug report at http://bugs.php.net/bug.php?id=25927&edit=1

Reply via email to