EDIFACT转XML需严格按语法指南解析段落层级、复合数据元结构、重复段边界及字符集声明，避免仅依赖段序或硬切分导致嵌套错误、语义丢失和乱码。
EDIFACT段落顺序错位导致XML节点嵌套错误
EDIFACT不依赖标签名而依赖段落（segment）位置和重复次数来表达结构，XML却靠显式嵌套。当映射工具机械按段序生成XML时，UNB→UNH→BGM→DTM看似线性，但实际DTM可能属于BGM，也可能属于其后的LOC或NAD——这取决于DTM前最近的“上下文段”是否为复合数据元起始段。
- 必须解析
UNH中声明的Message Type（如INVOIC）和Version（如D96A），查对应语法指南（Syntax Rules）确认每个DTM的层级归属 - 不能仅靠段名匹配，要跟踪
Segment Group层级：例如INVOIC中DTM在SG2（Line Item Group）内时，应嵌入 - 常见错误现象：
DTM+137（Invoice Date）被错误放在
复合数据元（Composite Data Element）拆分不完整
EDIFACT用+分隔复合数据元（如NAD+BY+123456789::92），其中BY是3035（Party Function Code），123456789是3039（Party Identifier），92是3055（Code List Responder ID）。XML映射若只取第一个字段或忽略分隔符位置，会丢失关键语义。
- 必须按
EDIFACT Directory（如D96A第14版）查每个复合数据元的字段定义顺序和可选性；NAD的C082（Party Name）含最多4个子字段，但第3、4字段常为空，不能跳过占位 - 避免用
split('+')硬切：某些值本身含+（如公司名ACME+CO），需依赖UNA段定义的Component Separator（默认+）并结合Data Element Separator（默认+）做状态机解析 - 示例错误：
NAD+SU+ABC123::91+ACME+CO+++GB中，ACME+CO是C08201（Name），不应被误拆为两个字段
SU ABC123 91 ACME+CO GB
重复段（Repeating Segments）与XML数组边界混淆
CTA（Contact Information）和COM（Communication Contact）在EDIFACT中可重复多次，但映射到XML时容易把所有CTA塞进一个CTA和COM混成同一数组。
- EDIFACT语法规定：重复段必须连续出现，且受
Segment Group约束。例如INVOIC中CTA只能出现在SG4（Party Group）内，且每组最多1个CTA，但SG4本身可重复 - XML应体现层级归属：不是
... ... IC - 性能影响：未限制重复次数会导致XSLT或Java JAXB解析时内存暴涨，应在映射前用正则预扫
^CTA\+行数，并设硬上限（如maxOccurs="5"）
字符集与转义处理不一致
EDIFACT默认使用ASCII，但实际报文常含ISO-8859-1字符（如é、ñ）或UTF-8字节序列。XML声明后，若原始EDIFACT用UNA指定了?为小数点、:为日期分隔符，却未同步声明字符集，解析器会把多字节UTF-8当作乱码截断。
- 必须提取
UNB第5字段（CharacterSet），常见值：UNOC（UNO Code, ASCII）、UNOA（ISO 646）、UNOE（ISO 8859-1）、UNOB（UTF-8）；若无此字段，默认为UNOC - XML输出时，对非ASCII字符必须做
XXXX;实体编码（如é→é），不能依赖XML库自动转义——某些老版本xerces会把UTF-8字节直接写入，导致XML无效 - 容易被忽略的点：
UNB本身可能含非ASCII字符（如发送方名称），这部分必须在解析UNB阶段就完成解码，否则后续段落偏移计算全错
DTM的父级段组、每个C082子字段是否存在、以及UNB里那个没被文档强调的字符集代码到底生效了没有。 
