" is often used in feeds to escape XML special characters. However, it can cause issues in some edge cases.">

" in RSS"><br>" is often used in feeds to escape XML special characters. However, it can cause issues in some edge cases.">

" in RSS"><br>" is often used in feeds to escape XML special characters. However, it can cause issues in some edge cases.">

Avoid using "" in RSS | WaspDev Blog

is very commonly used in RSS (also Atom) feeds to escape XML special<br>characters. At first glance, it looks very convenient,<br>you simply add blocks and write any (almost) content inside of them without<br>worrying<br>about escaping characters:

item><br>title> in Titles]]>title><br>link>http://example.comlink><br>description><br>This description contains HTML markup.<br>It allows us to use characters like "&" and brackets directly.<br>]]><br>description><br>item>

Why not CDATA?

CDATA seems to be perfect, isn't it? Except it's not possible to escape some CDATA special character sequences<br>inside a<br>single CDATA block, particularly ]]> (the one that ends the CDATA block). In order to do that,<br>you have to split the CDATA block<br>into multiple parts:

text><br>world]]><br>text>

The encoded text is "hello ]]> world". As you can see, the XML code is less readable now. CDATA<br>loses most of its simplicity advantage.

Even though splitting makes the encoding of ]]> possible, I would say it's still not worth using<br>CDATA:

It adds a special edge case for ]]>, which the serializer must handle.

It can mislead people into thinking the content is raw HTML or somehow safer. No, it is not.

It makes output less uniform, because sometimes you need split CDATA blocks.

It does not change the parsed value. XML parsers expose the same text either way.

It can make debugging confusing, especially if the content itself discusses CDATA, like this article title<br>does... Just look at the<br>RSS feed of this blog.

What to do instead?

Just escape these characters (works for HTML too):

function xmlEscape(text) {<br>return text<br>.replaceAll("&", "&amp;")<br>.replaceAll(", "&lt;")<br>.replaceAll(">", "&gt;")<br>.replaceAll('"', "&quot;")<br>.replaceAll("'", "&#39;");

Normal escaping is simpler and more uniform.

OK, but some people might say that CDATA might make the RSS content smaller on average since<br>characters don't need any escape (which requires more characters in encoded form) and ]]> is<br>encountered rarely. Fair point, however:

Feeds are usually gzip-compressed . Repeated strings like &lt;,<br>&gt;, and<br>&amp; compress very well.

RSS feed size is rarely the bottleneck . Images, HTML pages, CSS, JS, and network latency<br>usually matter much more.

CDATA has a special edge case . You still need to correctly handle ]]>.

Normal escaping is simpler and more uniform . One escaping path works for titles,<br>descriptions, Atom, RSS, attributes, metadata, etc.

Conclusion

Here I listed the reasons why you should avoid using CDATA. This is especially true if you are going to<br>implement your custom RSS / Atom feed generator.<br>Many libraries / frameworks / CMSs still generate CDATA for RSS / Atom feeds and many of them handle the<br>mentioned character sequence<br>]]> in their own ways. And they are perfectly fine to use if you have to rely on them. CDATA is<br>common because it<br>is convenient for legacy feed generators and visually cleaner for embedded HTML. But for new code, ordinary XML<br>escaping is usually cleaner and more uniform.

See you later.

Load Disqus comments

Disqus uses cookies, please check Privacy & cookies before loading the comments.

Please enable JavaScript to view the<br>comments powered by Disqus.

⬆UP

This site uses cookies for some services. By clicking Accept , you agree to their use.<br>To find out more, including how to control cookies, see here: Privacy & cookies.

Accept

Reject