Excel 打开 XML 并非真正编辑，而是解析后转为表格视图，保存时会丢失命名空间、注释、CDATA、xml:space 等关键信息，导致格式错误、类型丢失或重复根节点；安全修改应使用文本编辑器或专用工具，严格保持结构与编码。
Excel 打开 XML 文件只是“假装在编辑”
Excel 读取 XML 的方式是解析后转成表格视图，不是直接操作原始 XML 结构。你看到的单元格内容，和实际 XML 中的标签、属性、嵌套关系几乎无关。保存时 Excel 默认会丢弃所有原始格式、命名空间、注释、CDATA 段，甚至可能重排元素顺序——xml:space、xmlns、xsi:type 这类关键信息大概率消失。
常见错误现象：XML 格式错误（Excel 保存后无法被其他系统读取）、数据类型丢失（如 xs:date 变成纯文本）、重复根节点（Excel 自动加壳生成 Workbook 或 DataSet 包裹层）。
实操建议：
- 仅当 XML 是简单扁平结构（如无嵌套、无属性、单层同名元素）且目标系统能容忍 Excel 生成的变体时，才考虑用 Excel 快速改几行值
- 务必先备份原始 XML，再用 Excel “另存为” → 选择
XML Spreadsheet 2003 (*.xml)格式（这是 Excel 自己的方言，不是通用 XML） - 如果原文件带 XSD Schema 或用于 Web Service / Java/.NET 系统交互，绝对不要用 Excel 直接打开保存
直接修改 XML 文件必须用文本编辑器或专用工具
真正安全的修改方式，是把 XML 当作文本处理：保留缩进、不破坏标签配对、不误删空格或换行（尤其在 内）。Excel 不具备这些能力，而 VS Code、Notepad++、XMLSpy 或命令行工具（如 sed、xmlstar）可以。
使用场景举例：批量替换某个 <status></status> 值、给一批 <item></item> 元素统一加 version="2" 属性、修正 <date>2023-13-01</date> 这类格式错误。
实操建议：
- 打开前确认编码：XML 声明里写的是
<?xml version="1.0" encoding="UTF-8"?>，就用 UTF-8 打开；若声明是GBK，别用默认 ANSI 编辑器乱改，否则出现Invalid byte sequence - 修改属性值时注意引号匹配：不要把
id="123"改成id='123"，单双引号混用会直接导致解析失败 - 增删节点前，先验证当前 XML 是否合法：VS Code 装
Red Hat XML插件，或终端运行xmllint --noout file.xml，报错就别往下改
用 Python 或 PowerShell 批量改 XML 更可靠但要注意 DOM vs SAX
手改百来行还行，上千个文件就得脚本化。但不同解析方式影响巨大：xml.etree.ElementTree（Python）和 [xml]::Load()（PowerShell）都是 DOM 模型，会把整个 XML 加载进内存——大文件（>100MB）容易 OOM；而 xml.sax 或 iterparse 是流式处理，适合只改特定字段且内存受限的场景。
参数差异明显：ElementTree 默认不保留空白文本，etree.tostring(root, encoding='unicode', method='xml') 里的 method='xml' 不能省，否则输出可能缺声明头；PowerShell 的 $xml.Save() 默认用 UTF-8 without BOM，但某些老系统要求 BOM，得手动写入字节流。
实操建议：
- 优先用
xmlstar命令行工具做简单替换：xmlstar --inplace -u "//price" -v "99.99" data.xml，它不加载全文，速度快、零依赖 - Python 脚本中避免用
root.find("item").find("price").text = "99.99"这种硬编码路径，先用root.xpath("//item[price （配合 <code>lxml）更健壮 - 修改完务必校验：用
xmlschema库验证是否符合 XSD，或至少跑一遍xmllint --schema schema.xsd modified.xml
XML 中的特殊字符和实体引用最容易翻车
很多人改着改着发现 & 变成 &、 消失、中文变成乱码，其实都是没处理好字符转义。XML 规范强制要求：文本内容里的 <code>&、、<code>> 必须写成 &、<、>；而属性值里还要额外处理双引号 " → "。
常见错误现象：ParseError: not well-formed (invalid token)（通常卡在第 1 行第 123 列，就是某个未转义的 &）；或者 Excel 打开后某字段显示 <script> 而不是 <script></script>。
实操建议：
- 手工编辑时，宁可多转义：不确定要不要转，就按规则全转；但不要对 CDATA 块内内容转义——
]]>里面的内容原样保留 - 脚本中用
html.escape(text, quote=True)（Python）或[System.Security.SecurityElement]::Escape($str)（PowerShell）做转义，别自己拼字符串 - 如果 XML 本身声明了
encoding="GB2312"，而你用 UTF-8 编辑器打开并保存，即使没改内容，也会因编码不一致导致中文变???
真正麻烦的从来不是改哪一行，而是改完之后没人再检查它是否还能被下游系统正确加载——尤其是带命名空间的 XML，一个 xmlns:ns="http://example.com" 写错位置，整个文档就失效了。
