encodeForHTML

This page should cross-ref to the page for htmlEditFormat() (http://help.adobe.com/en_US/ColdFusion/10.0/CFMLRef/WSc3ff6d0ea77859461172e0811cbec22c24-7 847.html), as well as discuss the differences and merits of each; both in the context of intended usage and functionality.

Hi Adam,

Thank you for your feedback. The docs have been pushed live for CF10 http://www.adobe.com/support/coldfusion. We will make the necessary changes during the next doc refresh cycle.

Regards,

Suhas Yogin

When I try "EncodeForHTML('%Device%')" I end up with "Þvice%" which displays on the page as "Þvice%"  Obviously this isn't what I intended.  Is there a way to prevent this function from assuming the input string is encoded?

I see the same. I'd raise a bug if I was you. As for a work-around, not sure, given I don't see why it's messing with your string in the first place (it already seems safe to me?)

--

Adam

Alright, until I know more I'm sticking with the old HTMLEditFormat.  In the mean time I've added Bug 3566150.

Just FYI, I did some analysis here:

According to the docs for OWASP’s encodeForHtml(), this function ought to be escaping characters in these ranges: 00-08, 0B-0C, 0E-1F, and 7F-9F. However, obviously, there are no characters in those ranges in that input string.

Now I can see what’s going on: a THORN is HTML character entity 222, which is DE in hex, so if one was to treat "%DE" as a percent-encoded hex charcter, then that’d be a thorn. However percent encoding has got nothing to do with HTML (it’s to do with URIs), so that interpretation seems irrelevant to me.  What I do know is that in the context of HTML, "%device%" doesn’t need encoding to be "safe", so it shouldn’t be touched by this function.

Not that this helps you, but it helps understand what's going on.

I've voted for the bug.

--

Adam