一些 XModem CRC 传输的额外神秘字节

Question

出于我不会进入此处但有效的原因，我正在创建一个接收器的“XModem CRC 1K”实现，用于来自 Windows XP 超级终端的传输。

许多文件似乎传输得很好...我得到了 3 字节标头（SOH/STX、序列、Sequence1C）、数据（1024 或 128，取决于总文件大小）和 CRC16 的 2 字节。序列有效，CRC 有效，一切都很好。

然而，由于某些奇怪的原因，超级终端会为某些特定文件发送可重复的格式错误的数据包。对于相同的文件，它总是以相同的方式出现格式错误...我见过的一些格式错误包括：

1. 超出每个数据包预期 1029 个额外的（非控制）字节。最终，它确实再次找到了控制字节，并且可以重新对齐到 1029 数据包边界，并可能在下游添加更多杂散字节。
2. 在正常传输的最后一个数据包之后有一个额外的单字节。再次强调，这种畸形是可重现的，但无法解释。

这些传输是通过 Winsock TCP 超级终端连接进行的，因此我认为这是由于信号错误造成的，就像您在真正的调制解调器中看到的那样。对于给定文件来说，畸形也总是相同的。我多次查看了规范，但这些额外的字节没有在任何地方得到解释。如今，微软以不太遵守标准而闻名，所以我想知道情况是否如此？

非常感谢任何提示。

Answer 1

经过一些详尽的测试后发现了这一点。看起来超级终端正在用 0xFF,0xFF 替换数据包中出现的任何 0xFF。

我怀疑这是因为超级终端有其“自己的控制协议”，它使用 0xFF 字节来开始序列。因此，实际的 0xFF 字节需要转义。看起来没有任何方法可以在超级终端中禁用此行为，因此接收者只需处理替换（并在我的情况下承受效率损失）。