安全傳輸與 API 通訊模組 (Transport Manager) 深度分析

在 CB_IMGPSScanImp.pas.bk 中，「安全傳輸與 API 通訊模組」負責處理 ActiveX 客戶端與後端伺服器 (如 Java Servlet 平台) 之間的所有資料交換與檔案傳輸。由於涉及機敏的金融/保險文件，此模組高度依賴加密與安全通訊協定。

若要將此模組進一步細拆，其內部組成可分為以下四大子分類：

1. HTTP/HTTPS API 請求管理器 (RESTful / Servlet Client Wrapper)

職責：專責透過 HTTP(S) 協定，向後端的 Java Servlet 端點發送 GET/POST 請求，用於同步時間、下載設定檔或回報案件狀態。
核心實作特性：
* 套件依賴：底層依賴 SecureBlackbox 的 TElHTTPSClient (在變數宣告為 HTTPSClient) 處理 SSL/TLS 連線。
* 字串/表單資料交換：
* ProcessServlet_Get：使用 HTTP GET 方式，將加密過的參數 (SendData) 送至伺服器，並將伺服器回傳的結果寫入 FReWrite 或 Memo1 中。
* ProcessServlet / ProcessServlet_FormData：使用 HTTP POST 或 multipart/form-data 方式提交較大的資料集（如 OMR 檢核結果、案件完成通知等）。
* 狀態與錯誤攔截：檢查伺服器回傳的代碼（例如回傳 0 代表成功，1 代表錯誤，或攔截回傳 HTML 中包含 login.js 來判斷 Session 是否逾時登出）。

2. 雙協定檔案上傳/下載引擎 (Dual-Protocol File Transfer Engine)

職責：處理實體影像檔案（通常是打包後的 ZIP 檔）或系統授權檔的實體傳輸，並根據系統設定動態切換 HTTP 或 FTP 協定。
核心實作特性：
* HTTP 檔案傳輸：
* upFile：透過 HTTP POST (multipart/form-data) 將本地端的檔案 (如 Img.zip 或 .lic 檔) 上傳至伺服器指定的 Servlet 接收端。
* dnFile_Get / dnFile：透過 HTTP 協定從伺服器下載檔案 (如 OMRSet.zip, KeyinSet.zip 或舊案影像)，並提供下載狀態監控。
* FTPS 檔案傳輸 (高頻寬/大檔專用)：
* GetftpInfo：先透過 HTTP 向伺服器查詢該案件是否應使用 FTP 傳輸，並取回加密的 FTP 登入資訊。
* 依賴 SecureBlackbox 的 TElSimpleFTPSClient 建立 FTP over SSL 連線。
* SetFtpInfo、IIS_Ftp.FtpsConnect、IIS_Ftp.FtpsToMain、IIS_Ftp.FtpsDownloadFile：負責實際的 FTP 登入、切換目錄、上傳與下載操作，完成後呼叫 FtpCaseComplete 透過 HTTP 通知伺服器傳檔結束。

3. 安全加密與雜湊模組 (Security, Crypto & Hashing Utils)

職責：負責資料傳輸前後的加解密運算，以及檔案完整性的 MD5 校驗，確保通訊過程不被竄改。
核心實作特性：
* 字串加解密 (String Encryption)：
* 利用 En_DecryptionStr_Base64 函式（可能來自自訂或第三方的 Encryp 單元），對 URL 參數 (如 checktime, col 欄位清單) 進行加解密，避免敏感資訊在 URL 明文中裸奔。
* 解析加密過的 FTP 登入資訊字串。
* 檔案 MD5 雜湊校驗 (File Hashing)：
* 使用 Indy 的 TIdHashMessageDigest5 元件。
* LoadFileGetMD5：讀取本機影像檔並計算其 MD5 值，用於比對「異動件 (ESCAN)」模式下，檔案是否與伺服器原有的版本一致，防止誤刪或重複傳輸。
* 憑證管理 (Certificate Management)：
* HTTPSClientCertificateValidate：處理 X.509 憑證驗證事件，通常設定為 Validate := True 以略過嚴格的自簽憑證檢查（在內部封閉網路中常見的做法）。

4. 傳輸前置準備與封裝器 (Payload Archiver & Preparer)

職責：在真正啟動傳輸前，將硬碟上散落的 TIFF/JPG 檔案、.dat 索引檔以及 .ini 設定檔，打包成單一的封裝檔以利傳輸。
核心實作特性：
* ZIP 壓縮封裝：
* 依賴 TVCLZip (VCLZip 模組)。
* ZipMainFile：讀取 Context.dat 等清單，將案件目錄下的所有影像與關聯的索引文字檔打包成 Img.zip。
* 包含檔案大小檢核邏輯：在打包完成後，檢查 ZIP 檔是否超過伺服器允許的上限 (FMaxUploadSize)，若超過則阻擋上傳。
* ZIP 解壓縮處理：
* 依賴 VCLUnZip 模組。
* ExecuteUnZip / ExecuteUnZip_Pwd：將從伺服器下載回來的 OMRSet.zip、KeyinSet.zip 或舊案件影像壓縮檔解壓縮至指定的工作目錄中，並支援帶密碼的解壓縮。

💡 未來重構與微服務化建議

針對「安全傳輸與 API 通訊模組」，若未來系統架構演進，建議考量以下重構方向：

1. 統一且標準化的 HTTP Client (捨棄舊版第三方庫)：
   早期的 SecureBlackbox 雖然強大，但現代的開發環境 (如新版 Delphi 或 C#/Java/Node.js) 均已內建完善且高效的 HttpClient。建議將所有的 API 呼叫標準化為 RESTful API (JSON 格式)，並使用原生的網路庫。
2. 廢除 FTP，全面改用 HTTP(S) 分塊上傳 (Chunked Upload)：
   目前系統需動態切換 HTTP 與 FTPS，增加了防火牆設定 (Port 21, Passive Ports) 與除錯的困難度。現代系統處理大檔上傳，主流做法是透過 HTTP/HTTPS 的 分塊上傳 (Chunked Upload / Multipart) 搭配斷點續傳機制，建議未來可逐步汰除 FTP 傳輸路徑。
3. 非同步與背景傳輸 (Asynchronous Transfer)：
   目前上傳時會透過 DataLoading 鎖死整個 UI (Screen.Cursor := -11)，使用者必須枯等上傳完成。重構時應將 Transport Manager 放入獨立的 Thread 或背景 Service 中執行，並透過回呼 (Callback) 或事件 (Event) 更新進度條，提升使用者體驗。
4. Token-based 授權取代自訂加密：
   目前依賴自訂的 En_DecryptionStr_Base64 在 URL 傳遞加密字串作為安全驗證。建議未來升級為標準的 OAuth 2.0 (JWT Token) 放在 HTTP Header 中進行授權，更加安全且符合現代 Web 規範。