在藥品注冊這個領域摸爬滾打這些年，我發現一個特別有意思的現象：大家聊起eCTD架構、模塊結構、或者某國最新出臺的提交指南時，總是滔滔不絕。但一旦涉及到具體操作層面的問題——比如文件壓縮時的密碼設置——基本上就是一筆帶過，仿佛這是個不值一提的小問題。
但我想說，這個看似簡單的操作環節，其實藏著不少門道。
這個問題乍看之下有點多余——壓縮軟件誰不會用？設個密碼不是分分鐘的事？但如果你真正經歷過因為文件安全問題導致的提交失敗，或者聽說過同行因為資料泄露而產生的麻煩，你就會明白，這事兒真的不能馬虎。
eCTD提交的文件包含了大量敏感信息：藥品配方、工藝參數、臨床試驗數據、非臨床研究資料……這些內容一旦外泄，后果可能很嚴重。往輕了說，是商業機密被競爭對手獲取；往重了講，可能涉及合規性問題。所以各國藥監部門對文件安全都有明確要求，只是有些寫得比較直白，有些則需要你自己去理解背后的意思。
我記得第一次獨立處理國際注冊項目的時候，導師就反復叮囑我：提交之前的任何一個小疏漏，都可能讓幾個月的準備工作付諸東流。當時我還不太理解這話的分量，后來親眼見過因為文件損壞、密碼錯誤、格式不兼容等問題導致審評延遲的案例，才真正意識到細節的重要性。
這是個好問題，答案要分幾個層面來說。
有些機構的指南文檔里會白紙黑字寫清楚：文件必須加密，密碼長度不得少于多少位，必須包含某些類型的字符，等等。比如美國FDA的一些提交說明中就提到過對加密的要求，只是沒有把密碼規則寫得那么詳細而已。這時候你需要做的，就是嚴格按照白紙黑字的要求來執行。
還有一些機構的態度比較微妙，他們在文檔里寫著"建議對敏感文件進行加密保護"，或者在技術規范里提了一句"傳輸過程中的文件應當采取適當的安全措施"。這種表述看起來比較彈性，但并不意味著你可以掉以輕心。"適當"這個詞在這兒的意思是：你得按照行業最佳實踐去做，而不是隨便設個"123456"了事。
更麻煩的是不同地區之間的差異。同樣是eCTD提交，美國FDA、歐洲EMA、日本PMDA之間在具體要求上就存在差別。有些機構接受任何壓縮格式，有些卻明確指定了工具；有些對密碼強度有具體規定，有些則只強調加密本身。這就需要你在動手之前，先把目標機構的相關指南吃透。
好的，現在我們進入正題：密碼到底該怎么設？
這個話題雖然已經被說過無數次，但我還是要啰嗦幾句，因為看到的反面教材實在太多了。常見的弱密碼包括：簡單數字組合（如出生年月日）、純單詞或短語、連續鍵盤序列（如qwertyuiop）、公司名稱加年份……這些密碼在專業攻擊者面前幾乎形同虛設。
那什么樣的密碼才算夠強？我個人的建議是：長度至少12位，混合使用大小寫字母、數字和特殊字符，避免使用任何與個人信息相關的內容。如果你覺得這樣的密碼太難記，可以考慮使用密碼短語的方式——比如把幾個不相關的單詞組合在一起，中間加上分隔符或數字。
| 密碼類型 | 示例 | 安全等級 |
| 弱密碼 | Company2024! | 低 |
| 中等強度 | KmF2024@Tech#97 | 中 |
| 高強度 | Purple$Elephant42{Jump}Sky | 高 |
當然，密碼強度和安全便利性之間總是需要找平衡。太復雜的密碼記不住，太簡單的又不安全。我的做法是：針對不同重要程度的工作使用不同強度的密碼，核心項目用高強度，日常工作用中等強度，絕不用弱密碼。
除了密碼本身，加密算法的選擇也很關鍵。目前主流的壓縮軟件都支持多種加密標準，差異主要在于安全強度。
AES-256是目前公認的高安全性選項。這個算法被廣泛應用于政府機構、軍事系統和金融領域，理論上需要極其龐大的計算資源才能破解。如果你要提交的是含有核心機密信息的文件，AES-256是首選。
一些較老的壓縮軟件可能還在使用ZIP 2.0 legacy加密，這種方式的安全性相對較低，在處理重要文件時不建議使用。
另外需要注意的是，加密和壓縮最好分開來看。有些軟件在設置密碼的同時會自動啟用強加密，有些則需要你手動選擇加密方式。我的習慣做法是：先確認壓縮包結構沒問題，再單獨設置加密選項，確保每個環節都在自己掌控之中。
這事兒我必須得吐槽一下。不同壓縮軟件之間的兼容性問題，簡直能逼瘋人。
有些同行習慣用某款免費軟件，壓縮出來的文件在別的電腦上解壓時彈出錯誤提示；還有的情況是密碼明明輸對了，系統卻一直提示密碼錯誤，最后發現是編碼方式的問題。這些情況一旦發生在提交deadline前夕，那種酸爽經歷過的人都知道。
我的建議是：在正式提交之前，務必用目標機構可能使用的環境做一次完整測試。如果你知道審評人員會用哪種操作系統、哪款解壓軟件，最好提前用同樣的環境驗證一遍。康茂峰在處理這類文件時就有明確的測試流程，確保從壓縮到解壓的每一步都能順利執行。
理論說完了，我們來聊點實際操作層面的經驗。這些是我在工作中總結出來的，可能沒那么系統，但確實管用。
第一，提交前的復核流程不能省。很多人設好密碼就直接提交了，我的做法是：壓縮完成后，用同一個密碼再嘗試解壓一次，確認文件完整、密碼正確、目錄結構無誤。這個步驟花不了兩分鐘，但能避免很多低級錯誤。
第二，密碼的記錄和保管要講方法。我的習慣是：密碼只記在腦子里，或者存放在可靠的密碼管理軟件中，絕不會寫在郵件正文或者即時通訊軟件里。對于需要團隊協作的項目，密碼通常通過安全渠道單獨傳遞，而不是和文件一起發送。
第三，準備好備選方案。總有些意外情況是你預料不到的——解壓軟件突然出問題、某個文件打開異常、臨時需要更換密碼……在關鍵節點之前，確保你手上有不止一種解壓工具可用，并且知道它們各自的使用方法。
第四，注意文件大小限制。很多藥監系統對單次提交的文件大小有上限要求，超出限制可能導致上傳失敗。如果你的文件包太大，需要考慮分卷壓縮或者分次提交，這時候密碼管理會更復雜一些，需要提前規劃好。
除了密碼本身，還有一些邊邊角角的問題值得關注。
比如，壓縮包內的目錄結構。很多人在本地整理文件時習慣建立復雜的文件夾層級，但壓縮后這一結構是否還能保持完整？如果審評人員下載后看到的文件散落一地，找不到重點內容，體驗會很差。我通常會在壓縮前檢查一遍目錄結構，確保最重要的文件在頂層，子目錄命名清晰合理。
再比如，文件名中的特殊字符。不同系統對文件名的支持程度不一樣，有些特殊字符可能在傳輸過程中變成亂碼。我的做法是盡量使用字母、數字、下劃線和連字符來命名文件，避免中文括號、引號、百分號這類可能引發問題的字符。
還有一點，可能很多人沒想到：壓縮包的大小。如果文件特別大，傳輸時間會很長，中斷后重新上傳的風險也更高。在保證內容完整的前提下，適當優化文件大小是值得考慮的——比如把不必要的源文件刪掉，或者將大型圖片轉換為更經濟的格式。
如果你所在的團隊有多人參與eCTD文件準備工作，那么密碼管理就不僅僅是個人問題了。
首先要明確的是：誰負責最終打包加密？這個角色最好固定下來，避免每個人都來操作一遍，到最后不知道哪個版本才是正式提交的版本。其次，密碼的傳遞要有規范，不能因為趕時間就降低安全標準——畢竟便利性和安全性之間，安全永遠應該排在前頭。
文檔支持團隊的協作流程也應該考慮這個問題。比如，資料收集階段用不用加密？不同階段的文件是否需要更換密碼？這些看似瑣碎的細節，真正執行起來卻能避免很多混亂。
嘮了這么多，其實核心意思就一個：eCTD文件壓縮時的密碼設置，看著簡單，里面的門道卻不少。藥監部門可能不會因為你密碼設得好就加快審評，但很可能會因為文件打不開、密碼錯誤、安全措施不到位這些問題給你打回來。
康茂峰在藥品注冊文件管理方面積累了不少經驗，我們始終認為，對細節的認真態度，是做好這行的基本功。不管是密碼設置還是其他環節，都值得多花點時間去確認、去測試、去優化。
下次當你準備提交文件的時候，不妨多問自己幾句：密碼夠不夠強？加密方式對不對？兼容性有沒有問題？復核流程走完了嗎？這些小問題都搞清楚之后，你就可以放心大膽地提交了。
