38

I came up with a hack to escape HTML using jQuery and I'm wondering if anyone sees a problem with it.

$('<i></i>').text(TEXT_TO_ESCAPE).html();

The <i> tag is just a dummy as jQuery needs a container to set the text of.

Is there perhaps an easier way to do this? Note that I need the text stored in a variable, not for display (otherwise I could just call elem.text(TEXT_TO_ESCAPE);).

Thanks!

Michael Mior
  • 28,107
  • 9
  • 89
  • 113

3 Answers3

62

That's a pretty standard way of doing it, my version used a <div> though:

return $('<div/>').text(t).html();

This isn't technically 100% safe though as Mike Samuel notes but it is probably pretty safe in practice.

The current Prototype.js does this:

function escapeHTML() {
    return this.replace(/&/g,'&amp;').replace(/</g,'&lt;').replace(/>/g,'&gt;');
}

But it used to use the "put text in a div and extract the HTML" trick.

There's also _.escape in Underscore, that does it like this:

// List of HTML entities for escaping.
var htmlEscapes = {
  '&': '&amp;',
  '<': '&lt;',
  '>': '&gt;',
  '"': '&quot;',
  "'": '&#x27;',
  '/': '&#x2F;'
};

// Regex containing the keys listed immediately above.
var htmlEscaper = /[&<>"'\/]/g;

// Escape a string for HTML interpolation.
_.escape = function(string) {
  return ('' + string).replace(htmlEscaper, function(match) {
    return htmlEscapes[match];
  });
};

That's pretty much the same approach as Prototype's. Most of the JavaScript I do lately has Underscore available so I tend to use _.escape these days.

mu is too short
  • 426,620
  • 70
  • 833
  • 800
  • 3
    A lot of libraries do this. Just be aware that the result here is safe to embed in a PCDATA context and an RCDATA context, but not an attribute context since quotes are not escaped. If you might be susceptible to UTF-7 attacks and the like you should also escape '+': http://en.wikipedia.org/wiki/UTF-7#Security – Mike Samuel May 16 '11 at 20:24
  • 6
    @Mike: I don't think the `.text(t).html()` or Prototype's `replace` approaches are really that great, both approaches have problems. The lack of a `encodeHTML()` function in the standard JavaScript library is a gaping hole and a rather surprising oversight. – mu is too short May 16 '11 at 20:33
  • @muis: I don't think so: the core JavaScript language is not specifically aimed at web browsers. – Marcel Korpel May 17 '11 at 20:33
  • 4
    @Marcel: But we do have `encodeURIComponent` and JavaScript's roots are in web browsers. And, the fact that everyone ends up writing their own indicates that there is a gap in the standard libraries. – mu is too short May 17 '11 at 21:57
  • @muis Thanks for the pointer to Prototype. It turns out that my proposed method doesn't work as I expect in some browsers (read: IE) – Michael Mior May 18 '11 at 05:16
  • @Michael: Which IE version screws it up? I haven't noticed any problems but that doesn't mean there aren't any. – mu is too short May 18 '11 at 05:29
  • IE8. It actually mostly works. Perhaps this is expected behaviour, but newlines were stripped from the string which was returned. – Michael Mior May 18 '11 at 15:32
  • @Michael: You can't really depend on whitespace being preserved unless you're using `
    ` blocks but, as usual, whatever works.
     – mu is too short May 18 '11 at 17:06
  • Fortunately when working with a string, it's safe to just do the replacing. I was thrown at first because FF and Chrome seem to preserve whitespace just fine. – Michael Mior May 18 '11 at 17:31
  • For those interested in the relative performance of the different approaches, you can see the results at: http://jsperf.com/encode-html-entities In essence, the regular expression approach appears to be the general winner, closely followed by the multiple replace() approach. However, the regular expression approach probably scales better than replace() if you escaping more than the basic three: &,<,> – StephenD Mar 27 '13 at 18:45
11

There is no guarantee that html() will be completely escaped so the result might not be safe after concatenation.

html() is based on innerHTML, and a browser could, without violating lots of expectations, implement innerHTML so that $("<i></i>").text("1 <").html() is "1 <", and that $("<i></i>").text("b>").html() is "b>".

Then if you concatenate those two individually safe results, you get "1 <b>" which will obviously not be the HTML version of the concatenation of the two plaintext pieces.

So, this method is not safe by deduction from first principles, and there's no widely followed spec of innerHTML (though HTML5 does address it).

The best way to check if it does what you want is to test corner cases like this.

Mike Samuel
  • 118,113
  • 30
  • 216
  • 245
  • Actually, I want `$("").text("1 <").html()` to be `"1 <"` and `$("").text("b>").html()` to be `"b>"`. (which works) – Michael Mior May 16 '11 at 17:07
  • 1
    @Michael, if you've tested it on major browsers, and it works, great. As of 15 June, 2009, a current version of Safari actually **unescaped** > so `` was returned via `innerHTML` as ``. That may have been fixed in modern browsers though. My point is that testing is the way to gain confidence. – Mike Samuel May 16 '11 at 17:55
1

That should work. That's basically how the Prototype.js library does it, or at least how it used to do it. I generally do it with three calls to ".replace()" but that's mostly just a habit.

Pointy
  • 405,095
  • 59
  • 585
  • 614