问题标签 [error-detection]

从 4B/5B 编码方案 dataward 0000 编码为 11110 码字，类似地 0001 编码为 01001 等。

这里两个码字之间的异或运算的结果将是另一个有效的码字。

例如 11110 和 01001 的 XOR 是另一个码字 10111，其数据字是 1011。这里我没有问题。

同样，为了避免直流分量，使用了 NRZ-I 线路编码方案。结果，输出码字中没有三个连续的零。码字中不再有一个标题和两个尾零。我们不用担心 NRZ-I 编码方案中的个数。

但是，我如何将 0000 编码到 11110 或 0001 到 01001 以及我应该为这种编码方案应用哪种算法。

我也搜索谷歌和学习书籍。但是他们到处都在说同样的事情，但我没有得到答案。

提前致谢

我见过 8 位或 12 位的汉明码检测和校正示例。假设我有位串：1101 0110 11它包含 10 位。

我是否需要在该位串中添加两个额外的位来完成半字节？如果是我要添加0s or 1s吗？

我已经寻找了其他示例，但似乎无法找到那些带有部分半字节的示例来确定程序。谢谢你。

我正在使用以下代码来查找边缘图像与参考边缘图像的均方误差。

但是我得到的结果就像附加图像一样，但是我没有得到最终的单个值，而是得到一个错误，

诸如MurmurHash3和 xxHash 之类的非加密哈希几乎是专门为哈希表设计的，但它们的功能似乎与CRC-32、Adler-32和Fletcher-32相当（甚至更好） 。非加密散列通常比 CRC-32 更快，并产生更多“随机”输出，类似于慢速加密散列（MD5、SHA）。尽管如此，我只看到推荐用于数据完整性/校验和目的的 CRC-32 或 MD5。

在下表中，我测试了 32 位校验和/CRC/哈希函数，以确定它们检测数据细微差异的能力：

每个单元格中的结果意味着：A) 发现的冲突数，以及 B) 32 个输出位中的任何一个设置为 1 的最小和最大概率。要通过测试 B，最大值和最小值应尽可能接近 50 . 任何低于 45 或高于 55 的值都表示有偏见。

查看表格，MurmurHash3 和Jenkins lookup2与 CRC-32 相比（实际上未通过一项测试）。它们也分布均匀。DJB2 和 FNV1a 通过了碰撞测试，但分布不均。Fletcher32 和 Adler32 难以应对 NullBytes 和 8RandBytes 测试。

那么我的问题是，与其他校验和相比，“非加密哈希”对于检测文件中的错误或差异有多合适？CRC-32/Adler-32/CRC-64 是否有任何理由可能优于任何体面的 32 位/64 位哈希？

考虑两台计算机A和B. 有不同程度的A用途G和B用途。计算机想要发送数据，并为此使用 CRC。G'G' != GAD

该声明说，不可能出现A发送与数据相对应的 CRC 消息D并且计算机B将其作为有效消息接受的情况。这是为什么？

我们知道计算机A发送D*2^r XOR R（r是度数G）和计算机B除以G'。所以换句话说，为什么不能G'意外地分裂D*2^r XOR R？

显然这与事实有关，deg(G) != deg(G')但我没有弄清楚。

谢谢！

据说CRC（循环冗余校验和）可以检测少于r + 1位的突发错误，其中r是多项式的次数。此外，以1 – 2 ^-r的概率检测到长度大于r + 1位的突发。

有人可以指导我进行相同的证明吗？

在 CRC（循环冗余校验）中，通常两个节点就一个 r+1 位生成器达成一致。这个 r 通常为 32，并在设备（路由器）中配置。如果两台路由器配置了不同的 r 位生成器（例如，一台路由器配置了 16 位生成器，另一台配置了 32 位生成器），会发生什么情况？他们如何就使用哪些生成器达成一致？

我一直在尝试使用 sort 函数对数字数组进行排序，但我忘了写括号。

代替

我的问题是为什么 python 不能检测到这个错误并像 Java 一样通知我？该程序一直编译良好，但因为我是按升序输入数字，所以问题不会出现。

假设我有一个任意的字节块。该块以使用 CRC-16-CCITT 算法在整个块上计算的 CRC 余数终止，其中余数以大端字节序排列。在块和余数之后，有任意数量的零字节一直持续到字节流结束。

这种安排利用了这种 CRC 算法的某些特性，这通常被认为是不受欢迎的：它不区分具有不同数量尾随零的消息，前提是消息以其剩余部分终止（在我的情况下）。这允许接收器断言数据的正确性，而不管流中的尾随字节数如何。

这是一个例子：

在我的情况下，这是所需的行为。但是，在我的应用程序中，数据通过使用不归零 (NRZ) 编码的介质进行交换：介质层在相同级别的每五个连续数据位之后注入一个填充位，其中极性为填充位与前面的位相反；例如 的值00000000被传输为000001000。位填充是非常不可取的，因为它会增加开销。

为了利用 CRC 算法对尾随数据（用于填充）的不变性并避免位填充，我打算将每个数据字节与 0x55 异或（尽管它可以是任何其他避免填充的位模式) 在更新 CRC 余数之前，然后将最终余数与 0x5555 异或。

作为参考，这里是标准的 CRC-16-CCITT 算法，简单的实现：

这是我的修改，它使用 0x55 对输入和输出进行异或运算：

一个简单的检查确认修改后的算法按预期运行：

我的问题如下：我是否通过引入这种修改来损害算法的错误检测特性？还有其他我应该注意的缺点吗？

假设一个多字节数据块被某个 CRC 处理了两次，一次是不变的，一次是一个错误的字节。能否仅根据这两个代码定位故障字节？请注意，这并不意味着错误的确切性质必须仅识别其位置，字节错误也不限于可由任何 CRC 纠正的单个位翻转。