这是我参与8月更文挑战的第11天，活动详情查看：8月更文挑战

小白最近学习编程学烦了，看到学委之前写了一篇节约3小时之间试水Unity的，直接过来找我要了！（要么是懒得下安装包，不然是太依赖学委了，都不好！）

刚好我手上有一个Unity安装包, 就发给他了。

不知道啥原因，他说传输后打不开？

怎么可能呢？

接着，再传了一次还是打不开。

这让学委一下子想到了：得cksum一下

1） 先cksum工具本地算一次，得到校验码
2）然后在接受的系统中又计算一次，得到文件校验码
3）当两个数字校验相等，文件被认为是被正确传输了

使用就像下面一样：

cksum 文件名

第一个数字：2283207869 //为校验码
第二个数字： 844948304 // 为文件字节数

然后我让小白在本机跑一边cksum，发结果给我，一看他那边的校验数字居然是 33303330333 ，这个数字，稍微思考一下就很离谱！

很明显Unity包传输出错了。

这次我直接拷贝U盘给他了，并且进入U盘对应目录进行cksum了，万无一失！

好了，小白可以先走了。亲爱的读者我们继续学习一下cksum吧，很多使用的。

cksum官方补充

Linux cksum命令用于检查文件的CRC是否正确。确保文件从一个系统传输到另一个系统的过程中不被损坏。

CRC是一种排错检查方式，该演算法的标准由CCITT所指定，至少可检测到99.998%的已知错误。指定文件交由cksum演算，它会回报计算结果，供用户核对文件是否正确无误。
www.man7.org/linux/man-p…

这个算法不继续介绍，本文谈谈应用。

更多应用 - sha512cksum

sha512cksum 比cksum（32位 cksum）更加可靠，因为是512位哈希cksum。

比如我们常见的maven（Java项目管理工具）：

下图的表格第二列为下载链接，第三列为每一个包的sha512cksum的签名。

上面页面的链接可以点击【maven下载页面】

我们可以通过点击上面的链接下载，比如这个：maven tar gz包

通过这个链接下载然后跑shasum在本地校验一次。

shasum -a 512 apache-maven-3.8.1-bin.tar.gz
#得到这个签名：0ec48eb515d93f8515d4abe465570dfded6fa13a3ceb9aab8031428442d9912ec20f066b2afbf56964ffe1ceb56f80321b50db73cf77a0e2445ad0211fb8e38d

这个值跟第三列链接的文件【点这里下载sha512】内容必须一致.

操作复杂，学委准备了下面的脚本。

#!/bin/sh
#雷学委的demo代码
#仅支持macbook
url=https://mirror-hk.koddos.net/apache/maven/maven-3/3.8.1/binaries/apache-maven-3.8.1-bin.tar.gz
#url_sha512=${url}.sha512
url_sha512=https://downloads.apache.org/maven/maven-3/3.8.1/binaries/apache-maven-3.8.1-bin.tar.gz.sha512
curl ${url_sha512} -o maven.tar.gz.sha512
curl ${url} -o maven.tar.gz
shasum -a 512  maven.tar.gz

读者可以运行这个脚本试试，最好的验证效果如下图：

雷学委的开发经验分享

下面举例一些常用场景。

多文件迁移校验

通常是用在大量的打包数据迁移，生成每个文件的数字签名。

部署制品的校验

做Java的同学知道一个叫做Nexus的依赖仓库，不止可以放jar，还能放tgz包，我们通常会生成tgz包的同时，进行sha512把签名结果存到文件一并传到nexus上面。

当我们拿tgz文件部署的时候，同时下载tgz和sha512，本地校验，保证了部署安装的包跟实际交付的一致。