Can you nest "<![CDATA[ ... ]]>" blocks when generating RSS feeds?

Question

When generating RSS feeds, the RSS standard says that these translations have to be made for content to not be interpreted as XML, but rather as plaintext:

'&' => '&'
'<' => '&#x3C;'
'>' => '&#x3E;'

And that's precisely what I do. No problems.

However, it also supports a <![CDATA[ ... ]]> syntax, described here: https://en.wikipedia.org/wiki/CDATA

Using CDATA blocks is just like the first way, except it's horribly broken: it cannot contain ]]>` anywhere inside, because that ends the CDATA block!

This means that you have to make very confusing little "hacks" to be able to nest CDATA blocks, and since we are outputting a RSS document with a bunch of random content, it can obviously very well contain ]]> somewhere, so then you have to apply an escape routine for anything you put inside a "CDATA block".

So, with this in mind, why would anyone ever want to use CDATA blocks instead of escaping those three XML/RSS specials characters as the standard defines? I don't understand.

The only guess I have is that, if you have tons of content, then the number of bytes could grow sizeable if you have a bunch of < stuff everywhere, compared to just a CDATA start/end tag with plain characters inside...

So maybe I answered my own question right away, but is the only reason to "save some bytes of network traffic"? The part where you have to escape internal CDATA end tags puts me off from using CDATA blocks.

Answer 1

why would anyone ever want to use CDATA blocks [...] ?

That's a good question.

I think the key is here:

since we are outputting a RSS document with a bunch of random content, it can obviously very well contain ]]> somewhere

I don't use CDATA all that much (because I don't use XML all that much) but one place where I do use it is when I'm adding an inline stylesheet to an SVG file.

See:

<svg xmlns="http://www.w3.org/2000/svg"
     xmlns:xlink="http://www.w3.org/1999/xlink"
     viewBox="0 0 1200 1200">

<defs>
<style type="text/css"><![CDATA[

rect {
fill: rgb(255, 0, 0);
}

]]></style>
</defs>

the difference here, is: I know the limits of what will be going inside the CDATA.

I won't know in advance the exact contents of the CDATA but I do know that it will be valid CSS.

This means I can anticipate it might contain a > (direct descendant selector) which I need to escape or a < or a > in a @media query (both of which I need to escape) but I also know that it will never contain ]]> anywhere, because that substring has no place appearing in valid CSS.

So, I'm going to suggest that the advantage of CDATA is when you can be 100% certain that its contents will never contain ]]>.

If you can't be 100% certain of that, then you're right: the utility of CDATA is significantly diminished.