htmlEditFormat()? or encodeForHtml()? or ESAPIEncode('html',...)?


Ok, so htmlEditFormat() was deprecated in ACF, see
“…Note: Adobe recommends that you use the EncodeForHTML function, not the HTMLEditFormat function, to escape special characters in a string for use in HTML in all new applications. …”

encodeForHTML() was deprecated in Lucee, see

“…this function is deprecated, use function ESAPIEncode(‘html’,…) instead. …”

ESAPIEncode() is not supported in ACF, see

What exactly is the difference between ESAPIEncode and encodeForHTML()? (Something like this with a new column ESAPIEncode() would be great:
I found a bundled esapi.jar in the Lucee lib folder, ESAPI 2.0.1 from 2011-07-25. Is this library used in Lucee by ESAPIEncode?

Cool, I am fascinated – so which function (supported in ACF AND Lucee) should we use now?



There is no difference at all between ESAPIEncode( ‘HTML’, foo ) and
encodeForHTML( foo ). The former was an attempt to have a single
consolidated function instead of a number of small ones. This decision has
been reversed and in Lucee 5 the encodeForXXX() functions are not
deprecated but the ESAPIEncode() function is.

Use whichever one reads/types the easiest to you. I personally prefer




The Lucee docs seem to indicate that ESAPIEncode() is deprecated. Your comment is quite old, but it surfaced from a google search faster than the docs. Do the docs need to be updated or has Lucee changed its mind on the deprecation of encodeForHTML() again?


So far as I know, no other decisions have been made. Don’t read too much into the deprecations. It’s not like we’re going to remove any of the functions, it’s just a hint as to the one we recommend you use. Micha doesn’t like ot have two functions that do the same thing without having some sort of indicator of what the “recommended” one is. So read “deprecated” as “we recommend the other function that does the exact same one as this one but it’s not like this one will ever go away”.


Oh, a small historical note that I remembered after hitting send on my previous comment. The specific reason the “ESAPI” function was deprecated was because Micha originally thought “ESAPI” just meant something generic to security or something so he thought it was just a good, generic function name. When I pointed out (this was several years ago) that ESAPI was literally the name of the specific java library in use and if we ever swapped out that library, the name wouldn’t make sense is when he agreed to deprecate that one in favor of the more generically named functions. I think it went something like this:

  1. Adobe came out with the individual encodeForXXX() functions
  2. Lucee copied them and then Micha tried to ‘improve’ on them by creating a single encoding function to rule them all called ESAPIEncode( 'XXX' )
  3. Micha liked his approach so he deprecated the individual function names in favor of his singular one
  4. I convinced him using the word “ESAPI” was vendor lock in (in name anyway) and it got made more generic into just encodeFor( 'XXX' ) at which point the ESAPI version was deprecated.
  5. After I had to deal with a stubborn client who REFUSED to use the individual functions because they were marked as “deprecated” and they also refused to listen and understand what Lucee actually meant by that I spoke with MIcha, and quoting Uncle Bob’s “Clean Code” book, convinced Micha that specific functions with fewer params was actually better than a single generic function with more params. He agreed and reversed the deprecated notice in the docs.
  6. In the ensuing years to follow many developers have been confused at the wreckage of similar and paritially deprecated functions in Lucee. :slight_smile: