OFX/QFX非标准XML，需用OfxSharp等专用库解析；DTPOSTED为记账日应优先使用；LEDGERBAL是账本余额需重点关注；中文乱码常因实际编码为GBK而非文件声明的UTF-8。
OFX/QFX不是标准XML，别用XmlDocument直接加载
OFX和QFX文件看着像XML，但实际是SGML变种：允许无闭合标签、不强制引号、支持注释嵌套。用XmlDocument.Load()或XDocument.Load()会直接抛XmlException，报错类似“无法解析的标记”或“意外的字符”。这不是你文件坏了，是解析器太严格。
实操建议：
- 用
StreamReader配合正则或状态机提取关键块（比如<stmttrn></stmttrn>到），再对每段做轻量清洗（补全引号、转义&为&）后交给XElement.Parse() - 更稳妥的做法是用现成库——
OfxSharp（NuGet可搜），它专为OFX 1.02/2.0+设计，能跳过声明头、容忍空格错位、正确识别OFXHEADER:100分隔区 - 注意QFX是OFX的“银行导出特供版”，字段名基本一致，但可能多出
<currency></currency>或<secid></secid>，OfxSharp默认兼容，不用额外开关
交易日期DTPOSTED和DTUSER含义不同，别混用
OFX里一笔交易至少带两个时间戳：DTPOSTED是银行记账日（资金实际变动日），DTUSER是用户操作日（比如手机App提交转账的时间）。理财软件常只显示DTPOSTED，但个人记账时如果按DTUSER归类，会导致月底对不上银行流水。
实操建议：
- 优先取
DTPOSTED，格式固定为YYYYMMDDHHMMSS[+/-]ZZZZ（如20240520143022[-0400]），用DateTimeOffset.ParseExact()解析，别用DateTime.Parse() - 若
DTPOSTED为空（极少数老系统导出），再降级用DTUSER，但要在日志里打标：“fallback to DTUSER for<trnuid></trnuid>” - 注意有些QFX文件把日期写成
DTSTART/DTEND（用于对账单区间），和单笔交易无关，别误抓
余额字段LEDGERBAL和AVAILBAL容易读反
LEDGERBAL是账本余额（已清算资金），AVAILBAL是可用余额（含未清算支票、冻结金额）。个人用户最关心LEDGERBAL，但很多解析示例代码默认取AVAILBAL，导致余额比银行APP少几千——其实是被临时冻结了。
实操建议：
- 检查OFX结构：余额总在
<bankmsgsrsv1><stmttrnrs><stmtrs></stmtrs></stmttrnrs></bankmsgsrsv1>下，LEDGERBAL和AVAILBAL是同级节点，别从父节点BAL里硬找 - 用
OfxSharp时，直接访问response.Statement.LedgerBalance，它内部已做类型转换，返回decimal；AvailableBalance字段同理 - 如果文件没提供
LEDGERBAL（部分信用卡QFX省略），只能用最后一笔交易的TRNAMT累加初始余额推算，此时必须校验DTASOF（余额截止日）是否覆盖你要的周期
中文字符在QFX里常乱码，别信文件声明的CHARSET:UTF-8
很多国内银行导出的QFX文件头写着CHARSET:UTF-8，但实际用GBK编码写入，用Encoding.UTF8读就会出现“张三”或空字段。这不是解析逻辑问题，是编码层就错了。
实操建议：
- 先用
File.ReadAllBytes()读原始字节，检查BOM：UTF-8有BOM是EF BB BF，GBK没有；如果没BOM且中文异常，大概率是GBK - 用
Encoding.GetEncoding("GBK")解码（.NET Core 6+需装System.Text.Encoding.CodePages包并调用Encoding.RegisterProvider(CodePagesEncodingProvider.Instance)） - 别依赖
OFXHEADER后的CHARSET字段——它只是银行系统填的备注，和真实编码无关
真正麻烦的是混合编码：个别字段用UTF-8（如银行名），其余用GBK（如户名、摘要）。这时得按字段白名单切分处理，没有银弹。
