Xz format inadequate for long-term archiving中有一节（2.5）：
根据Koopman（第50页），“七宗罪”之一（即 CRC和校验和使用的错误想法是无法保护消息 长度字段。这会导致由于帧错误导致的漏洞。注意 数据流中帧错误的影响更严重 比图1所示。不仅是随机位置的数据 解释为CRC。无论CRC伪造的数据如何 被解释为以下字段的开头，防止了 成功解码流中的任何剩余数据。
他谈到这个案子，当时的消息是这样的：
ID LEN DATA CRC
如果LEN被破坏，则将使用随机位置的CRC。但我没有看到，为什么这是一个问题。在该随机位置，几乎肯定会有无效的CRC值，因此检测到错误。
他谈到解码以下数据。我没有看到，如果LEN受到保护，那么如何能够解码以下数据。如果LEN损坏，我们在两种情况下都找不到下一条消息。
例如，PNG不保护长度字段。
那么，当LEN字段受CRC保护时，为什么它显然更好？
如果我要设计一个消息结构，这是最好的方法吗？我应该使用什么顺序，我应该用CRC保护什么？假设消息包含以下部分：
我目前的设计是：
这种方法有什么缺点吗？
答案 0 :(得分：1)
考夫曼实际上说的是什么（here）：
无法保护邮件长度字段 结果将数据指向FCS，得到HD = 1
HD是汉明距离，这意味着如果您将部分数据视为（虚假）检查值，而不是实际，则误报率的概率会在低误码率流上显着上升检查价值。要真正做到这一点，您应该在数据之前使用自己的检查值保护长度字段和其他标头值。
至于您的设计，首先放置CRC的缺点是必须先缓冲所有消息以计算CRC，然后才能在流中编写消息。你可以输入id，length，header crc，message，message crc。