觀點 · 資訊分享

Azure Blob SDK 支援 CRC64-NVME 端對端驗證：上傳下載的檔案有沒有走樣，一個位元組也不放過

Azure Blob Storage 在 6/30 宣布，用戶端資料完整性保護正式推出：.NET、C++、JavaScript 的最新 SDK 已整合 CRC64-NVME 檢查碼，可以驗證檔案從應用程式到 Azure 實體儲存，寫入與讀取都沒有被改動。

一句話看懂：Azure Blob Storage 的 .NET、C++、JavaScript SDK 現在內建 CRC64-NVME 檢查碼，可以驗證檔案從你的程式到 Azure 實體儲存，寫入與讀取都沒有走樣；這項用戶端資料完整性保護在 6 月 30 日正式推出。

Azure Blob 端對端資料完整性 GA資訊圖卡：SDK 帶上 CRC64-NVME 檢查碼，確認檔案從程式到儲存都沒走樣

先用白話講：資料完整性檢查是什麼？

想像你要寄一件貴重的瓷器：寄件前拍照、量尺寸，在箱子上貼一張獨一無二的封條；收件人收到後，核對封條與尺寸，就能確定途中沒有被掉包或摔壞。

電腦世界的「封條」就是檢查碼（checksum）：資料寫入前算出一組「指紋」，讀取後再算一次，兩組一樣，資料就是完好的；不一樣，就代表有地方出錯，需要重傳。

Azure 在 6 月 30 日宣布，Blob Storage 的用戶端資料完整性保護正式推出（GA）：

Blob Storage 一直支援資料完整性驗證：最早是隨 HTTP 標準提供的 MD5，後來在 2019 年加入 CRC64-NVME
現在 CRC64-NVME 已整合進最新的 Azure Blob SDK，涵蓋 .NET、C++、JavaScript
這等於把保護延伸到用戶端應用程式：用 CRC64-NVME 檢查碼，驗證寫入與讀取 Blob 的資料，從應用程式層到 Azure 底層實體儲存，都逐位元組完整
起步方式：升級到最新的 .NET、C++ 或 JavaScript SDK

上表是依檢查碼的一般用途整理，不是公告原文列出的案例。

以下取自 Microsoft Learn 文件：

.NET 的 StorageChecksumAlgorithm 列舉有四個值：Auto（建議，由程式庫選擇演算法，不同版本可能選不同的）、None（不計算也不要求檢查碼）、MD5、StorageCrc64（Azure Storage 的 64 位元 CRC）
REST API 層：結構化本文（Structured Body）格式，是 Blob、File、DFS API 用來高效計算檢查碼的二進位格式；請求本文會被編碼成「標頭、一個或多個分段、結尾」，結尾只支援 crc64 檢查碼。使用支援的 SDK，請求會自動編碼成這種格式；直接呼叫 REST API 的人則要自己處理，且這個格式是選用的
目前這個格式只有第 1 版，只支援 CRC64
公告沒有說明預設是否自動啟用、效能影響，以及各 SDK 的最低版本；上線前請看各語言 SDK 的發行說明與文件

我常幫客戶做的網站與後台，檔案上傳、報表下載是很常見的功能，而「檔案壞掉」這類問題最麻煩的是：很少發生，但一發生就很難重現，也很難證明是哪一段出的錯。有了端對端的檢查碼，至少能把問題範圍縮小到「上傳前」「雲端內」「下載後」三段，不用再猜。

不過我也不會因此就把它當成萬靈丹：檢查碼只能告訴你資料「有沒有走樣」，不能保證內容本身正確，也不能取代備份。建議把它跟版本控制與備份一起用，並且先在測試環境確認自己用的 SDK 版本真的有開啟。

資料完整性檢查是什麼？

就像寄包裹時貼的封條或條碼：寄件時算出一組「指紋」（檢查碼），收件時再算一次，兩組對得上，就代表途中沒有被改動或損毀。Blob Storage 以前就支援 MD5，也支援 CRC64-NVME；這次是把後者放進用戶端 SDK。

我需要改程式嗎？

公告只說要升級到最新的 SDK。.NET 的程式庫有 StorageChecksumAlgorithm 列舉，值有 Auto、None、MD5、StorageCrc64，文件建議用 Auto 讓程式庫自己選，但不同版本可能選不同演算法。要明確使用 CRC64 的話，請以官方文件的最新做法為準。

沒有用 SDK、直接呼叫 REST API 怎麼辦？

官方有一份「結構化本文格式」規格，說明 Blob、File、DFS API 用來高效計算檢查碼的二進位格式；支援的 SDK 會自動把請求編碼成這種格式。目前只有第 1 版，只支援 CRC64 檢查碼，使用上是選用的。

作者

接案做系統開發、網站與主機託管。觀點裡的文章都是我自己寫的,寫的是做專案時第一手遇到的事。