@nickg I did not want to clutter your other thread, but this is important to understand: Encoding concepts: • when transmitting character data, the transmission needs to say what charset the data is in so the receiver knows how to interpret it. This is charset encoding, and with HTTP or MIME messages, this is done with a header. • when a user agent (browser, email client) renders a document that has been received via the mechanism in the previous step, one can provide additional meta information that re-states this, eg like in a

<meta http-equiv='Content-Type' content='text/html; charset=UTF-8'>

. Note the

http-equiv

... it is the document-level equivalent of the HTTP header mentioned in the previous phase. I think on the whole these days this is a nice to have, and the header in the transmission is enough? Don't quote me on that. • when being rendered as part of an HTML document (for example), user-originated data must be security- / intended-usage- encoded before it's rendered, so protect from XSS, and to just make sure it's rendered correctly. A benign example would be that if we were using an HTML client now, and if I wanted actual

<meta http-equiv='Content-Type' content='text/html; charset=UTF-8'>

to appear on the screen for you to read, instead of having the browser goes "oh that's info for me", I need to encode it (escape it, basically). So in your CFML view file, never this:

<cfoutput>#someVariable#</cfoutput>

But always:

<cfoutput>#encodeForHtml(someVariable)#</cfoutput>

unless you are actively outputing markup that should be treated as mark-up. This however is generally a pretty rare thing to be wanting to do. (note: there are other encoding functions to use for different situations in the HTML document, eg:

encodeForHtmlAttribute

and

encodeForJs

etc. Use the correct one).

@Adam Cameron many, many thanks. This stuff has always been hazy for me, although the developer working on this is more seasoned.