PHP 4.0 Bug #6625 Updated: htmlspecialchars should escape "'" character

ID: 6625 Updated by: stas Reported By: jon+php-dev@unequivocal.co.uk Status: Closed Bug Type: Feature/Change Request Assigned To: cmv Comments: Previous Comments: --------------------------------------------------------------------------- [2000-09-12 01:57:14] cmv@php.net 1) I understand your comments. Treating me like a child doesn't earn you points or help your cause. 2) The reason I keep bring up databases is because that was the original reason this issue came up. I suggest you re-read bug 5254 and see why the individual wanted single quotes to be escaped. 3) Just because you *can* write HTML with single quotes, doesn't mean we are about to change the language to be (potentially) backwardly-incompatible with the million-plus existing users of PHP4.0.1, PHP4.0.0 and all PHP3.x versions. 4) Any code that uses get_html_translation_table() to check for HTML references is broken, since it does not report single quotes. My code (which I will not post here) read META tags from a given URL, or allowed the user to enter some META tags, then ran sanity checking on them to make sure they were valid. Basically, anything that relied on this function working the way it did (i.e. not changing single quotes) no longer worked. 5) You say "htmlspecialchars is supposed to encode all characters that are special to HMTL." Says who? No, HTMLSpecialChars() is supposed to encode the double-quote, ampersand, less-than and greater-than signs. That's what the manual says. If anything, HTMLSpecialChars() and HTMLEntities() are supposed to convert those characters into their equivalent character entity. The single quote does not have a character entity, only a numeric one. Refer to http://www.w3.org/TR/html4/sgml/entities.html 6) I can't think of very many cases (except for the one I mentioned) where this change would break PHP code. However, just because you or I can't think of examples, doesn't mean that there aren't any. Commiting a change to the language that is definitly backwardly-incompatible (i.e. the function behaves differently than it used to) is not a good thing to do, no matter how "safe" you think it is. Unless you can convince me and/or the core developers, and are positive that this won't break existing code, it's not going to happen. It shouldn't have happened in the first place. Especially given the possibility of breakage ... and because (as you have shown in your notes in the manual) it is trivial to implement in a user-defined function. --------------------------------------------------------------------------- [2000-09-12 00:07:03] jon+php-dev@unequivocal.co.uk You're making it very difficult to remain polite here. I shall summarise in nice easy-to-understand bite-size pieces: It is nothing to do with databases. Databases are nothing to do with it. It is to do with HTML. Not databases. The apostrophe is a special character in HTML. htmlspecialchars is supposed to encode all characters that are special to HMTL. It does not, because it does not encode apostrophes. Backslashes are not the correct way to encode characters in HTML. Entities are the correct way to encode characters. As you can tell by what this function does with other special characters. The function is broken until it encodes apostrophes. The only reason not to make it encode apostrophes would be for reasons of backwards compatibility. Making it encode extra characters is highly unlikely to break old code. You said in a previous bug report that it did, in fact, break code that you had. So it would be helpful if you could explain how, so that the problem could be understood. --------------------------------------------------------------------------- [2000-09-11 23:53:38] cmv@php.net Change the quotes around your PHP code to double quotes, and it works just fine. As for escaping neither, I hope you agree that would just be silly. Again, the reason this function was (erroneously) changed in the first place was because of this comment: > Because a ' is used for db queries and I think it's pretty > standard behaviour to escape it as well. > For example if you use PHP together with Javascript, > it's much easier if it's escaped. In the first case (DB), use addslashes() or turn magic quotes on. In the second case (JS), you can use addslashes() also, or urlencode() or strtr(). Besides, if you want an apostrophe in your database field, you should be using "'", not "'". Otherwise, you're going to get the 6-character string "'" out of the database, not the one-character single quote. Then what function do you use to convert it back to single-quotes? --------------------------------------------------------------------------- [2000-09-08 08:49:25] jon+php-dev@unequivocal.co.uk I will add a note to the manual. I am mystified as to what code could be broken by escaping additional characters, however. Could one of the people who had some code which broke give us an excerpt so we can understand the problem? --------------------------------------------------------------------------- [2000-09-08 08:41:09] waldschrott@php.net we cannot simply break backwards compatibility, maybe we should add another function or an optional parameter to this one where *both* are converted there have never been complaints about this shortcoming as opposed to where scripts broke changing this function (month ago or so) --------------------------------------------------------------------------- The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online. Full Bug description available at: http://bugs.php.net/?id=6625