SQL导出XML时字段值被转义是符合标准的行为，需根据下游需求决定是否跳过；PostgreSQL用xmlforest()+xmlelement()避免二次转义，MySQL需REPLACE按序还原；SQL Server应改用FOR XML PATH或RAW扁平化结构；Python解析时须强制指定encoding防乱码；XML转JSON应预埋type属性或直接用FOR JSON避免类型丢失。
SQL 查询结果导出为 XML 时字段值被转义怎么办
MySQL 和 PostgreSQL 默认用 XMLSERIALIZE 或 CONCAT 拼接 XML 时，会把 &、、<code>> 自动转成 &、、<code>>，导致下游解析失败。这不是 bug，是 XML 标准行为，但清洗阶段常被误认为“数据损坏”。
实际做法取决于你是否真需要合法 XML：如果只是中间格式且下游是自研解析器，可跳过转义；否则必须保留。PostgreSQL 推荐用 xmlforest() + xmlelement() 组合，它默认不二次转义已合法的文本节点；MySQL 则得手动用 REPLACE(REPLACE(REPLACE(...)) 回填，但要注意顺序——先处理 & 再处理 和 <code>>，否则会套叠。
- PostgreSQL 示例：
SELECT xmlelement(name row, xmlforest(id, name, REPLACE(content, '&', '&') AS content)) FROM posts; - MySQL 临时绕过法：
SELECT CONCAT('<row><id>', id, '</id><content>', content, '</content></row>') FROM posts;（仅限 content 确认无非法字符） - 别在应用层再对数据库输出的 XML 做一次
html_entity_decode，那会把本该保留的
SQL Server 的 FOR XML AUTO 生成嵌套结构太深怎么压平
FOR XML AUTO 会按 JOIN 顺序自动建层级，比如 SELECT u.name, o.amount FROM users u JOIN orders o ON u.id = o.user_id FOR XML AUTO 会产出 <u name="..."><o amount="..."></o></u>，但多数 API 只要扁平数组。硬改 SQL 逻辑成本高，不如在 XML 生成后切片处理。
关键不是禁用 AUTO，而是换用 FOR XML RAW 或 FOR XML PATH('')。前者每行一个同名节点，后者允许手写标签名并拼接字段，天然扁平。注意 PATH('') 中空字符串不生成外层包裹，适合做 CSV 式拼接；若需根节点，最后用 SELECT '<root>' + (子查询) + '</root>' 包一层即可。
- 扁平化示例：
SELECT id AS '@id', name AS 'text()', '' AS 'data()' FROM users FOR XML PATH('user'), ROOT('users'); - 避免用
FOR XML EXPLICIT—— 它要求显式定义 tag/id/parent，字段一多就难维护 - SQL Server 2016+ 支持
STRING_AGG，可先聚合再包 XML，比嵌套 FOR XML 更可控
用 Python etree 处理 SQL 导出的 XML 时中文乱码或解析失败
根本原因常是编码声明和实际字节不一致。SQL Server 导出 XML 默认带 <?xml version="1.0" encoding="UTF-16"?>，但文件保存或管道传输时可能被当 UTF-8 读取；PostgreSQL 的 xml_out 函数输出的是 UTF-8 字节，却可能没写 encoding 声明，etree 就按系统默认编码猜，一猜就错。
最稳做法：不依赖 XML 声明，强制指定编码。用 etree.fromstring() 时传 parser=etree.XMLParser(encoding='utf-8')；如果是文件，用 etree.parse(filename, parser)。若数据来自网络响应，先用 response.content（bytes）而非 response.text（str），避免 requests 自动解码污染原始字节。
- 安全读取示例：
parser = etree.XMLParser(encoding='utf-8'); root = etree.fromstring(xml_bytes, parser) - 别用
open(filename).read()直接喂给 etree —— 缺少 encoding 参数时 Python 3 默认用 locale 编码，Windows 上就是 gbk - 清洗前先检查前 100 字节：
print(repr(xml_bytes[:100]))，看是否有b'\xff\xfe'（UTF-16 LE BOM）
XML 转 JSON 后数组丢失、字段类型错乱怎么对齐
XML 本身没有数组/对象/布尔/数字类型概念，所有内容都是字符串。工具如 xmltodict 把单个 <item>123</item> 当 str，两个同名节点才转 list，但 SQL 导出常因数据量少只生成一个节点，导致下游 JSON Schema 校验失败。
解决思路不是改转换库，而是在 XML 层面预埋结构提示。PostgreSQL 可用 array_to_json(ARRAY(SELECT ...)) 先转 JSON 再包进 XML；SQL Server 用 FOR JSON PATH 替代 FOR XML；实在不行，在 XML 中用属性标记类型，例如 <price type="number">99.9</price>，然后写个轻量解析器识别 @type 并 cast。
- PostgreSQL 预转 JSON 示例：
SELECT xmlelement(name data, xmlforest(to_jsonb(ARRAY(SELECT json_build_object('id', id, 'name', name) FROM users)) AS items)) - 别依赖
xmltodict.parse(xml_str, force_list=('item',))这种全局配置 —— 它会让所有<item></item>强制变 list，连<count>1</count>也变[1] - SQL Server 2016+ 直接用
SELECT * FROM users FOR JSON AUTO，比 XML+JSON 两步更可靠
真正麻烦的是混合类型字段，比如一个 <value></value> 有时存 "true"，有时存 "123"，有时存 "2023-01-01"。这种没法靠格式自动判断，得在 SQL 层用 CASE WHEN 显式分类，或者接受它在 JSON 里全是字符串——清洗逻辑本就该在业务层，不在序列化环节。
