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

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

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

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

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

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