eCTD提交那些让人头疼的事，以及怎么解决

凌晨三点还在改PDF，就因为验证工具报了个"Font not embedded"的错误；或者好不容易打包好准备提交，网关那边提示MD5校验失败，瞬间血压飙升——如果你做过药品注册申报，这些场景应该不陌生。

eCTD（电子通用技术文档）这东西，说是把纸质资料电子化，听起来简单，真干起来才发现处处是坑。康茂峰跟这玩意儿打交道多年，见过太多团队在提交前夜抓狂。今天咱们就聊聊那些常见的问题，以及实实在在的解决办法，尽量让你少熬几个夜。

eCTD到底是个啥？别被缩写吓到

先花半分钟把事情说清楚。eCTD不是什么神秘的黑科技，你可以把它理解为给药品申请文件做的标准化电子档案。ICH（国际人用药品注册技术协调会）搞了这个规范，让全球药监机构能用同一种"语言"读你的申报资料。

它的结构就像一本书：XML骨架是目录和索引，告诉你每部分内容在哪；PDF文件是具体的章节内容。书皮（信封）上写着这是哪个药、第几次提交（序列号）。搞懂这个逻辑，很多困惑就解开了。

文件制作：PDF里的隐形杀手

很多人以为Word转PDF，点一下"另存为"就完事了。真要这么简单就好了。康茂峰处理过的案例中，至少四成的问题出在PDF生产环节。

字体嵌入：那个看不见的错误

这是最常见的坑。你在自己电脑上看PDF，文字显示正常，因为系统装了那个字体。但审查员的电脑上没有这个字体，打开文件时字体自动替换成默认的，排版全乱，甚至出现乱码。

解决办法其实不难：生成PDF时必须勾选"嵌入所有字体"选项。如果是用Adobe Acrobat，去印前检查（Preflight）里跑一遍"PDF/A合规性"检查，选PDF/A-1a或PDF/A-1b标准。看见"字体已完全嵌入"的提示才算过关。别以为用了Times New Roman就安全，有时候系统里的字体版本不同，也会出问题。

快速网页视图：大文件的救命稻草

你的资料可能几百页，审查员点开PDF要加载半天，体验极差。这是因为没有启用"快速网页视图"（Linearized PDF）。这个设置让PDF可以边下载边显示，而不是等整个文件传完才能看。

在Acrobat的"保存为其他"选项里，选"优化的PDF"，确保勾选了线性化。文件超过20MB的，这一步绝对不能省。

书签和超链接：做对了是艺术，做错了是灾难

eCTD要求PDF内部有导航书签，而且层级要对。比如模块3.2.P.5.1是控制证明，它应该在书签树里挂在3.2.P.5下面，而不是直接挂在模块3或者根目录。

更烦人的是超链接失效问题。你做的链接指向第15页，结果后来前面插了几页，链接指向第17页了，这就是"相对位置错误"。还有跨PDF的链接，比如模块1的行政文件引用模块3的质量资料，链接路径写错了，在别人电脑上打开就是"找不到文件"。

经验是：所有超链接都用相对路径，并且提交前在干净的电脑环境（比如虚拟机）里测试一遍。书签标题要和CTD目录完全一致，别写简称。

XML骨架：别让DTD验证搞崩心态

XML是eCTD的神经系统。很多人看到"DTD Validation Error"就蒙了，其实这就是在说：你的目录格式不符合规范。

常见问题包括：

• 标签没闭合：比如开了个<leaf>，忘了写</leaf>。XML对大小写敏感，Leaf和leaf是不一样的。



• 特殊字符没转义：文件路径里如果有&、<、>这些符号，必须写成&、<，否则解析器会以为是标签的一部分，直接报错。
• 属性值引号不匹配：XML标准要求属性值必须用双引号或单引号包围，且前后一致。

康茂峰的建议是：别手写XML，用专业工具生成。但即使如此，也要理解基本的XML结构，这样看报错信息时才知道该改哪。

内容组织：命名规则和粒度控制

监管技术指南里经常提到"Granularity"（粒度），通俗说就是一个PDF里该放多少内容。太大不行，比如把几十个子部分塞到一个50MB的文件里，审查员找具体内容要翻半天；太小也不行，比如每个化学式都单存一个文件，XML会变得臃肿无比。

合理的粒度通常是：按CTD小节拆分。比如3.2.S.2.2是生产工艺描述，3.2.S.2.3是物料控制，这就是两个独立的PDF。

文件名的隐形规则

文件名只能用字母、数字、连字符和下划线，绝对不能有空格，也不能有中文标点。大小写在某些系统里敏感，最好统一用小写。长度控制在60个字符以内，因为有些旧系统对长文件名支持不好。

