关于控制下载完整性的“总开关”以及出现校验值与“提供源”不符的原因

    下载——是计算机用户使用频率较高的日常操作之一,又是“无师自通”最为简单的计算机操作之一。但是,就是这个习以为常、司空见惯的“下载”,却深藏着“数据转换”“信号通讯”“传输控制”等一系列晦涩艰深的理论。本文力求用最简洁、最通俗的文字说清楚:控制下载完整性的“总开关”以及出现校验值与“提供源”不符的原因?

    为了确保数据传输和存储的正确性、准确性,必须具有“检错”“纠错”的控制机制和检测手段。目前运用最为普遍、性能最为可靠的就是“CRC”(由于“CRC”算法的晦涩艰深,对“演算公式”恕不详加叙述)。CRC是Cyclical Redundancy Checkde的缩写,中译:循环冗余校验。据权威统计数据,CRC不能发现错误的概率仅为0.0047%。

    “CRC”是控制下载完整性、准确性的“总开关”:进行下载的“第一动作”,是要计算出下载对象的CRC值,并随数据一同发送给“接收方”;在此后的下载过程中,会不断对下载数据进行计算并与收到的CRC值进行比对,直至“丝毫不差、完全吻合”时即完成下载。以上过程,都是下载软件通过CRC这只“无形的手”忠实履行“把关职能”。

    出现下载校验值与“提供源”校验值不符的原因非常复杂。“提供源”校验值(比如:MD5、SHA1)“胡编乱造”比较少见(除了有损信誉之外,似乎没有这个必要),那么问题一般还是出在下载软件或下载设置上:1)下载软件计算下载对象的CRC值不准确;2)不幸遭遇了概率极低的“0.0047%”;3)极个别下载对象只认“从原始地址下载”。

     ——假如下载后的校验值与提供源的校验值“不合拍”,还有一种与“下载”毫无关系的可能:使用的校验工具“不称职”。

Write a comment

Comments: 0