PHP XML 数据怎么处理？面对旧系统接口时应该掌握哪些方法
图片说明：示意图 图片来源：Public Domain（公有领域）
在新项目里，JSON几乎已经成为Web接口的默认选择，但一旦接手银行、ERP、财务、物流、医疗、政府系统或者运行多年的企业内部平台，XML往往还在接口链路中占据重要位置。很多PHP开发者第一次碰到这类系统时，容易把XML处理理解成“把标签读出来，再把数据写回去”。真正麻烦的地方通常不在于读取一个节点，而在于命名空间、编码、DTD、CDATA、属性、节点顺序、Schema验证以及旧系统那些没有写进文档的格式约定。
因此，处理遗留XML接口时，重点并不是记住几个PHP函数，而是建立一套可靠的数据处理流程：先确认原始XML到底是什么，再决定解析方式；读取之后进行结构和业务验证；生成XML时严格按照对方接口要求构造；最后把异常、编码、安全和日志处理完整。
SimpleXML适合简单读取，复杂接口不要硬套
PHP中最方便的XML工具之一是SimpleXML。对于结构稳定、层级不深、命名空间较少的XML，它非常好用。
例如服务器收到下面这样的XML：
OK
10086
199.99
可以直接：
$xml = simplexml_load_string($xmlString);
if ($xml === false) {
throw new RuntimeException('XML解析失败');
}
$status = (string)$xml->status;
$orderId = (string)$xml->order->id;
$amount = (float)$xml->order->amount;
SimpleXML的优势就是代码非常短，而且读取节点非常直观。
但这种便利性也容易让开发者产生错觉，以为所有XML都可以这样处理。遇到复杂命名空间、混合内容、CDATA、属性操作、节点插入删除、复杂XPath或者需要精确控制输出结构的场景时，SimpleXML很快就会开始显得受限。
尤其是命名空间。XML中的命名空间不是“标签名称比较复杂”这么简单，而是节点的完整名称由namespace URI和local name共同决定。例如：
10086
这时直接写：
$xml->Body
通常得不到预期结果，因为Body属于SOAP命名空间。
SimpleXML需要通过children()或者xpath()处理命名空间，例如：
$namespaces = $xml->getNamespaces(true);
$soap = $xml->children($namespaces['soap']);
$body = $soap->Body;
$m = $body->children($namespaces['m']);
$orderId = (string)$m->GetOrder->OrderId;
这里还有一个容易混淆的概念：XML里的前缀soap、m本身并不是决定节点身份的关键，真正决定节点身份的是namespace URI。因此不能假设对方下一次把m改成order，你的程序就一定失效；只要URI保持一致，程序仍然可以按照命名空间处理。
DOMDocument适合需要精确控制的接口
当项目不仅需要读取XML，还需要修改、删除、增加节点，或者必须按照对方接口规范精确生成XML时，DOMDocument通常更加合适。
例如：
$doc = new DOMDocument('1.0', 'UTF-8');
$doc->formatOutput = true;
$order = $doc->createElement('order');
$id = $doc->createElement('id');
$id->appendChild($doc->createTextNode('10086'));
$order->appendChild($id);
$doc->appendChild($order);
echo $doc->saveXML();
如果需要处理命名空间，则应该使用createElementNS()、getElementsByTagNameNS()等DOM API。
需要特别纠正一个常见说法：DOMDocument并不存在所谓的registerNodeNameSpace()标准方法。命名空间注册与XPath查询有关时，可以使用DOMXPath::registerNamespace()；如果直接操作DOM节点，则应使用带Namespace URI的相关API。
例如：
$xpath = new DOMXPath($doc);
$xpath->registerNamespace(
'm',
'http://example.com/order'
);
$nodes = $xpath->query('//m:OrderId');
foreach ($nodes as $node) {
echo $node->nodeValue;
}
这在处理SOAP、行业标准XML以及企业系统接口时非常常见。
XPath往往比一层层遍历节点更可靠
面对旧系统XML，节点层级可能非常深。例如一个订单可能位于：
Envelope
└── Body
└── Response
└── Result
└── Orders
└── Order
└── Customer
└── CustomerId
如果全部依靠：
$xml->Body->Response->Result->Orders->Order->Customer->CustomerId
代码很快就会变得难以维护。
DOMDocument配合DOMXPath可以把查询逻辑集中起来：
$xpath = new DOMXPath($doc);
$nodes = $xpath->query('//Customer/CustomerId');
foreach ($nodes as $node) {
$customerId = trim($node->textContent);
}
如果存在命名空间，则先注册：
$xpath->registerNamespace(
'm',
'http://example.com/order'
);
$nodes = $xpath->query('//m:CustomerId');
对于经常变化的遗留系统接口，XPath还能让代码与具体节点层级适当解耦。不过XPath也不能无限制地使用，核心字段最好仍然经过明确的结构和业务验证。
XML编码问题不能靠“统一转UTF-8”解决
旧系统最容易让PHP开发者头疼的另一个问题是编码。
现代系统通常使用UTF-8，但老系统可能仍然输出GBK、GB2312、Windows-1252、ISO-8859-1甚至一些设备厂商自己的字符集。
最危险的处理方式就是：
$xmlString = mb_convert_encoding(
$xmlString,
'UTF-8'
);
然后假定问题解决。
mb_convert_encoding()必须知道源编码。XML本身可能通过XML声明告诉你编码：
如果程序已经把原始数据转换成UTF-8，却没有同步处理XML声明，就可能形成“内容是UTF-8，声明却说是GB2312”的矛盾。
因此更稳妥的做法是先确认接口实际发送的字节编码、HTTP响应头、XML声明以及服务器接收到的原始数据，再决定是否转换。
例如确认源编码后：
$xmlString = mb_convert_encoding(
$xmlString,
'UTF-8',
'GB18030'
);
如果是你自己生成XML，则从源头统一使用UTF-8通常更加可靠：
$doc = new DOMDocument('1.0', 'UTF-8');
不要把编码问题简单理解成“中文乱码问题”。XML编码错误可能导致解析失败、字段截断、签名验证失败，甚至让同一份数据在不同系统中得到不同结果。
htmlspecialchars不是XML万能消毒剂
原文中还有一个容易被混淆的地方。
生成XML时，如果直接进行字符串拼接：
$xml = '' . $name . ' ';
而$name里面恰好包含：
A&B
最终可能生成非法XML：
A&B
这时确实需要正确进行XML转义。
但如果使用DOMDocument：
$node = $doc->createElement('name');
$node->appendChild($doc->createTextNode($name));
DOM会负责正确处理文本节点中的特殊字符，因此不应该再对同一数据进行重复转义。
htmlspecialchars()主要是HTML上下文中的转义函数。XML也有转义规则，但在使用DOM、SimpleXML等XML API时，应该让XML库负责节点编码，而不是到处手工拼接和转义。
这也是为什么专业项目中应该尽量避免：
$xml = '' . $name . ' (.*?)<\/OrderId>/', $xml, $matches);
作为正常XML处理方案。
XML存在嵌套、命名空间、CDATA、实体、属性、混合内容等结构。正则表达式无法可靠承担完整XML语法分析任务。
更合理的做法是先确认数据究竟是不是XML。如果它是合法XML，就交给XML解析器；如果接口实际上返回的是某种自定义文本协议，就应该按照该协议编写解析器。
只有在处理已经明确脱离XML结构的文本内容时，正则表达式才适合作为辅助工具。
“XML解析器负责结构，正则表达式负责文本”比“DOM加正则一起解析XML”更加清晰。
生成XML时不要靠字符串拼接
与解析XML一样，生成XML最常见的低级错误也是字符串拼接。
例如：
$xml = '
' . $id . '
' . $name . '
';
当变量中出现&、<、>、引号或者其他特殊字符时，就容易出现格式错误。
使用DOMDocument：
$doc = new DOMDocument('1.0', 'UTF-8');
$order = $doc->createElement('order');
$idNode = $doc->createElement('id');
$idNode->appendChild(
$doc->createTextNode((string)$id)
);
$nameNode = $doc->createElement('name');
$nameNode->appendChild(
$doc->createTextNode($name)
);
$order->appendChild($idNode);
$order->appendChild($nameNode);
$doc->appendChild($order);
$xml = $doc->saveXML();
如果接口要求属性：
$order->setAttribute('version', '1.0');
如果要求命名空间，则应该通过Namespace API构造节点，而不是手工拼接xmlns字符串。
对于一些老系统来说，节点顺序甚至也是协议的一部分。虽然从XML标准角度看，很多场景下元素名称比顺序更重要，但具体接口可能按照固定顺序进行Schema验证或者由老程序硬编码读取。因此生成XML时必须以对方接口文档和实际样例为准。
XML安全比解析成功更重要
处理来自外部系统的XML时，不能只关注“能不能解析”，还必须关注XML实体和外部资源问题。
历史上的XML External Entity，也就是XXE问题，可以让攻击者构造恶意XML，通过外部实体机制诱导服务器访问本地文件或者远程资源。在现代PHP/libxml环境中，相关默认行为和安全机制已经发生过多次变化，因此不能简单套用十年前的固定代码。
尤其不要把：
libxml_disable_entity_loader()
当成所有PHP版本、所有场景下的万能安全开关。
更可靠的思路是：使用当前PHP/libxml环境支持的安全解析方式，避免不必要的DTD和外部实体处理；对不可信XML进行严格限制；在需要Schema验证时使用受控的Schema；同时限制输入文件大小、请求体大小、解析时间和资源消耗。
安全问题也不只是XXE。一个攻击者完全可以发送超大的XML、极深的嵌套结构或者异常复杂的数据，让服务器消耗大量CPU和内存。因此接口层还应该考虑请求大小限制、超时、内存限制、反向代理限制以及异常日志。
XML验证应该分成三层
一个稳定的XML接口通常不能只做一次“XML解析成功”检查。
第一层是语法验证。也就是确认它是不是合法XML：
$xml = simplexml_load_string($xmlString);
if ($xml === false) {
throw new RuntimeException('XML格式错误');
}
第二层是结构验证。如果接口提供XSD，就应该根据XSD验证元素、属性、数据类型、必填字段以及结构。
第三层是业务验证。
例如XML完全合法：
-500
XML解析器不会认为它有问题，但如果业务规定订单金额必须大于0，那么它仍然应该被拒绝。
因此，“XML解析成功”绝不等于“接口数据可信”。
老系统接口最难的往往不是XML
实际维护遗留系统时，最让开发者头疼的通常不是PHP XML API，而是接口协议中那些没有写在文档里的规则。
例如有些系统要求：
Content-Type: text/xml
而另一些系统要求：
Content-Type: application/xml
SOAP接口还可能要求特定的SOAPAction、Envelope结构和命名空间。
有些系统要求XML声明必须位于第一行，有些系统对节点顺序异常敏感，还有系统会把空节点：
喜欢这篇报道？
使用下面的功能，方便以后继续阅读和分享 MNewsTV
关于文章收藏
收藏不需要注册帐号，收藏信息仅保存在当前浏览器中。
删除收藏请进入「我的收藏」进行管理。
捐助（Paypal）: https://www.paypal.me/observeccp 订阅中国观察电报 Telegram : https://t.me/s/ObserveCCP