Package home | Report new bug | New search | Development Roadmap Status: Open | Feedback | All | Closed Since Version 0.9.3

Request #5886 Passing default-encoding to htmlentities
Submitted: 2005-11-07 14:13 UTC
From: tobias at neuyork dot de Assigned: olivierg
Status: Closed Package: Structures_DataGrid
PHP Version: 4.3.4 OS: Suse 9.1
Roadmaps: (Not assigned)    
Subscription  
Comments Add Comment Add patch


Anyone can comment on a bug. Have a simpler test case? Does it work for you on a different platform? Let us know! Just going to say 'Me too!'? Don't clutter the database with that please !
Your email address:
MUST BE VALID
Solve the problem : 48 - 1 = ?

 
 [2005-11-07 14:13 UTC] tobias at neuyork dot de
Description: ------------ The HTMLTable-Renderer doesn't use the default-charset when running the function htmlentities()(DataGrid/Renderer/HTMLTable.php). I've got a problem with UTF-8 encoded characters. /* ORIGINAL */ //$content = htmlentities($row[$column->fieldName]); // modified to: $content = htmlentities($row[$column->fieldName], ENT_COMPAT, mb_internal_encoding());

Comments

 [2005-11-08 18:41 UTC] olivierg at php dot net
This is supposed to have been fixed in CVS by using htmlspecialchars() instead of htmlentities(), see bug #5829. Does this work for you ? Your solution looks cleaner though... Meanwhile, bug #5838 got reported, insisting on the argument that the HTMLTable renderer should not perform such conversion at all. If I am to use your fix instead of the previous one : - is mb_internal_encoding() reliable to know what charset the user needs ? - instead, shouldn't there be some options to specify the charset and to enable/disable HTML entities/specialchars conversion ? - or maybe that this conversion should not be performed at all by the HTML Table renderer. A column formatter could be used to do so. But this looks like a BC break...
 [2005-11-09 09:18 UTC] tobias at neuyork dot de
The bugfix for bug #5829 is workin for my case. In my opinion, the new bug #5838 describes how the DataGrid should act. A data-formatter that can be plugged to the DataGrid would be very nice. Maybe it should be possible to plug-in your own class/function! But for making a fast implementation this should also do it: - mb_internal_encoding() as a default encoding-option in the datagrid - if there should be no conversion, this could be unset - this encoding-option could also be overwritten with a user-defined-encoding - HTMLTable is then using this encoding-option for doing field-conversion. If encoding-option is not set, there is no conversion. i hope this could be a solution
 [2005-11-09 09:21 UTC] tobias at neuyork dot de
The bugfix for bug #5829 is workin for my case. In my opinion, the new bug #5838 describes how the DataGrid should act. A data-formatter that can be plugged to the DataGrid would be very nice. Maybe it should be possible to plug-in your own class/function! But for making a fast implementation this should also do it: - mb_internal_encoding() as a default encoding-option in the datagrid - if there should be no conversion, this could be unset - this encoding-option could also be overwritten with a user-defined-encoding - HTMLTable is then using this encoding-option for doing field-conversion. If encoding-option is not set, there is no conversion. i hope this could be a solution
 [2006-03-01 22:14 UTC] olivierg at php dot net
This request has been implemented in CVS. The default value of the new HTMLTable "encoding" option (related to Bug #6031) is now set from mb_internal_encoding() if the mbstring extension is loaded. Otherwise, the default is ISO-8859-1. Thanks for the report and suggestions.