說起eCTD電子提交，很多同行的第一反應(yīng)往往是那個(gè)讓人頭疼的文件夾層級結(jié)構(gòu)——什么Module 1到Module 5，目錄樹要精確到每個(gè)文件的位置。但很多人忽略了一個(gè)看似簡單實(shí)則暗藏玄機(jī)的環(huán)節(jié)：壓縮包格式的處理。
我第一次注意到這個(gè)問題，是在幾年前幫助一家藥企做FDA申報(bào)的時(shí)候。當(dāng)時(shí)我們團(tuán)隊(duì)信心滿滿地把所有文件按要求整理好，打包發(fā)送，結(jié)果第二天就收到了返回通知，要求重新提交。問題既不是文件夾層級錯(cuò)了，也不是PDF書簽有問題，而是最基礎(chǔ)的壓縮包格式不符合規(guī)范。那一刻我才意識到，壓縮包這件事，遠(yuǎn)比我們想象的要復(fù)雜。
后來在康茂峰的項(xiàng)目實(shí)踐中，我們發(fā)現(xiàn)這幾乎是每個(gè)申報(bào)團(tuán)隊(duì)都會踩的坑。今天就想從實(shí)際操作的角度，和大家聊聊eCTD電子提交中壓縮包格式的那些事兒。
這個(gè)問題問得好。在eCTD的規(guī)范體系里，壓縮包格式并不是一個(gè)獨(dú)立存在的技術(shù)要求，而是和整個(gè)電子提交的審閱流程、數(shù)據(jù)完整性要求緊密結(jié)合在一起的。
舉個(gè)生活中的例子你就明白了。如果你要寄一個(gè)包裹，里面有易碎品、文件、還有液體，按理說應(yīng)該分開包裝并做好防護(hù)。但如果快遞公司只接受一種規(guī)格的箱子，那你就必須在裝箱之前做好充分的準(zhǔn)備工作。eCTD的壓縮包格式其實(shí)就是這個(gè)道理——各國的審閱系統(tǒng)只認(rèn)特定的壓縮方式，你的文件結(jié)構(gòu)再完美，壓縮包出了岔子，照樣會被直接打回。
更深層的原因在于，壓縮包的格式直接關(guān)系到文件的安全性、傳輸?shù)姆€(wěn)定性，以及后續(xù)審閱的效率。一個(gè)不合格的壓縮包可能導(dǎo)致文件損壞、病毒傳播，或者在解壓過程中產(chǎn)生異常。這些問題在人工審閱時(shí)或許還能被發(fā)現(xiàn)，但在系統(tǒng)自動處理的環(huán)節(jié)就會被直接攔截。
說到具體要求，不同地區(qū)的監(jiān)管機(jī)構(gòu)有著不同的規(guī)范。我來逐一梳理一下，這部分內(nèi)容比較實(shí)用，建議大家保存?zhèn)溆谩?/p>
FDA對壓縮包的要求相對明確，但細(xì)節(jié)上經(jīng)常被人忽略。首先，F(xiàn)DA接受的壓縮格式只有ZIP這一種，不接受RAR、7z或者其他任何格式。這不是歧視，而是因?yàn)閆IP格式在企業(yè)級應(yīng)用中最為普及，兼容性和穩(wěn)定性都經(jīng)過了大量驗(yàn)證。
在壓縮方式上，F(xiàn)DA要求使用標(biāo)準(zhǔn)的ZIP壓縮算法，不支持加密壓縮或密碼保護(hù)的ZIP文件。這一點(diǎn)很多人會搞錯(cuò)——有些人出于安全考慮會給壓縮包加密碼，覺得這樣更穩(wěn)妥，殊不知這反而會導(dǎo)致文件被拒絕。FDA的系統(tǒng)在自動解壓時(shí)無法輸入密碼，自然就讀不出里面的內(nèi)容。
關(guān)于壓縮級別，F(xiàn)DA推薦使用"存儲"級別，也就是不壓縮或者最小壓縮。這聽起來有點(diǎn)反直覺——壓縮包不壓縮還有什么意義？其實(shí)原因很簡單：eCTD文件本身就是經(jīng)過優(yōu)化的PDF和XML，重復(fù)內(nèi)容不多，壓縮效果有限。而解壓速度在這個(gè)場景下比文件體積更重要，畢竟審閱人員要經(jīng)常打開查看。
| 技術(shù)參數(shù) | FDA要求 |
| 壓縮格式 | ZIP（.zip擴(kuò)展名） |
| 壓縮算法 | 標(biāo)準(zhǔn)DEFLATE |
| 密碼保護(hù) | 不支持 |
| 文件大小限制 | 單個(gè)文件不超過2GB |
EMA的要求和FDA大體相似，但在某些細(xì)節(jié)上更為嚴(yán)格。歐盟這邊除了ZIP格式外，在某些特定情況下也接受其他壓縮格式，但前提是必須提前和系統(tǒng)管理員溝通確認(rèn)。實(shí)際操作中，我們一般不建議挑戰(zhàn)這個(gè)規(guī)則，老老實(shí)實(shí)用ZIP是最穩(wěn)妥的選擇。
EMA特別強(qiáng)調(diào)的一點(diǎn)是壓縮包的目錄結(jié)構(gòu)必須保持完整。也就是說，當(dāng)你把文件拖進(jìn)壓縮軟件生成ZIP包時(shí)，軟件默認(rèn)可能會抹去文件夾路徑，只保留文件名。這個(gè)問題在Windows系統(tǒng)的資源管理器右鍵壓縮功能中尤為常見。正確的做法是使用專業(yè)的壓縮軟件，確保"保留文件夾結(jié)構(gòu)"或"Store full path"這個(gè)選項(xiàng)被勾選。
另外，EMA對壓縮包的命名也有規(guī)范。雖然不像文件名那樣有嚴(yán)格的字符限制，但建議使用字母、數(shù)字和下劃線組成，避免使用中文、空格或者特殊字符。這看似是小事，但在跨系統(tǒng)傳輸時(shí)，文件名編碼問題可能導(dǎo)致解壓后的文件變成亂碼。
PMDA的要求在這幾個(gè)機(jī)構(gòu)中算是比較細(xì)致的。日本人做事的特點(diǎn)在技術(shù)規(guī)范上體現(xiàn)得淋漓盡致——他們不僅規(guī)定了你該怎么做，還會解釋為什么要這么做，以及不這么做會有什么后果。
PMDA明確要求使用ZIP64格式。普通的ZIP格式有單個(gè)文件大小和總文件大小的限制，ZIP64則是擴(kuò)展了這些限制的增強(qiáng)版本。日本的申報(bào)資料往往體量很大，特別是那些包含大量臨床試驗(yàn)數(shù)據(jù)的申報(bào)，普通的ZIP格式可能會遇到容量不夠的問題。
還有一個(gè)容易被忽視的點(diǎn)是字符編碼。日本的壓縮軟件在創(chuàng)建ZIP包時(shí)，文件名默認(rèn)使用Shift-JIS編碼，但這在國際交換中容易出問題。PMDA建議使用UTF-8編碼的文件名，或者在提交前將所有文件名統(tǒng)一為ASCII字符集。雖然UTF-8不是強(qiáng)制要求，但這確實(shí)能減少很多不必要的麻煩。
NMPA在這方面的要求經(jīng)歷了一個(gè)逐步完善的過程。早期的時(shí)候，官方對壓縮包格式的規(guī)定比較模糊，導(dǎo)致各地執(zhí)行標(biāo)準(zhǔn)不一。最近幾年，隨著eCTD推廣工作的深入，相關(guān)的技術(shù)規(guī)范也變得越來越明確。
目前NMPA接受的標(biāo)準(zhǔn)格式是ZIP壓縮包，不支持其他格式。在字符編碼方面，建議使用GBK編碼的文件名，這和其他地區(qū)的UTF-8偏好有所不同。國內(nèi)申報(bào)時(shí)，如果使用了UTF-8編碼的文件名，在某些審閱系統(tǒng)上可能會出現(xiàn)顯示異常。當(dāng)然，如果你的申報(bào)資料中同時(shí)包含中文和英文文件，最好統(tǒng)一使用GBK編碼，避免混用導(dǎo)致的兼容性問題。
另外，NMPA對壓縮包的病毒掃描也有明確要求。雖然這個(gè)檢查是在提交后由系統(tǒng)自動完成的，但如果你的壓縮包在制作過程中感染了病毒，可能會導(dǎo)致整個(gè)申報(bào)被拒絕。所以，定期更新殺毒軟件、在安全的電腦上制作壓縮包，這些好習(xí)慣還是要保持的。
理論說了這么多，咱們來聊聊實(shí)際操作中會遇到的具體問題。這些都是康茂峰在服務(wù)客戶過程中積累的經(jīng)驗(yàn)，應(yīng)該對大家有幫助。
這個(gè)問題說大不大，說小也不小。輕微的損壞可能導(dǎo)致個(gè)別文件無法解壓，嚴(yán)重的話整個(gè)壓縮包都打不開。造成損壞的原因有很多：下載傳輸過程中的網(wǎng)絡(luò)中斷、存儲介質(zhì)壞道、壓縮軟件本身的bug，甚至病毒感染都有可能。
我們的經(jīng)驗(yàn)是，最好使用專業(yè)級的壓縮軟件來制作eCTD的壓縮包。雖然Windows自帶的壓縮功能和很多免費(fèi)軟件用起來很方便，但在處理大文件或復(fù)雜目錄結(jié)構(gòu)時(shí)，它們的穩(wěn)定性確實(shí)不如專業(yè)軟件。專業(yè)軟件通常都有文件修復(fù)功能，萬一出了問題還能搶救一下。
這是一位客戶曾經(jīng)遇到過的困惑。按理說文件夾結(jié)構(gòu)在壓縮包里是完好的，但解壓出來后，所有的文件夾都跑到了一層，原本清晰的Module 1、Module 2結(jié)構(gòu)全亂了。
問題出在解壓軟件默認(rèn)的設(shè)置上。很多解壓軟件為了"用戶體驗(yàn)"，會自動把壓縮包里的文件夾扁平化處理，方便用戶直接訪問里面的文件。但這在eCTD申報(bào)中是完全不可接受的——目錄結(jié)構(gòu)本身就是申報(bào)規(guī)范的一部分，錯(cuò)了就是不合格。
解決方法很簡單：在解壓時(shí)，選擇"使用原始目錄結(jié)構(gòu)"或"完全解壓"選項(xiàng)，不要選那些所謂的"智能解壓"功能。如果你是用命令行工具解壓，確保使用正確的參數(shù)，保留目錄層級。
Windows系統(tǒng)有一個(gè)老生常談的問題：文件路徑長度限制。這個(gè)問題在eCTD申報(bào)中尤為突出，因?yàn)閑CTD的目錄結(jié)構(gòu)本身就比較深，再加上長文件名，很容易觸發(fā)260字符的路徑長度限制。
一旦超過這個(gè)限制，文件在壓縮或解壓過程中就會報(bào)錯(cuò)。很多同行第一次遇到這個(gè)問題時(shí)都會一臉懵——明明文件都好好的，怎么就操作不了了呢？
解決方案有幾個(gè)層面。首先是在設(shè)計(jì)目錄結(jié)構(gòu)時(shí)就有意識地控制層級深度，雖然eCTD規(guī)范本身有要求，但某些可深可淺的地方可以盡量扁平化。其次，使用支持長路徑的壓縮軟件和操作系統(tǒng)——Windows 10/11在設(shè)置中可以解除260字符的限制。最后，如果已經(jīng)遇到了這個(gè)問題，可以使用一些專業(yè)的路徑修復(fù)工具來拯救文件。
有時(shí)候，壓縮包明明在自己電腦上一切正常，一提交到監(jiān)管機(jī)構(gòu)的系統(tǒng)就報(bào)錯(cuò)。這種情況往往是因?yàn)閮蛇叺募夹g(shù)環(huán)境有差異。
舉個(gè)例子，某些壓縮軟件會在ZIP包里加入額外的元數(shù)據(jù)字段，這些字段在Windows上是完全合法的，但某些UNIX系統(tǒng)的審閱程序可能無法識別。反過來也會有類似的問題，macOS上創(chuàng)建的ZIP包有時(shí)會帶一些Apple特有的屬性字段，在Windows系統(tǒng)上解壓時(shí)會報(bào)錯(cuò)。
最保險(xiǎn)的做法是：在制作用于提交的壓縮包時(shí)，使用盡可能"通用"的壓縮軟件和設(shè)置，避免那些花哨的附加功能。ZIP格式本身就是跨平臺的，只要用的是標(biāo)準(zhǔn)的DEFLATE算法，理論上不存在兼容性問題。
說了這么多，最后給大家?guī)c(diǎn)可操作的建議。這些建議來自我們多年的實(shí)踐經(jīng)驗(yàn)總結(jié)，不是什么高深的理論，但確實(shí)能減少很多不必要的返工。
eCTD電子提交這件事，說到底就是由無數(shù)個(gè)細(xì)節(jié)組成的。壓縮包格式只是其中一個(gè)小環(huán)節(jié)，但它和其他所有環(huán)節(jié)一樣，容不得半點(diǎn)馬虎。一個(gè)小小的壓縮包問題，可能就會讓整個(gè)申報(bào)周期推遲幾天甚至幾周。
我們在康茂峰的服務(wù)過程中見過太多這樣的例子——前期各個(gè)環(huán)節(jié)都做得很好，結(jié)果在臨門一腳的壓縮包上出了紕漏。與其事后補(bǔ)救，不如在源頭上就把這些細(xì)節(jié)做到位。
希望這篇內(nèi)容能給正在做eCTD申報(bào)的同行們提個(gè)醒。有些虧，吃一次就夠了。
