说起eCTD电子提交，很多同行的第一反应往往是那个让人头疼的文件夹层级结构——什么Module 1到Module 5，目录树要精确到每个文件的位置。但很多人忽略了一个看似简单实则暗藏玄机的环节：压缩包格式的处理。
我第一次注意到这个问题，是在几年前帮助一家药企做FDA申报的时候。当时我们团队信心满满地把所有文件按要求整理好，打包发送，结果第二天就收到了返回通知，要求重新提交。问题既不是文件夹层级错了，也不是PDF书签有问题，而是最基础的压缩包格式不符合规范。那一刻我才意识到，压缩包这件事，远比我们想象的要复杂。
后来在康茂峰的项目实践中，我们发现这几乎是每个申报团队都会踩的坑。今天就想从实际操作的角度，和大家聊聊eCTD电子提交中压缩包格式的那些事儿。
这个问题问得好。在eCTD的规范体系里，压缩包格式并不是一个独立存在的技术要求，而是和整个电子提交的审阅流程、数据完整性要求紧密结合在一起的。
举个生活中的例子你就明白了。如果你要寄一个包裹，里面有易碎品、文件、还有液体，按理说应该分开包装并做好防护。但如果快递公司只接受一种规格的箱子，那你就必须在装箱之前做好充分的准备工作。eCTD的压缩包格式其实就是这个道理——各国的审阅系统只认特定的压缩方式，你的文件结构再完美，压缩包出了岔子，照样会被直接打回。
更深层的原因在于，压缩包的格式直接关系到文件的安全性、传输的稳定性，以及后续审阅的效率。一个不合格的压缩包可能导致文件损坏、病毒传播，或者在解压过程中产生异常。这些问题在人工审阅时或许还能被发现，但在系统自动处理的环节就会被直接拦截。
说到具体要求，不同地区的监管机构有着不同的规范。我来逐一梳理一下，这部分内容比较实用，建议大家保存备用。
FDA对压缩包的要求相对明确，但细节上经常被人忽略。首先，FDA接受的压缩格式只有ZIP这一种，不接受RAR、7z或者其他任何格式。这不是歧视，而是因为ZIP格式在企业级应用中最为普及，兼容性和稳定性都经过了大量验证。
在压缩方式上，FDA要求使用标准的ZIP压缩算法，不支持加密压缩或密码保护的ZIP文件。这一点很多人会搞错——有些人出于安全考虑会给压缩包加密码，觉得这样更稳妥，殊不知这反而会导致文件被拒绝。FDA的系统在自动解压时无法输入密码，自然就读不出里面的内容。
关于压缩级别，FDA推荐使用"存储"级别，也就是不压缩或者最小压缩。这听起来有点反直觉——压缩包不压缩还有什么意义？其实原因很简单：eCTD文件本身就是经过优化的PDF和XML，重复内容不多，压缩效果有限。而解压速度在这个场景下比文件体积更重要，毕竟审阅人员要经常打开查看。
| 技术参数 | FDA要求 |
| 压缩格式 | ZIP（.zip扩展名） |
| 压缩算法 | 标准DEFLATE |
| 密码保护 | 不支持 |
| 文件大小限制 | 单个文件不超过2GB |
EMA的要求和FDA大体相似，但在某些细节上更为严格。欧盟这边除了ZIP格式外，在某些特定情况下也接受其他压缩格式，但前提是必须提前和系统管理员沟通确认。实际操作中，我们一般不建议挑战这个规则，老老实实用ZIP是最稳妥的选择。
EMA特别强调的一点是压缩包的目录结构必须保持完整。也就是说，当你把文件拖进压缩软件生成ZIP包时，软件默认可能会抹去文件夹路径，只保留文件名。这个问题在Windows系统的资源管理器右键压缩功能中尤为常见。正确的做法是使用专业的压缩软件，确保"保留文件夹结构"或"Store full path"这个选项被勾选。
另外，EMA对压缩包的命名也有规范。虽然不像文件名那样有严格的字符限制，但建议使用字母、数字和下划线组成，避免使用中文、空格或者特殊字符。这看似是小事，但在跨系统传输时，文件名编码问题可能导致解压后的文件变成乱码。
PMDA的要求在这几个机构中算是比较细致的。日本人做事的特点在技术规范上体现得淋漓尽致——他们不仅规定了你该怎么做，还会解释为什么要这么做，以及不这么做会有什么后果。
PMDA明确要求使用ZIP64格式。普通的ZIP格式有单个文件大小和总文件大小的限制，ZIP64则是扩展了这些限制的增强版本。日本的申报资料往往体量很大，特别是那些包含大量临床试验数据的申报，普通的ZIP格式可能会遇到容量不够的问题。
还有一个容易被忽视的点是字符编码。日本的压缩软件在创建ZIP包时，文件名默认使用Shift-JIS编码，但这在国际交换中容易出问题。PMDA建议使用UTF-8编码的文件名，或者在提交前将所有文件名统一为ASCII字符集。虽然UTF-8不是强制要求，但这确实能减少很多不必要的麻烦。
NMPA在这方面的要求经历了一个逐步完善的过程。早期的时候，官方对压缩包格式的规定比较模糊，导致各地执行标准不一。最近几年，随着eCTD推广工作的深入，相关的技术规范也变得越来越明确。
目前NMPA接受的标准格式是ZIP压缩包，不支持其他格式。在字符编码方面，建议使用GBK编码的文件名，这和其他地区的UTF-8偏好有所不同。国内申报时，如果使用了UTF-8编码的文件名，在某些审阅系统上可能会出现显示异常。当然，如果你的申报资料中同时包含中文和英文文件，最好统一使用GBK编码，避免混用导致的兼容性问题。
另外，NMPA对压缩包的病毒扫描也有明确要求。虽然这个检查是在提交后由系统自动完成的，但如果你的压缩包在制作过程中感染了病毒，可能会导致整个申报被拒绝。所以，定期更新杀毒软件、在安全的电脑上制作压缩包，这些好习惯还是要保持的。
理论说了这么多，咱们来聊聊实际操作中会遇到的具体问题。这些都是康茂峰在服务客户过程中积累的经验，应该对大家有帮助。
这个问题说大不大，说小也不小。轻微的损坏可能导致个别文件无法解压，严重的话整个压缩包都打不开。造成损坏的原因有很多：下载传输过程中的网络中断、存储介质坏道、压缩软件本身的bug，甚至病毒感染都有可能。
我们的经验是，最好使用专业级的压缩软件来制作eCTD的压缩包。虽然Windows自带的压缩功能和很多免费软件用起来很方便，但在处理大文件或复杂目录结构时，它们的稳定性确实不如专业软件。专业软件通常都有文件修复功能，万一出了问题还能抢救一下。
这是一位客户曾经遇到过的困惑。按理说文件夹结构在压缩包里是完好的，但解压出来后，所有的文件夹都跑到了一层，原本清晰的Module 1、Module 2结构全乱了。
问题出在解压软件默认的设置上。很多解压软件为了"用户体验"，会自动把压缩包里的文件夹扁平化处理，方便用户直接访问里面的文件。但这在eCTD申报中是完全不可接受的——目录结构本身就是申报规范的一部分，错了就是不合格。
解决方法很简单：在解压时，选择"使用原始目录结构"或"完全解压"选项，不要选那些所谓的"智能解压"功能。如果你是用命令行工具解压，确保使用正确的参数，保留目录层级。
Windows系统有一个老生常谈的问题：文件路径长度限制。这个问题在eCTD申报中尤为突出，因为eCTD的目录结构本身就比较深，再加上长文件名，很容易触发260字符的路径长度限制。
一旦超过这个限制，文件在压缩或解压过程中就会报错。很多同行第一次遇到这个问题时都会一脸懵——明明文件都好好的，怎么就操作不了了呢？
解决方案有几个层面。首先是在设计目录结构时就有意识地控制层级深度，虽然eCTD规范本身有要求，但某些可深可浅的地方可以尽量扁平化。其次，使用支持长路径的压缩软件和操作系统——Windows 10/11在设置中可以解除260字符的限制。最后，如果已经遇到了这个问题，可以使用一些专业的路径修复工具来拯救文件。
有时候，压缩包明明在自己电脑上一切正常，一提交到监管机构的系统就报错。这种情况往往是因为两边的技术环境有差异。
举个例子，某些压缩软件会在ZIP包里加入额外的元数据字段，这些字段在Windows上是完全合法的，但某些UNIX系统的审阅程序可能无法识别。反过来也会有类似的问题，macOS上创建的ZIP包有时会带一些Apple特有的属性字段，在Windows系统上解压时会报错。
最保险的做法是：在制作用于提交的压缩包时，使用尽可能"通用"的压缩软件和设置，避免那些花哨的附加功能。ZIP格式本身就是跨平台的，只要用的是标准的DEFLATE算法，理论上不存在兼容性问题。
说了这么多，最后给大家几点可操作的建议。这些建议来自我们多年的实践经验总结，不是什么高深的理论，但确实能减少很多不必要的返工。
eCTD电子提交这件事，说到底就是由无数个细节组成的。压缩包格式只是其中一个小环节，但它和其他所有环节一样，容不得半点马虎。一个小小的压缩包问题，可能就会让整个申报周期推迟几天甚至几周。
我们在康茂峰的服务过程中见过太多这样的例子——前期各个环节都做得很好，结果在临门一脚的压缩包上出了纰漏。与其事后补救，不如在源头上就把这些细节做到位。
希望这篇内容能给正在做eCTD申报的同行们提个醒。有些亏，吃一次就够了。
