17370845950

FIXML是FIX协议的XML表达形式，非替代协议而是同一语义的结构化翻译，用于可读存档、监管报送与系统集成，需严格遵循官方XSD Schema并处理编码、命名空间等企业级要求。

FIXML 是 FIX 协议消息的 XML 表达形式，不是替代 FIX 的新协议，而是同一套语义在不同编码风格下的“翻译”——它用层级化、自描述的 XML 结构，把原本紧凑的 Tag=Value 消息（如 35=D 表示新订单）展开成可读、可存档、易验证的文档。

它解决的不是“能不能传”，而是“传完之后怎么被系统理解、审计、转给清算或监管系统”。换句话说：FIX 负责“快准狠地下单”，FIXML 负责“留下一份盖章签字、带目录和页码的交易档案”。

为什么不能直接用 FIX 文本做报送和存档？

因为原始 FIX 消息是面向实时通信优化的，不是为人类或后台系统设计的：

• 8=FIX.4.2^9=251^35=D^... 这种格式没有嵌套结构，字段顺序依赖上下文，55=IBM 和 48=459200101 谁属于哪个金融工具？靠人工查字典
• 不支持注释、命名空间、版本控制，无法表达复杂嵌套（比如一个订单含多个 legs 的期权组合）
• XML 解析器、XSD 验证、XSLT 转换、SQL Server 的 FOR XML 或 .query() 等企业级工具，

  

  对纯文本 FIX 无能为力
• 监管报送（如 MiFID II）明确要求结构化、可追溯、带签名的 XML 报文，不是 SOH 分隔的流式字节

如何生成合法的 FIXML 实例？关键三步

生成可用的 FIXML 不是手写 ... 就完事，必须匹配官方 Schema：

• 先确认所用 FIX 版本（如 FIX 4.4、FIX 5.0 SP2），再下载对应 FIXML.xsd —— 官网 fixprotocol.org 提供全部历史版本 Schema
• 所有字段名、嵌套路径、必选/可选属性都必须严格遵循 XSD；例如 下的 在 FIX 4.4 中是属性 SecurityIDSourceValue="1"，不是子元素
• 生成后务必用 XML 验证器校验：

  xmllint --schema FIXML44.xsd order.xml --noout

  或 SQL Server 中用 CAST(... AS XML) 强转时触发隐式验证

SQL Server 中处理 FIXML 的典型陷阱

很多团队想用 SQL 直接解析 FIXML 日志表，但常卡在编码和类型上：

• 从文件读 FIXML 时，若用 OPENROWSET(BULK 'msg.xml', SINGLE_CLOB)，默认按 Windows-1252 解码，而 FIXML 多为 UTF-8 —— 必须改用 SINGLE_BLOB + 显式 CAST：

  SELECT CAST(x AS XML) FROM OPENROWSET(BULK 'msg.xml', SINGLE_BLOB) AS T(x)

• xml 类型列存入后，用 .value() 提取字段时，XPath 必须带命名空间前缀（FIXML Schema 含 xmlns="http://www.fixprotocol.org/FIXML-4-4"），否则返回 NULL
• 不要试图用 REPLACE() 或字符串函数“修”坏掉的 FIXML —— XML 解析失败会直接报错，且无法定位是哪一行；应先用外部工具（如 Python 的 lxml）预检再入库

FIXML 的真正难点不在语法，而在“它不是独立协议，而是 FIX 生态的延伸”：你得同时懂 FIX 字段语义、XML Schema 约束规则、以及目标系统（如 CME Position Service 或监管接口）对命名空间、时间格式、枚举值大小写的硬性要求。漏掉任意一层，生成的 XML 就只是看起来像 FIXML，实际会被接收方静默丢弃。