[PHP-DEV] PHP 4.0 Bug #9426 Updated: Form variables encoding problem

2001-02-24 Thread d . sbragion

ID: 9426
User Update by: [EMAIL PROTECTED]
Status: Open
Bug Type: Unknown/Other Function
Description: Form variables encoding problem

It turned out to be a problem with a:

META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=ISO-8859-1"

header that caused encoding by the browser prior to sendind data to PHP. Now there's 
another problem. The '’' doesn't get encoded by the htmlentities() function. This 
char, and others, is an illegal char according to the WDG html validator and should be 
encoded. I think an extended version of the htmlentities() function, which encodes 
every char that need encoding, not only the ones in the 
get_html_translation_table(HTML_ENTITIES) table, should be considered. Of course 
encoding should be performed in the '#;' form.

Previous Comments:
---

[2001-02-23 12:51:48] [EMAIL PROTECTED]
Sorry but everything gets screwed because of the mixture of html entities and real 
chars. The char that gives problems is '’', the corresponding html entitie is 
amp;#8217;, the html entitie provided by FrontPage is amp;#146;. Looking directly at 
the html code make it easier to understand what's going on.

---

[2001-02-23 12:45:17] [EMAIL PROTECTED]
When I enter some special chars in a textual form field (either 'INPUT TYPE="text"' or 
'TEXTAREA') they get encoded like an html entitie. For example this '’' gets encoded 
as '#8217;' in the variable of the form handling script (I hope this won't trigger 
the bug, the first char is like a '`' but "reversed", almost like a superscript small 
'/'). No coding happens for a plain typed '#8217;', so there's no way to distinguish 
between the two cases in the form handling script and so there's no way to safely 
reverse the encoding. Browser is IE 5.5 on Windows 98.

This may happen for example doing cut  paste from WordPad, Word or existing web 
pages. I tried the same thing pasting into FrontPage Express. It encodes it as 
'#146;' instead of '#8217;', may be it's just the encoding that's wrong.

P.S. Sorry for my poor English

---


Full Bug description available at: http://bugs.php.net/?id=9426


-- 
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




[PHP-DEV] PHP 4.0 Bug #9426 Updated: Form variables encoding problem

2001-02-23 Thread d . sbragion

ID: 9426
User Update by: [EMAIL PROTECTED]
Status: Open
Bug Type: Unknown/Other Function
Description: Form variables encoding problem

Sorry but everything gets screwed because of the mixture of html entities and real 
chars. The char that gives problems is '’', the corresponding html entitie is 
amp;#8217;, the html entitie provided by FrontPage is amp;#146;. Looking directly at 
the html code make it easier to understand what's going on.

Previous Comments:
---

[2001-02-23 12:45:17] [EMAIL PROTECTED]
When I enter some special chars in a textual form field (either 'INPUT TYPE="text"' or 
'TEXTAREA') they get encoded like an html entitie. For example this '’' gets encoded 
as '#8217;' in the variable of the form handling script (I hope this won't trigger 
the bug, the first char is like a '`' but "reversed", almost like a superscript small 
'/'). No coding happens for a plain typed '#8217;', so there's no way to distinguish 
between the two cases in the form handling script and so there's no way to safely 
reverse the encoding. Browser is IE 5.5 on Windows 98.

This may happen for example doing cut  paste from WordPad, Word or existing web 
pages. I tried the same thing pasting into FrontPage Express. It encodes it as 
'#146;' instead of '#8217;', may be it's just the encoding that's wrong.

P.S. Sorry for my poor English

---


Full Bug description available at: http://bugs.php.net/?id=9426


-- 
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]