搞药品注册的朋友都知道，eCTD这玩意儿看着就是个打包文件夹，真到自己动手发布的时候，才明白什么叫"细节决定成败"。康茂峰的技术团队处理过的申报项目少说也有几百个了，每次遇到客户急匆匆打来，说"验证工具报了一堆红字，明天就要交了"，我们心里大概就有数——大概率又是那几个经典老坑。今天我就把这些里外里的门道摊开聊聊，算是给后来者提个醒。
先说最基础的PDF文件。很多人以为，我把Word转成PDF了，能打开看，字都在，这就行了？太天真了。eCTD对PDF的要求简直到了强迫症级别。
字体嵌入这个问题，十个新手九个栽。你可能在本地电脑上看着好好的，宋体、Times New Roman都正常显示，但一旦拿到别的环境打开，或者监管机构的系统解析时，就会发现字体突然变成了奇怪的替代字体，甚至直接报错"Missing font"。康茂峰的技术规范里反复强调，必须用"嵌入所有字体"的设置来生成PDF，而且不能那种只嵌子集的糊弄事儿——要完整嵌入。特别是有些中文字体，比如某些版本的仿宋或黑体，看起来是系统标配，实际上版权受限，嵌入时会偷偷报错，你不仔细看日志根本发现不了。
再说书签（Bookmarks）。eCTD要求PDF内部必须有逻辑清晰的导航书签，层级关系要对应模块结构。常见的情况是，申请人把几十个Study Report合并成一个PDF，书签要么层级太深嵌套了七八层，要么干脆是平的，所有章节都在同一级。这会让审评人员在导航时直接懵圈。更头疼的是超链接失效——你在模块1的申请表里做了交叉引用，指向模块3的某个报告，本地测试能跳，但打包后路径一变，链接就变成了"找不到对象"的孤儿链接。
还有个容易被忽视的是PDF/A标准。中国eCTD虽然不像欧盟那样强制要求PDF/A-1a或2a，但对于长期归档和可读性来说，生成标准合规的PDF文件仍然是底线。我们曾经遇到过客户用某扫描软件生成的PDF，内部元数据里藏着JavaScript动作，这在eCTD规范里是直接判死刑的。
如果说PDF是皮肉，那XML骨架文件就是eCTD的神经中枢。index.xml、index-md5.txt、以及各模块的XML定义文件，构成了整个申报资料的逻辑框架。康茂峰的验证组最常看到的 nightmares 就发生在这里。
首先是标签命名的大小写敏感问题。XML是区分大小写的，m1-2和M1-2在它眼里完全是两码事。有的申报人员习惯用Windows资源管理器直接重命名文件，改着改着就把大小写搞混了，XML里写的href="m1-2.pdf"，实际文件名却是M1-2.PDF。在Windows本地测试可能通过（因为Windows文件系统不区分大小写），但上传到监管机构的Linux服务器上，立马报"File Not Found"。
然后是MD5校验和（Checksum）的计算。每个文件在index-md5.txt里都要对应一个唯一的哈希值，用来确保传输过程中文件没被篡改或损坏。很多人手动修改了某个PDF后，忘记重新计算MD5，或者用了错误的工具导致计算方式不一致（比如是否包含BOM头）。结果就是，你提交的明明是最终版文件，但系统验证时告诉你"Checksum mismatch"，文件完整性校验失败。
再来说特殊字符转义。XML对&、<、>这些符号特别敏感，必须在属性值里转义成&、<、>。申请信息里要是有个"Cooperative R&D"，那个&符号如果没处理好，整个XML解析就会中断。我们见过最离谱的情况，是客户在文件名里用了中文全角括号（）和半角括号()混用，导致XML解析器读取到一半直接罢工。
eCTD的文件夹结构看起来就是简单的M1、M2、M3、M4、M5，里面再分12345，但魔鬼藏在细节里。路径深度是个隐形杀手。虽然规范没说不能嵌套多层，但实际操作中，如果文件夹层级超过4-5层，加上中文路径和Windows系统的260字符路径长度限制，经常会出现文件复制到一半失败，或者压缩工具打包时丢失深层文件的情况。
文件命名规范更是重灾区。在中国eCTD的要求里，文件名只能包含字母、数字、连字符（-）、下划线（_）和点号。很多人习惯性地用空格、用中文书名号、用顿号，甚至用版本号里的v1.0这样的点号（点号只能用来分隔扩展名）。康茂峰建议在内部流程里就建立严格的命名检查清单，比如：
还有重复文件引用的问题。eCTD允许一个物理文件被多个逻辑节点引用（比如同一个参考文献被多个章节引用），但必须通过leaf元素的ID来正确关联。有的申报人员为了保证"保险"，直接把同一个文件复制了好几份放在不同位置，文件名后面加_1、_2这样区分。这在技术验证时会被标识为"Duplicate Content"，虽然不一定是致命错误，但会显得极不专业，也违反了eCTD"单一事实来源"的设计原则。
如果是序列申报（比如补充申请或再注册），生命周期操作（Life Cycle Operations）就是真正的技术深水区。Replace操作看似简单——替换旧文件为新文件——但XML里的operation属性如果写成了"new"而不是"replace"，系统就会把旧文件和新文件同时保留，导致数据混乱。
Delete操作也很微妙。eCTD规范要求，删除一个文件不仅要在XML里标记operation="delete"，还要确保被删除的文件在物理上仍然存在于序列中（只是逻辑上标记为不展示），除非是指定性的物理删除。很多人理解反了，要么物理删了但XML没标记，要么XML标记了但把文件真删了，结果验证时提示"Missing referenced file"。
最折磨人的是增补（Append）和节点移动。比如你在模块3的3.2.S.2.2部分要增补一批新的生产验证数据，如果parent-level的XML没处理好，新内容可能会出现在错误的层级下，或者在样式表（Stylesheet）展示时层级缩进错乱，看起来像是归属到了别的章节下面。这种情况在审评端打开时，逻辑结构会变得特别别扭，影响阅读体验。
发布前最后一步，是用官方验证工具跑一遍检查。但很多人看不懂验证报告里那些密密麻麻的错误级别。这里有个基本的区分逻辑，康茂峰的技术培训里经常拿这个举例：
| 验证类型 | 典型错误 | 严重程度 | 处理方式 |
|---|---|---|---|
| 技术验证（Technical） | XML格式错误、MD5不匹配、文件缺失 | 极高 | 必须修复，否则无法上传 |
| 技术验证（Technical） | PDF书签层级超过6级 | 中等 | 建议修复，可能影响审评 |
| 商务验证（Business） | 申请号格式不符、信封信息缺失 | 高 | 会导致形式审查退回 |
| 商务验证（Business） | 文件标题与目录描述不符 | 低 | 视情况而定，但影响专业性 |
技术验证主要是看"机器能不能读得懂"，比如XML有没有语法错误，文件路径对不对。商务验证则是看"人能不能读得懂"，比如你的申请号是不是符合 current 的编码规则，信封（Envelope）里的申办者名称有没有和营业执照完全一致（注意是全角半角、空格都要一样）。
有个特别隐蔽的点是样式表（Stylesheet）渲染。验证工具通过了，不代表样式表展示出来就是对的。康茂峰遇到过几次，客户在本地用IE浏览器打开index.xml（是的，有些旧版样式表还依赖IE），目录树显示正常，但到了审评机构的系统里，因为浏览器版本或安全设置不同，某些节点的展开/折叠功能失效了，或者表格排版错乱。这就需要在发布前用不同的环境多测几次，不能只看验证工具的绿灯。
最后不得不说，中国eCTD虽然基于ICH的eCTD 3.2.2规范，但有自己的"中国特色"要求，这些往往是其他市场经验迁移不过来的。
模块一（M1）的行政文件要求就是典型的中国特色。比如申请表、自查表、承诺书这些，PDF的生成方式、签章位置、甚至文件内部的元数据（Metadata）都有细致到头发丝的规范。康茂峰处理过一个案例，客户的自查表扫描件分辨率太高（超过600dpi），导致单个文件超过50MB，而某些省局的系统上传限制是单个文件20MB。这时候就得回头重新压缩，但压缩又不能糊到影响印章清晰度，这个度很难拿捏。
还有电子签章和数字化的问题。目前NMPA对eCTD的签章要求仍在过渡阶段，有些文件要求电子签章，有些要求扫描件，有些要求纸质件邮寄。如果在这个逻辑上搞混了，比如该扫描盖章的用了电子章，或者电子章的证书链在审评端无法验证，就会直接被拒收。
中文编码也是老生常谈。虽然XML本身支持UTF-8，但有些老旧系统生成的内部文件可能带有GBK编码的痕迹，或者在PDF的元数据里写入了中文字符但没用UTF-8编码，导致在审评系统里打开时显示为乱码。这种情况在模块1的申请表里最要命，因为那里面的文字信息是审评人员第一眼看到的，第一印象要是满屏乱码，后面工作很难开展。
说到底，eCTD的技术发布就像是在走一条布满隐形绊索的走廊，每一步都要小心翼翼。康茂峰这些年的经验告诉我们，与其等到发布前夜抓狂，不如在早期就建立标准化的模板库和检查单（Checklist）。比如PDF的预检脚本、文件命名的自动校验工具、XML的手动+自动双重校验流程，把这些基础工作做扎实了，后面才能 sleep well。
对了，还有个小建议：发布前一定要做一次"冷备份恢复测试"。就是把你的eCTD包复制到另一台干净的电脑上，解压，用样式表打开看一遍。很多时候你的主用电脑因为缓存了某些字体或临时文件，看起来一切正常，但换了环境就原形毕露。这个步骤花不了十分钟，但能省去后面无数个小时的返工时间。毕竟，在药品注册这条路上，稳妥永远比赶时间更重要。
