要说搞懂![CDATA[ ]]你几乎不需要背任何复杂的理论但要是没搞懂它你在XML解析上的翻车现场能绕地球一圈。我做数据对接这些年光是因为特殊字符没转义导致的解析失败就遇到过不下十次后面把CDATA这个机制吃透了才算是把这类问题从根上解决掉。这篇文章不打算按教科书方式讲我就结合自己的实战经历把CDATA的来龙去脉、使用边界、解析坑位一次说清楚。不管是写XML接口、改RSS、做爬虫解析还是编辑nfo刮削文件只要你的工作流里有XML这篇内容都用得上。1. CDATA到底解决了什么问题从一次“非法字符”报错谈起1.1 我在解析第三方XML接口时遇到的诡异报错有一年我负责对接一个第三方数据服务对方返回的是XML格式的报文。正常情况解析都没问题但某天突然开始抛org.xml.sax.SAXParseException: XML document structures must start and end within the same entity这类错误有时还会提示Character reference is an invalid XML character。我当时第一反应是对方返回了损坏的XML可是浏览器里打开完全正常下载下来看也不觉得哪里有问题。后来逐行排查才发现问题出在某个description字段里写了一句话价格优惠30% 满100减20 活动结束。先不说这句话的语义单看里面的和符号在XML规范里就是两只老虎。XML的语法规定只有和用于标记标签用于启动实体引用如果你在文本内容里裸放一个或解析器会以为你在写标签或实体自然就炸了。更麻烦的是这种报错位置往往和真正出错的字符不在同一个地方因为解析器是流式的可能到几行之后才报告错误。我第一次遇到时把整个XML翻了三遍心态差点崩掉。1.2 CDATA的标准定义与实质![CDATA[ ]]全称是Character Data意思是“字符数据”。它的作用是告诉解析器这块内容不需要做XML特殊字符解析你原样把里面的字符串给我就行。标准写法长这样content![CDATA[价格优惠30% 满100减20 活动结束]]/content注意CDATA标记本身不是节点它更像一个“包装壳”。解析后拿到的content节点值就是价格优惠30% 满100减20 活动结束这个值里不会包含CDATA这几个字母。换句人话讲CDATA是给内容套了一层“免转义保护膜”。从规范角度看XML文档里有两种文本可以出现在元素内容里一种是直接写的普通文本需要严格转义另一种就是包在CDATA区段里的文本不需要转义。正因为CDATA区段里允许出现任意字符包括、、、、这些在XML里有特殊意义的符号所以它是存放原始文本和代码片段的理想选择。1.3 为什么不能全靠实体转义转义规则的死穴既然有了lt;、gt;、amp;这些预定义实体为什么还要搞一个CDATA出来答案很直接当你要存放的文本里包含大量特殊字符时手工转义会变成一场灾难。举个例子如果你要在XML里存一段SQLSELECT * FROM users WHERE age 30 AND name 用实体转义就得写成sqlSELECT * FROM users WHERE age lt; 30 AND name lt;gt; /sql这还算能忍如果存的是整段JavaScript代码、整篇Markdown、或者一个包含几十个尖括号的数学公式呢转义之后的文本完全没法阅读而且转义过程中一旦漏掉一个符号解析器照样给你颜色看。我在实际开发里维护过一批模板配置文件里面嵌了非常复杂的正则表达式。正则里的[、]、\、*、.在XML普通文本里都不需要转义但要命的是正则里的和以及必须转。有一次同事在正则里顺手写了个整个配置文件加载失败排查了好久。后来我们统一约定凡是包含特殊字符的“原文型内容”一律用CDATA包裹。从那以后这类问题基本绝迹。2. CDATA的语法规则与使用场景拆解2.1 标准语法与边界条件![CDATA[ ]]的语法非常死板几个关键点不能弄错起始标记是![CDATA[注意前面是![不是[[。括号是英文方括号不能写成中文全角。结束标记是]]三个字符之间不能有空格。CDATA区段里最大的禁忌是不能再出现]]这个子串因为解析器看到]]就认为CDATA区段结束了。CDATA区段可以被放在元素内容中也可以出现在混搭内容里即文本和子元素交替出现但是CDATA区段不能出现在标签内部比如不能写在属性值里。最后一点非常重要。很多人会误以为node attr![CDATA[xxx]]/这样写可以免去属性值的转义这是完全错误的。CDATA只能用在元素的内容区域不能用在属性值里。属性值如果包含特殊字符老老实实用实体引用lt;、amp;、quot;等。我见过有人把整个文档包进CDATA企图“绕过XML解析”那更是南辕北辙。CDATA再厉害也只是XML文档内部的一块文本区域不是用来包裹整个文档的。2.2 CDATA可以包裹哪些内容包括二进制吗CDATA里可以放任何合法的XML字符序列除了]]包括换行、制表符、中文、Unicode字符、以及XML预定义特殊字符。但是有一个容易被误导的点CDATA不等于“可放二进制”。XML本身是纯文本格式所以CDATA里放不了真正的二进制字节。如果你用CDATA直接包一张图片的原始字节解析出来的字符串是乱码的。正确做法是把二进制内容进行Base64编码转成ASCII字符后再放进CDATA。一个我经常使用的场景在配置文件里嵌入SSL证书的PEM内容PEM本身就是Base64文本天然适合用CDATA保护不需要额外转义。2.3 典型应用场景从RSS到nfo再到刷机配置CDATA在实际工程里最常见的几个落点RSS/Feed内容RSS 2.0的description标签经常用CDATA来包HTML片段。因为博客摘要里会有p、a、img这些HTML标签如果不用CDATAHTML标签会被当成XML的子元素解析结构直接错乱。脚本代码与SQL像上面提到的配置管理、ETL任务、消息队列报文里需要在XML中嵌入一段需要“原样执行”的脚本字符串。nfo文件与影视元数据玩过“多媒体刮削”的朋友都知道很多影视元数据用nfo格式保存内部就是XML。一些媒体服务器允许在元数据里写评论或剧情描述遇到包含、、的原文内容时nfo里就应该用CDATA包裹否则刮削解析会失败。刷机配置文件等设备场景很多设备刷机或恢复配置时使用的是XML描述文件配置项里会包含路径、脚本、密钥或自定义参数。如果这些内容涉特殊字符同样需要用CDATA标记保护。这里重点提一下[CDATA[与实体转义的取舍问题。简单建议如果内容以人为阅读的“正文”为主且只有一两个特殊符号直接用实体转义更轻量可读性也好如果内容本身是程序代码、富文本、SQL、正则表达式这类机器生成或批量导入的“原材料”不要犹豫用CDATA。3. 实操环节CDATA在解析与生成XML中的正确姿势3.1 手写XML时如何安全包裹内容手写XML的场景多见于写配置文件、写RSS、写nfo。我来模拟一个真实的nfo文件例子?xml version1.0 encodingUTF-8? movie title某电影/title plot![CDATA[这是剧情简介。 剧情里包含特殊符号满200减30 折扣 5折 活动。 中文标点也完全没问题。]]/plot /movie这里plot里的文本包含和、没有CDATA的话就必须写成amp;、lt;、gt;。一旦写错很多刮削器直接忽略这一段甚至整个文件读取失败。手写的时候有几点经验CDATA起始标记和结束标记尽量单独占一行或者紧贴内容首尾但中间不要有多余空格。解析后的文本会包含CDATA标记内部的全部字符包括换行和缩进。如果你不希望在文本值里出现首尾空格就写成![CDATA[内容]]这种紧凑型。写完以后用XML校验工具跑一遍很多编辑器如VS Code能提示XML格式错误但CDATA内部的]]异常有时候不提示需要自己注意。如果是写RSS注意RSS规范要求description里若是HTML文本建议包CDATA且HTML标签不能丢。包完CDATA后消费者端读取时拿到的是HTML源码字符串再由前端渲染。3.2 用Python解析包含CDATA的XMLlxml与BeautifulSoup的坑位在Python里解析带CDATA的XML主要有两个坑一个是解析器会默认把CDATA当成纯文本合并另一个是BeautifulSoup可能会丢CDATA标记。先看lxml的标准表现。用lxml.etree解析from lxml import etree xml_str root content![CDATA[价格优惠30% 满100减20 活动结束]]/content /root root etree.fromstring(xml_str.encode(utf-8)) content root.findtext(content) print(content) # 输出: 价格优惠30% 满100减20 活动结束默认情况下lxml会把CDATA里的内容当作普通文本节点findtext拿到的就是原始字符串和不会转义这通常是我们想要的结果。但有一个坑如果你重新序列化这个XMLlxml默认会转义特殊字符不再保留CDATA包裹。print(etree.tostring(root, encodingunicode)) # 输出: # root # content价格优惠30% amp; 满100减20 lt; 活动结束gt;/content # /root有些场景下你需要保留CDATA标记比如下游系统有偏好这时在创建解析器时要把strip_cdataFalse打开parser etree.XMLParser(strip_cdataFalse) root etree.fromstring(xml_str.encode(utf-8), parserparser) print(etree.tostring(root, encodingunicode)) # 输出: # root # content![CDATA[价格优惠30% 满100减20 活动结束]]/content # /root这里strip_cdata的意思是“是否剥离CDATA标记”。默认是True也就是把CDATA的内容取出来去掉标记设为False后解析树里保留了CDATA标记序列化时也能原样写回。再来看BeautifulSoup。如果直接用它解析XMLCDATA标记通常会被当作字符串内容保留但再输出时不一定能还原CDATA标记。比如from bs4 import BeautifulSoup xml rootcontent![CDATA[price 100 discount]]/content/root soup BeautifulSoup(xml, xml) content soup.content.string print(content) # 输出: price 100 discount 这个没问题 print(soup.prettify())在xml解析器下大多数情况内容能正确读出来但prettify之后CDATA标记往往会丢失。如果你要“读取出原始内容”这没问题如果你要“原样保留CDATA并重新写入文件”建议把BeautifulSoup当读取器再用lxml重新构建文档或者干脆全程用lxml处理。我做爬虫时的一个习惯是凡是解析XML响应优先用lxml.etree只有解析HTML且需要容错处理时才用BeautifulSoup。因为XML的格式要求比HTML严格得多lxml给的错误信息也更具体。另外要提醒一个隐蔽坑用requests拿到的XML响应里有CDATA时response.text会保留![CDATA[ ... ]]你直接用response.content传给etree.fromstring没问题但如果你先把response.text做了一次字符串替换比如替换为amp;这就会把CDATA内部的内容也改掉直接导致解析结果和你预期不一致。所以记住一条铁律在把字符串交给XML解析器之前不要手工去转义CDATA内部的内容解析器会正确处理。3.3 用Java/PHP生成CDATA的常见做法服务端开发中最常见的需求是“把对象序列化成XML报文”并且指定某些字段用CDATA包裹。以Java为例如果直接用字符串拼接String content 价格优惠30% 满100减20 活动结束; String xml description![CDATA[ content ]]/description;简单粗暴但前提是content里不能包含]]。如果内容不可控需要做一个安全函数把]]替换成]]]]![CDATA[。这是什么操作等于在遇到非法子串时先关掉一个CDATA区段再用普通文本膨胀一点紧接着开启一个新的CDATA区段。在Java里我通常这样处理public static String cdataSafe(String value) { if (value null) return ; return ![CDATA[ value.replaceAll(]], ]]]]![CDATA[) ]]; }这样生成的CDATA区段在XML解析后拿到的原始文本依然是包含]]的完整内容。如果用的是JAXB或DOM生成XMLCDATA处理会稍微麻烦一点。DOM里可以用CDATASection节点Document doc DocumentBuilderFactory.newInstance().newDocumentBuilder().newDocument(); Element root doc.createElement(root); CDATASection cdata doc.createCDATASection(price 100 discount); root.appendChild(cdata); doc.appendChild(root);序列化时要注意Transformer输出默认可能不会保留CDATA实际上JDK默认输出能保留CDATASection。但如果内容里含]]createCDATASection会抛异常或序列化出错所以还是要先做安全替换。PHP里生成CDATA更简单直接拼字符串$content 价格优惠30% 满100减20 活动结束; $xml description![CDATA[{$content}]]/description;但注意解析时SimpleXMLElement读取CDATA节点后再asXML()输出时CDATA标记可能被转义成普通文本。如果需要保留CDATA可以配合LIBXML_NOCDATA选项读取或者使用DOMDocument。用PHP解析带CDATA的XML有个经典问题simplexml_load_string读取CDATA内容是自动剥掉标记的这没问题但如果你用json_encode把SimpleXMLElement转成JSONCDATA内容可能会丢失需要先转成数组$xml simplexml_load_string($str, SimpleXMLElement, LIBXML_NOCDATA); $array json_decode(json_encode($xml), true);LIBXML_NOCDATA的作用是把CDATA节点合并为普通文本节点这样json_encode才拿得到内容。这个坑我踩过最后翻libxml文档才找到原因。3.4 CDATA在XPath查询下的实际表现很多XML的查询操作比如用XPath抽取节点值遇到CDATA该注意什么直接用XPath的string()或text()就能拿到CDATA里的内容这个没有障碍。因为CDATA在解析后的DOM树里就是一个文本节点。但有个容易忽略的点如果CDATA区段和普通文本在同一个元素里混着出现比如description欢迎来到![CDATA[特价区]]amp; 活动/description解析后description里其实有三个文本节点欢迎来到、特价区来自CDATA、 活动实体转义后的普通文本。如果你用description/text()获取到的是多个文本节点用string(description)则会把它们拼接成一个字符串。实际用XPath取值时建议用string()或者normalize-space()来得到完整拼接后的值。在XPath里没法直接判断一个文本节点是不是来自CDATA因为XPath模型不区分CDATA与普通文本。这也是很多程序员一开始困惑的地方为什么解析器读取CDATA后标记就消失了因为内存中的XML树模型里只有文本内容标记只是源码层的语法糖。如果你需要保留源文件中的CDATA标记必须依靠解析器参数如lxml的strip_cdataFalse或序列化策略。4. CDATA常见问题与避坑清单4.1 内容里包含“]]”怎么办唯一的硬性冲突CDATA区段唯一不能直接包含的字符序列是]]。如果你要放进CDATA的文本里确实出现了这三个字符最稳妥的方式是分段把]]拆成]]加前者可以放在一个CDATA区段里把放在该CDATA区段之外因为单独的在普通文本里是合法的。我举一个实际案例有次在XML配置中需要嵌入一段模板代码if (x 0) return ]]直接把]]放进去解析就报错。处理办法是code![CDATA[if (x 0) return ]]]]![CDATA[]]/code看着有点绕实际拆解一下第一个![CDATA[if (x 0) return ]]包含的是if (x 0) return ]紧接着一个普通文本再一个![CDATA[]]包含的是。最终拼接结果就是if (x 0) return ]。这样既不破坏CDATA语法也能保证内容完整。有库提供了封装方法比如Java的createCDATASection会检查非法序列如果你用字符串拼接一定要自己写安全替换函数。4.2 CDATA与转义并存时如何处理解析器先处理哪一步CDATA区段内的所有字符对解析器而言都是“字面量”所以里面不能再使用实体引用。例如content![CDATA[lt;scriptgt;]]/content这表示的内容是字面量lt;scriptgt;而不是script。如果你本想把script原样输出却写成lt;scriptgt;结果就是字符串里多了个lt;。反过来在CDATA外部你写lt;scriptgt;才会被解析成script。很多新手在这里栽跟头。我自己的经验法则是用了CDATA就别再做实体转义做了实体转义就不需要用CDATA。两套机制不要叠加否则语义容易混乱。4.3 CDATA在解析后还是不是“CDATA”取决于解析器设置上面提到过lxml默认strip_cdataTrue会把CDATA标记剥掉序列化时不再保留。如果你是从外部读入XML并在后续写回可能需要保留原始形态这时必须设置strip_cdataFalse。以lxml为例完整的读写闭环建议这样写from lxml import etree parser etree.XMLParser(strip_cdataFalse) tree etree.parse(input.xml, parserparser) root tree.getroot() # 修改内容 # ... # 写回时使用相同的解析器得到的结果 tree.write(output.xml, encodingUTF-8, xml_declarationTrue)注意即使解析时保留了CDATA标记如果你对包含CDATA的节点做了修改比如把原来的文本替换为新字符串lxml会把该节点升级为普通文本节点CDATA标记可能丢失。所以保留CDATA这件事适合“读原文直接序列化”的场景如果要大规模修改内容更建议修改后再统一生成一次CDATA包裹。4.4 Word转XML、刷机配置和nfo编辑里的CDATA应用热词里有人搜“word转xml数学编辑器没有正确安装”这类问题通常出现在MathType或OMML公式导出场景。Word转XML的本质是把文档内容映射到WordprocessingML命名空间而公式里的特殊符号、嵌套结构非常复杂极容易出现CDATA包裹或实体转义问题。如果你在转换后手动编辑XML看到类似m:oMathm:rm:t![CDATA[x^2 y^2 1]]/m:t/m:r/m:oMath这就是典型的用CDATA保护数学公式内容的写法。公式里的如果没有被CDATA包裹在XML解析时会被当成标签起始符整个文档结构崩掉。数学编辑器报错很多时候就是因为你“拆了CDATA”或者“多加了转义”。数字公式这种生成型内容保存为CDATA是最省心的。刷机配置里的XML经常有类似partitionspartition labelmodemfilenamemodem.bin/filenamesize0x123456/size/partition/partitions这样的结构虽然CDATA不常用在这里但一旦配置项里嵌入了ADB脚本、命令行参数等比如fastboot flash boot boot.img这里的就必须转义或包CDATA。命令行内容包CDATA尤其合适因为命令行里充满了、|、这些符号。nfo编辑就更有意思了。很多下载的电影nfo文件里剧情描述或演职员名单中会出现类似br /这样的HTML换行或者字符。正确的做法是plot![CDATA[导演: 某某 br / 主演: 某某 某某]]/plot如果不加CDATA刮削器解析时会把br /当作XML节点而不是换行文本轻则显示异常重则整个nfo无法解析。另外很多播放器或媒体库对nfo中的CDATA支持良好建议善用。4.5 从“小于号在xml中是lgt?”说起一个高频误解的根源热词里有个“小于号在xml中是lgt?”这显然是混淆了的实体映射。XML里小于号的正确实体是lt;对应“lgt”可能是“less than”的缩写误写。出现这种问题本质是对XML特殊字符的转义方式不够熟悉。用lt;、gt;、amp;、quot;、apos;这五种预定义实体能覆盖绝大多数简单场景。但正因为很多内容作者记不住这些实体才会反复出现“小于号怎么转义”的搜索。这恰恰说明了CDATA的价值当你不想记也不想人工转义时直接包上CDATA把“转义”这个脏活交给解析器去处理。XML设计者当初加入CDATA目的就是让那些含有大量特殊字符的文本块能够“原样”流动起来。5. 写在最后的个人经验说实话CDATA本身不难难的是在真实项目里判断什么时候用、怎么用不翻车。我自己的处理逻辑是三层第一层能提前避免特殊字符就提前避免比如用JSON存数据或改用参数化接口没必要为了一个字符串专门造XML第二层如果必须用XML承载原文比如RSS、nfo、报文那就优先用CDATA第三层如果CDATA里可能包含]]必须写一个安全处理函数不能偷懒直接拼接。关于解析库我现在的固定搭配是Python读取用lxml.etree生成XML用lxml.builder或手动拼CDATA安全片段Java服务里用DOMcreateCDATASection并且在写入前对任何不可信内容执行]]替换。只要这些基础动作到位CDATA就不会成为线上事故的源头。最后送一个我亲手验证过的小技巧不是所有XML解析器都尊重CDATA标记遇到解析后内容被截断或者符号丢失的情况先检查是不是拿了个不支持CDATA的迷你解析器。大多数情况下换成lxml或系统自带的标准DOM库问题就消失了。希望这篇文章能让大家对![CDATA[ ]]有个清晰、可落地的认识少走一些我当年走过的弯路。