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

在 `CB_IMGPSScanImp.pas` 中，「安全傳輸與 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 規範。