工業資料匯出完整性檢查

交付契約與檢查層次

歷史資料匯出前要先定義交付契約：檔名、格式、欄位、編碼、時間範圍、筆數、排序、空資料語意與檔尾標記。SHA-256可以證明下載者拿到的bytes與產出時相同，但不能證明來源設備資料本身正確，也不能取代筆數、欄位與連續性檢查。

空檔、合法無資料與截斷檔要分開。合法無資料仍應有標頭、查詢範圍、rowCount=0與產出狀態；零位元檔可能是失敗。在契約要求結尾換行時，截斷檔可能少檔尾換行、筆數不符或最後列欄位不足，但完整檔也可能含合法缺測，需另查quality與時間連續性。

匯出前先鎖定查詢條件，保存開始、結束、時區、過濾器與資料源。若匯出期間來源仍寫入，rowCount可能改變，應使用平台快照或記錄一致性策略，不把兩次不同快照誤當檔案損壞。

來源身分與產出追溯可由權限、簽章及產出日誌支持，資料完整仍需來源清單核對。SHA-256不是來源認證，也不是內容正確性的統計檢查；它只讓同一物件的傳輸變動可被發現。

一週每分鐘資料預期10080只是案例條件。若事件型檔案不固定頻率，不能用時間長度乘頻率推定筆數，要用查詢規格、首尾時間與缺測統計。

截斷事件的可重算核對

虛構一週固定每分鐘取樣檔預期10080筆資料記錄，不含標頭，匯出中途只寫到7440列後連線中斷。匯出工具回報success不能直接採信，交付前計算實際rowCount、每列欄數、首尾timestamp、缺口數與檔案SHA-256。若重跑後得到相同完整bytes，hash相同；若同資料含產出時間欄，hash可能不同，應分清內容欄與metadata。

校驗碼流程是先產檔、flush與close、讀檔計算hash，再寫manifest；不要在檔案尚未關閉時把hash當交付證據。manifest至少列filename、bytes、rowCount、firstTimestamp、lastTimestamp、columns與hash。若檔案傳輸後重新計算hash不同，先查傳輸、編碼、換行或壓縮層。

傳輸重試不應把兩份同內容檔案當兩批資料。用exportId、queryFingerprint與hash判斷同批重送，另保存接收次數。

交付前以第三方環境重新解析、計數、驗hash並讀最後十列；把結果寫入驗收表，不能只附一個hash字串。

完整性核對還要分邏輯和傳輸兩層。邏輯層檢查時間、欄位、品質與筆數，傳輸層計算封裝前後hash。壓縮、加密或重新換行會改變bytes，應在每一層寫明hash scope，不把不同層的值互相比較。

傳輸完整但內容少列時，hash仍會穩定地證明錯檔被完整傳送；因此筆數、首尾時間和完成旗標必須在hash之外檢查。

hash與manifest的邊界

Hash只回答同一bytes，不回答來源完整。攻擊者或錯誤流程若產生一個錯檔並同時更新hash，hash仍能匹配，所以來源簽名、權限與產出日誌另行保存。

驗收時故意刪最後一列、改一個字元、截斷檔尾並重算：筆數或欄數應先報錯，字元修改會導致hash變更；若只改manifest而不驗證簽章，仍可能掩蓋問題。對含逗號、換行、UTF-8 BOM與空值的CSV，要用正式解析器檢查而非只用文字搜尋。

平台匯出API、壓縮方式與檔尾規則各異，未指定產品時不捏造命令。交付流程只描述檢查點；實作前查官方匯出規格、編碼、分頁、時間戳及錯誤回報。

hash計算輸入要固定：原始CSV、壓縮包或解壓後檔案是不同bytes。manifest列出hashAlgorithm與hashScope，接收者才能重算同一物件。

若匯出規格提供完成旗標或頁尾摘要，應與自行計算的rowCount互相比對。兩者不一致先保留檔案和日誌，標記QUARANTINED，不要為了交付刪掉最後幾列或手動補成預期筆數。

檔案交付後接收者應在隔離目錄解析，確認大小、hash、欄位、首尾時間與抽樣內容，再移入報表目錄。任何失敗都保留原檔名、接收時間與錯誤，方便追查。

接收者先複製檔案到隔離區，不在原檔上修正缺列。若發現截斷，重新產出新exportId並保留舊檔、舊hash和失敗原因；手動補列會破壞來源與交付證據的區分。

資料欄位型別也要核對，數值不能因CSV解析變成文字或小數截斷；timestamp不能因時區格式化丟掉offset。抽樣讀取首、中、尾列並和來源摘要比對，補足hash無法回答的內容問題。

驗收流程與平台限制

FAQ1：hash相同是否表示資料真實？不表示，只能說bytes一致。

FAQ2：rowCount正確是否沒有缺測？不一定，還要檢查時間連續性與quality。

CSV欄位內若含換行，不能用行數直接當rowCount；要用符合格式的解析器計算record。引號、逗號、UTF-8與BOM都要納入測試，檔尾換行規則也要寫交付契約。

筆數檢查要和時間連續性分開。事件型資料可能合法只有一筆，固定一週的時序資料才適合用預期筆數；任何預期值都要來自查詢契約或來源排程，不從檔案大小猜。

若檔案沒有資料，manifest仍應說明查詢成功但rowCount為零，或查詢失敗而沒有檔案；兩者不能共用同一個空白檔。

若rowCount只在檔案內保存，檔案截斷時摘要也可能一起遺失；因此manifest應在檔外保存，並與檔名、exportId及hash關聯。

manifest本身也要納入簽章或版本管理，並明確說明是對原始檔、壓縮檔還是解壓檔計hash。接收者按同一範圍重算，才能判斷傳輸是否改變內容。

若查詢有分頁，還要核對頁數、每頁游標和總數；只取到第一頁的檔案可能格式完全正確，卻仍缺少大部分事件，交付前必須顯示分頁完成並完整留存交付檔案。

FAQ與來源

FAQ3：空檔可以當合法無資料嗎？要有標頭、查詢範圍和rowCount=0契約。

FAQ4：先傳檔再算hash可以嗎？應完成close後計算並保存manifest。

參考：NIST FIPS 180-4 Secure Hash Standard。

參考：RFC 4180 CSV格式說明。

截斷檔可能最後一行仍有完整欄位但少了後續事件，所以要按取樣契約檢查最後預期時槽及完成標記；半開區間的資料不應要求出現end那一筆。單看檔尾換行不足以證明完整。

檢查表把邏輯錯誤、檔案截斷、編碼錯誤與來源缺測分開開票，處理者才能補資料或重跑正確步驟。

完成交付的證據是一組可重做的紀錄，而不是單一成功畫面。保存查詢條件、工具版本、產出時間、rowCount、首尾時間、hash與驗收人，下一次收到相同檔案時才能快速比對。

完成案例應有10080筆、七欄、最後時槽週日23:59且來源查詢完成；7440筆案例即使hash一致也拒收。RFC 4180允許末筆沒有結尾換行，因此只有本案契約明定換行時才能以此報錯，不把它當所有CSV的通用必要條件。

延伸閱讀

• 工業日報與班報的跨日邊界
• 工業報表雙Y軸的判讀與排錯