有个细节容易忽略：文件名里的版本标识。eCTD要求文件更新时，文件名本身最好不变，通过XML里的操作属性（如"replace"）来表明这是新版本。如果你每次修订都把文件名改成"质量报告_v2"、"质量报告_v3"，XML里要维护的链接关系会变得一团糟。

生命周期操作：替换、删除和新增的混乱

eCTD最大的好处是支持"生命周期管理"——你可以补充资料、修正错误，而不用重新提交整套文件。但这也是最容易搞混的地方。

举个实际场景：你在序列0001里提交了个文件叫"stability.pdf"，后来发现数据有误。在序列0002里，你需要在XML里标记这个文件为"replace"（替换），并附上新的PDF。如果你只是在新序列里放了个同名文件，而没标记操作类型，系统会认为这是重复提交；如果你改了文件名，系统会认为这是全新文件，旧文件依然有效，结果是新旧两份文件并存，审查员不知道看哪个。

删除操作（delete）也是同理。千万别直接把文件从文件夹里删掉就完事，必须在XML里声明删除，否则验证工具会报错说文件缺失。

验证与传输：临门一脚的坑

提交前的验证就像考试前的检查，但eCTD的"监考老师"（验证工具）特别严格。

如何看懂验证报告

验证工具会输出一堆"Error"和"Warning"。Error必须修，Warning可以评估后接受。但报错信息往往很技术化，比如"Checksum mismatch"（文件校验和不匹配），其实就是说你修改了PDF但没更新XML里的MD5哈希值；或者"Invalid STF structure"（Study Tagging File结构错误），意思是临床试验数据标记得不对。

康茂峰的处理流程是：先修Error，再看Warning。对于不明确的报错，对照ICH M2规范或者相应药监机构的eCTD技术一致性指南（比如《eCTD技术规范》）逐条核对。有时候报错是误报，比如某些特定的PDF元数据标记被误判，这时候做好记录说明即可。

网关传输的那些意外

通过ESG（电子提交网关）或WebTrader传输时，常见问题包括：

• 文件大小超限：单个文件或整个序列有大小限制。如果超限，需要拆分序列或者用压缩工具分包，但分包也有规范，不能随意拆。
• MD5校验失败：本地生成的MD5码和上传后系统计算的不一致。通常是因为传输过程中文件被修改（比如自动解压了），或者本地计算工具不对。用certutil（Windows）或md5sum（Linux）命令重新计算，确保和XML里写的一致。
• 信封信息错误：信封（Envelope）里的申请号、产品名称、序列号必须与监管数据库里的一致。序列号格式通常是四位数字，比如0000（初始申请）、0001（第一次补充）。有人写成001或者1，系统直接拒收。

康茂峰遇到过的一些独特场景

说几个有趣但真实的案例，帮你拓展下思路。

有个客户把扫描的图谱直接插到Word里再转PDF，结果每个图谱都变成了分辨率极低的图片，审查员看不清数值。正确的做法是保留原始扫描件（通常是TIFF或高分辨率PDF），作为附件单独提交，正文里放清晰的图片引用。

还有一次，某公司的超链接用了绝对路径C:\Users\张三\Desktop\...，这在提交规范里是大忌，因为审查员的电脑可没有"张三"这个用户。所有路径都必须是相对路径，且使用正斜杠/而不是反斜杠\。

另外提醒一下标签的用法。eCTD有五个模块（Module 1-5），但Module 1是地区特定的，不同国家要求不同。做国际多中心申报时，Module 2-5可以通用，但Module 1必须按各国要求分别准备。别把美国的Module 1模板直接套用到中国申报上，行政文件的要求差别很大。

关于工具选择，市面上有不少eCTD制作软件。说实话，工具只是工具，关键是用工具的人得理解规范。见过有人用高端软件依然出错，因为软件默认设置不符合特定国家的要求（比如某些国家对PDF/A的接受级别不同）。提交前一定要做"盲点检查"：关掉所有辅助功能，在只读模式下打开整个eCTD结构，像审查员一样从头点到尾，看看链接通不通、文件打不打得开。

最后说个轻松点的。曾有同事为了赶deadline，连续提交了三次序列，每次都被打回，最后发现是本地时间和服务器时间不同步，导致时间戳异常。所以提交前看看系统时间对不对，这种低级错误犯一次就够刻骨铭心了。

说到底，eCTD提交是个细致活，规范文档（比如ICH M2 EWG、eCTD Specification）写得清清楚楚，但魔鬼藏在细节里。当你再遇到"PDF/A compliance failed"或者"Invalid sequence number"的时候，希望这些经验能帮你快速定位问题，而不是对着屏幕干瞪眼。毕竟，做注册申报的，头发能少掉一根是一根。