顧客上載附件：說清要求、保障檔案與處理失敗

先決定需要甚麼文件

加入上載欄位前，先問清楚檔案用來支持甚麼決定。保養申請可能需要收據及故障相片；報價查詢或許需要圖則。兩種文件的敏感程度、審閱人員和處理方法都不同。可先評估資料能否用結構化欄位填報、相片是否已足夠，以及顧客可否先送出申請，稍後才補交證明。預先收集所有可能用到的附件，會增加保存量及審閱工作，未必令決定更準確。團隊應記下誰可以上載、檔案歸屬哪個個案、誰可查閱及何時刪除。對顧客的說明要指出用途，而非只寫內部儲存系統名稱。

把這項決定化為清楚的檔案規格，然後才設計介面。訂明真正需要的格式清單、每份檔案的容量上限、可否上載多份，以及相片是否須看得清楚。容量上限應按實際文件及服務能力決定，不應照抄別家網站的數字。另要說明加密文件能否被審閱；若允許格式無法呈現顧客的證據，便提供其他提交途徑。頁面、網關、應用程式和職員指引須使用同一套要求。若第一層接受而第二層拒絕，顧客花時間拍攝或掃描後，只會遇到難以理解的失敗。

讓選檔與修正都容易

在有標籤的檔案控制項旁，選檔前就列出可接受格式和容量上限。MDN 指出，HTML 的 accept 屬性只協助檔案選擇器篩選顯示類型，不能保證伺服器收到的內容合規。因此它只是方便功能，文字規則仍須顯示。即使自訂外觀，也要讓鍵盤及輔助技術使用者可操作原生控制項。選定後，以文字顯示檔名、大小和份數，並提供明確的移除或更換方法。手機使用者可能誤選相機相片，這一步尤其有用。縮圖可以輔助確認相片，但不能證明掃描清晰或檔案安全。

拒收訊息應指出哪一份檔案出問題，以及顧客下一步可做甚麼。例如說明「收據檔案超過本表格所列上限，請選較小檔案或使用其他聯絡途徑」，比單寫「上載無效」實用。檔案失敗時，不應清除其他已填欄位。若一次提交多份附件，可保留已接受項目的可見紀錄，並清楚標示被拒的一份，但仍須遵守瀏覽器對檔案輸入的安全限制。W3C 的錯誤識別指引要求，以文字指出出錯項目及問題。測試提交後能否找到訊息、放大頁面後能否閱讀，以及訊息是否連到相應控制項。瞬間消失的提示，可能令顧客不知道整份申請是否已送出。

收到檔案後再核對及隔離

所有選定檔案都應視為未經信任的輸入。OWASP 建議只允許必要副檔名、核對由瀏覽器提供的 Content-Type 以外的內容、限制大小、由系統產生儲存名稱，並控制存取權。檔名和瀏覽器所報的 MIME 類型都不是內容證明。檢查副檔名前，先按規格解碼及正規化檔名；遇到可能繞過檢查的命名方式，應拒絕而非勉強整理成可執行路徑。若格式有可靠的檔案特徵，可把實際位元組與預期類型比對；這只是一層防護，並不保證檔案完全無害。按文件類型和工作需要安排惡意軟件掃描或內容淨化。掃描失敗或解析器出錯時，不能悄悄把未檢查附件當作已接納。

收到的檔案應放在不可執行網站程式的路徑以外，或放在權限最少的隔離儲存位置。系統產生的識別碼可把物件連到個案；原檔名經安全處理後可作顯示資料，卻不應決定儲存路徑。上載及之後下載都要按個案核對權限，因為難猜的網址並不代表查閱者獲授權。請在接收請求時限制大小；若容許壓縮檔，解壓後亦要考慮容量。營運團隊須訂明待處理、被拒及放棄草稿的附件如何保留、刪除與記錄。實際目標是讓職員可追查及審閱附件，同時避免把客戶文件當作公開網站素材。

分清已選、已收到與已接納

裝置上已選檔、檔案已傳到伺服器，以及已被個案接納，是三件不同的事。只有真正傳送時才顯示相應進度，不要把選檔說成職員已收到。伺服器核對實際位元組後，應回傳連到個別附件和個案的狀態。若掃描需稍後完成，就寫明「已收到，待檢查」，待結果出來才更新個案。完成申請後，列出已接納的附件，並給顧客可用於查詢的參考編號。網絡中斷時，盡可能保留表格內容，亦不要引導顧客盲目重送整份申請，造成重複個案。復原指示要講清楚應重試該檔案、整份申請，還是暫時毋須重試。

以保養申請作設計情境：顧客選取一份收據 PDF 和兩張故障相片。介面在選檔前列明格式與容量規則，選檔後列出三個檔名。收據通過伺服器檢查，其中一張相片獲接納，另一張的實際格式不在允許清單內。頁面應點名該相片、保留已填寫的故障描述及已接納檔案，並提供更換方法。最後確認應列出已接納的兩份附件，而不是籠統地說「成功」。職員只能在通過個案權限核對後看見相關檔案。這是設計驗收情境，並非任何商店的實際故障率或營運紀錄。

驗收整個交接，而非只試選檔器

驗收時要涵蓋有效檔案、不允許的副檔名、誤導性的 MIME 標示、超大檔案、傳送中途截斷，以及網絡斷線。逐一檢查顧客所見和伺服器實際留下甚麼。用鍵盤走完整個選檔、移除、處理錯誤及確認流程，再用螢幕閱讀器核對標籤和狀態文字。亦要測試窄手機畫面、放大頁面與長中文檔名。嘗試改動識別碼，確認顧客不能讀取其他個案的文件；同時核對職員角色只見到工作所需紀錄。這些是針對實際系統的驗收測試，並非一張清單就能保證上載安全。

客服亦需要一份簡短操作說明：先詢問個案編號，再指出哪份附件待檢查或已被拒，最後提供安全的補交途徑，避免叫顧客把私人文件轉寄到無關信箱。伺服器可記錄內部拒收原因碼，另備顧客看得懂的解釋；直接顯示掃描工具原始輸出，既難理解，也可能暴露系統細節。推出後可檢視真實查詢，若某種合理文件經常失敗，便修訂格式政策或說明；不應只為消除錯誤報告而放寬白名單。團隊應能就單一個案證明：顧客看到的確認、實際保留的位元組，以及職員取得的權限三者一致。

小型團隊可把接納規則寫成決策表，列明檔案用途、可接受類型、容量限制、審閱人員及後備提交方法。客服與產品團隊應使用同一版本，避免職員承諾任何檔案都能提交，而系統卻暗中阻擋。每次修改規則要有負責人；新增格式在對外公布前，須測試安全處理、可否閱讀及如何刪除。個案類型改變時亦要檢討指示，因為適合保養收據的上載方式，未必適合身份證明。這些管理工序雖小，卻能讓顧客承諾與系統實況一致。