QuickFixj报错：消息无字段分隔符，Kafka+JSON传递解析问题排查

核心问题本质 #

QuickFixj 依赖 ASCII SOH（十六进制 0x01，显示为
） 作为Fix消息的字段分隔符。你遇到的解析报错，大概率是JSON解析/字符串转换过程中，SOH字符被篡改、丢失或转义错误，导致QuickFixj无法识别合法的分隔符。

分步排查点 #

1. 先确认QuickFixj的分隔符配置

你提到硬编码空格分隔的消息能正常解析，先检查QuickFixj会话或数据字典配置：

• 查看是否误将 FieldSeparator 参数设置为空格（ASCII 0x20）。如果是，带SOH的消息自然会被判定为“无字段分隔符”。
• 默认配置下QuickFixj的分隔符是SOH（0x01），若没修改过该配置，再往下排查。

2. 验证JSON解析后字符串的实际字节内容

打印显示正常不代表字节正确（终端会把0x01显示为
或空格），直接检查字节数组：

• 用代码输出解析后字符串的字节：

  byte[] msgBytes = parsedString.getBytes(StandardCharsets.UTF_8);
  System.out.println(Arrays.toString(msgBytes));
  

• 对比硬编码可解析字符串的字节数组：
  • 正常Fix消息的分隔符位置应该是 1（对应0x01）；
  • 如果解析后分隔符位置是 32（对应空格0x20），说明JSON转换时把SOH替换成了空格；
  • 如果是 92, 117, 48, 48, 48, 49（对应\u0001的UTF-8字节），说明JSON转义序列没被还原成实际的SOH字符。

3. 排查JSON序列化/反序列化的SOH处理逻辑

不同JSON库（Jackson/Gson等）对不可打印字符的处理策略不同：

• 如果生产者是把带SOH的Fix消息直接序列化成JSON：
  • 很多JSON库会自动把SOH转义为\u0001，此时消费者需要确保反序列化时把\u0001还原成实际的0x01字节（比如Jackson需要开启ALLOW_UNQUOTED_CONTROL_CHARS配置）；
• 如果生产者手动把SOH替换成了空格再存JSON：
  • 那解析后自然是空格分隔，只有修改生产者逻辑，保留原始SOH并正确转义，才能让QuickFixj识别。

4. 确认Kafka消息的编码传递流程

你的流程是「Kafka传递→JSON解析→UTF-8转字符串」，检查是否多此一举：

• 如果Kafka中直接存储的是Fix消息的二进制内容（带SOH），不需要经过JSON解析，直接把Kafka消息字节转成UTF-8字符串即可；
• 如果Kafka存的是JSON格式的字符串，必须确保生产者在序列化时正确处理SOH（比如转义为\u0001），消费者反序列化时再还原为0x01。

内容的提问来源于stack exchange，提问作者user2868864