小白最近學習編程學煩了，看到學委之前寫了一篇節約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演算，它會回報計算結果，供用戶核對檔案是否正確無誤，
https://www.man7.org/linux/man-pages/man1/cksum.1.html
這個演算法不繼續介紹，本文談談應用，
更多應用 - 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，本地校驗，保證了部署安裝的包跟實際交付的一致，
轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/290251.html
標籤：java