{ "content_summary": "本文论述了为何在 RSS/Atom 中应尽量避免使用 CDATA。作者指出虽然 <![CDATA[ ... ]]> 看似方便，可以直接包含 HTML 与特殊字符，但它对终止序列 ]]> 存在特殊的边缘情形，必须通过拆分 CDATA 块（例如 ]]]]><![CDATA[>）来解决，导致序列化输出变得不一致且难以阅读。CDATA 并不会改变解析后得到的文本值，反而可能误导开发者以为内容更“原生”或更安全。作者建议采用统一的 XML 转义（例如将 & < > \" ' 替换为实体）来保持输出简单、可预测，并指出 gzip 等压缩能有效缩小重复转义字符串的体积，RSS 大小通常也不是瓶颈。", "community_viewpoints": "有人认为对任意文本做硬编码字符串替换并不是稳妥做法，推荐使用真正的 XML DOM 库来处理 CDATA 与转义（例如浏览器的 DOMParser）；有评论指出如果自己实现序列化，可以用简单的替换将 \"]]>\\" 变为 \"]]]]><![CDATA[>\", 以避免多重 replaceAll 的复杂性；也有人提出实践中经常需要用 CDATA 才能让第三方导入工具正常工作（例如某些 WP 插件），兼容性比效率更重要；有观点支持 CDATA 的可读性和多行 HTML 便利性，认为那一点边缘情况不足以否定其价值；还有人观察到现实中很多源（如 HN RSS）在不同字段采用不同的转义策略，引发了是否应统一策略的讨论；此外部分评论批评文章写法冗长并对基于字符串的 XML 操作表现出不屑，强调应当用成熟库而非手工替换。", "introduction": "理解本文的关键在于区分“表达便利性”与“序列化一致性”两者的取舍。作者的核心观点是：虽然 CDATA 在书写含 HTML 的描述或多行文本时看起来更直观，但它带来一个不可忽视的边缘问题——不能直接包含终止序列\"]]>\"，必须拆分 CDATA 块，导致输出不一致、调试复杂且容易误导。更稳妥的做法是统一采用标准的 XML 转义（替换 & < > \" ' 为实体），这条路径更简单、易于维护、在压缩传输下体积影响甚微，并且可以用于标题、描述、属性等所有字段。实务建议：优先使用成熟的 XML 库进行序列化/解析；如果确实选择 CDATA，务必在序列化阶段正确处理\"]]>\"的情况并在消费端测试兼容性；若追求可读性且能保证所有下游工具支持，可在内部保留 CDATA，但要有严格的测试和文档说明。" }