做注册申报这行久了，你会发现eCTD这东西挺有意思的——表面上就是个电子文档打包提交，看起来就是把PDF塞进文件夹里的事儿，但实际上手的时候，那些技术细节能把人折腾得够呛。我们康茂峰的技术团队在支持客户做eCTD出版的过程中，几乎把能遇到的坑都踩了一遍。今天想聊点实在的，不说那些官方文档里的标准套话，就说说真正提交前夜让你睡不着觉的那些技术难点。
说实话， most people 觉得PDF是最没技术含量的格式，毕竟谁没用过PDF呢？但在eCTD的世界里，PDF简直就是个挑食的主儿。
最常见的翻车现场就是字体嵌入。你可能在Word里看着好好的宋体、Times New Roman，转成PDF后在自己电脑上打开也正常，但一上传到验证工具就报错——"Font not embedded"。这事儿诡异之处在于，有些字体明明是你系统自带的，按理说应该随文件走，但eCTD要求的是所有字体必须100%嵌入，包括那些你根本注意到的子集字体。
更麻烦的是中文字体。有些申报资料里必须出现中文商品名或者中文说明，这时候如果用了某些特殊中文字体，嵌入后文件体积会暴增，可能从2MB直接飙到20MB。康茂峰遇到过最极端的案例，一个 stability report 因为用了某款艺术字体的中文标题，结果整个模块的传输都成问题。这时候你就得权衡——是坚持美观还是改为标准字体保平安。
然后是PDF/A归档标准的问题。eCTD普遍要求PDF/A-1a或者PDF/A-1b，但这两个标准对图层的处理很严格。如果你的PDF是从扫描件转过来的，或者中间经过某些设计软件处理，可能会残留一些透明的图层或者注释层，这在普通阅读器里看不见，但验证工具能识别出来并判定为不合规。
有个小窍门可能有用：别直接用"打印成PDF"这种方式生成最终文件，虽然这样通常能强制嵌入字体，但往往会丢失标签结构（tagged structure）。而PDF/A-1a要求文档必须有逻辑结构标签，这是为了无障碍阅读考虑的。康茂峰的建议是，生成PDF后最好用专业的preflight工具先跑一遍，看清楚报错信息再决定是重新生成还是用PDF编辑器手动修复。
如果说PDF是 flesh，那XML backbone 就是 skeleton。很多人把精力都放在做漂亮的PDF上，结果在XML上栽跟头。
eCTD的XML必须符合特定的DTD（文档类型定义），这个验证很 rigid。最头疼的是某些属性值的大小写问题——比如有些地方要求写"new"，你写了个"New"，首字母大写了，XML解析器就认定这是个非法值。还有日期格式，必须是YYYY-MM-DD，如果你习惯了写2024/05/20，直接报错。
更隐蔽的是特殊字符转义。申报资料里经常会出现化学式、数学符号，或者公司名里的&符号。这些在XML里都必须转义，比如&要写成&，小于号要写成<。康茂峰曾经处理过一个案例，客户的公司名称里带有个"&"符号，在PDF里显示正常，但在XML metadata里没转义，结果整个 backbone 文件解析失败，连带所有文件索引都乱了。
每个PDF文件在XML里都要有个 entry，这个 entry 的 href 属性必须精确指向文件名，包括大小写、空格、扩展名。Windows系统不区分大小写，所以你在本地测试时"File.pdf"和"file.pdf"都能打开，但上传到电子提交系统后，Unix-based的服务器是区分大小写的，链接就会断掉。
还有 leaf 节点的属性设置。比如 operation 属性，是新递交（new）、替换（replace）还是删除（delete）？这个配置错了，监管机构的系统就会误判你的操作意图。特别是做 lifecycle management 的时候，版本号（version）和替换序号的逻辑必须严丝合缝。
说到 lifecycle，这可能是很多从纸质申报转过来的同事最难适应的概念。纸质时代你要改个内容，重新印一页插进去就行；电子时代可不行，系统需要知道你到底想干什么。
Replace 和 Delete 的区别特别容易搞混。Delete 是把原来的文件彻底移除，而 Replace 是用新文件覆盖旧文件但保留历史记录。如果你本意是更新某个表格数据，用了 Delete 再 New，那历史版本链就断了；反之亦然。康茂峰建议在操作前画个流程图，明确每个文件的状态变迁。
还有 Append 操作，这个在增补资料时很常见，但要注意 append 的序号管理。比如某个 section 已经有 1.2.3 三个文件，你 append 一个 1.2.4，这没问题；但如果你 append 的是 1.2.3.1，这就涉及到层级结构是否合理的问题。有些地区的系统对文件编号连续性检查得很严，中间不能有空缺号。
内部超链接（internal hyperlink）是eCTD体验的核心，但也是技术故障的高发区。
最常见的是书签（bookmark）和链接目标的错位。你在PDF里创建了一个跳转到"Table 3"的链接，但目标位置可能因为分页调整而变了，或者书签层级（hierarchy）设置错误。eCTD规范通常要求书签层级不能超过五级，而且必须和文档的标题结构对应。如果文档里有六级标题，你就得想办法把它合并到五级里，或者调整文档结构。
外部链接（external link）也是个敏感话题。链接到官方网站、参考文献这些本来是为了方便审评员，但如果链接失效了（link rot），在有些严格的技术验证中会被标记为警告甚至错误。康茂峰的做法是，对于必须的外部引用，在提交前用工具批量检查URL有效性，同时准备一份说明文档解释每个外部链接的必要性。
Metadata 贯穿整个eCTD包，从 envelope 信息到每个文件的 attributes。申请编号（application number）、产品名称（product name）、申请人名称（applicant name）这些关键字段必须在所有地方保持一致。
这里的 consistency 包括大小写、空格、标点符号。比如你在 XML 的 envelope 里写的是"ABC Pharma Co., Ltd."，但在模块一的某些表格里写成了"ABC Pharma Co Ltd"（少了那个点），或者大小写不一致，系统就可能认为这是两个不同的实体。康茂峰内部有个 checklist，专门比对 envelope、XML attributes 和 PDF 页眉页脚的这些信息。
还有日期格式和时区问题。虽然eCTD标准规定用ISO 8601格式，但涉及到生成PDF的时间戳、系统日志时间等，不同软件默认设置不同，可能导致时间戳混乱。这在跨国提交时尤其麻烦，因为你得明确是基于哪个时区的时间。
-commercial validation 工具，比如某些主流的 eCTD validation software，它们的验证规则是基于各监管机构发布的最新规范，但规则更新往往比软件更新快，或者软件版本对规范的解读有细微差别。
最常见的报错是文件路径长度问题。Windows系统支持长路径，但某些 legacy 的验证工具或者提交门户只支持256字符以内的路径。如果你的文件夹嵌套很深，文件名又长，可能技术上文件没问题，但路径报错。
还有加密和安全设置。有些PDF在生成时默认设置了不允许打印、不允许复制文本，或者设置了打开密码，这在eCTD里是绝对禁止的。但问题是，这些限制在PDF的 security properties 里一目了然，可如果你是用某些自动化工具批量生成的PDF，可能会忘记检查这一项。
| 错误类型 | 常见原因 | 康茂峰的处理建议 |
| Font not embedded | 使用了系统字体未嵌入子集 | 生成PDF时强制嵌入所有字体，或使用PDF/A合规检查工具预处理 |
| Invalid XML structure | DTD不匹配或特殊字符未转义 | 用XML编辑器而非记事本编辑，严格遵循DTD的枚举值列表 |
| Bookmark hierarchy exceeds limit | 标题层级超过5级或逻辑混乱 | 调整文档结构，合并过细的子章节，或手动调整书签层级 |
| Hyperlink target missing | 链接指向的页码已变更或书签被删除 | 提交前进行全文档链接有效性扫描，特别关注交叉引用部分 |
| Metadata mismatch | 信封信息与文件内容不一致 | 建立主数据表（master data sheet），提交前进行三方比对 |
虽然ICH努力统一了eCTD的标准，但各个监管机构在执行层面都有自己的"方言"。比如模块一（Module 1）的内容和格式，各地区要求差异很大。同样的行政信息，在欧美亚不同地区的提交包里，XML的节点结构、必需的属性字段都可能不同。
还有文件命名规范。有些地方允许用下划线，有些必须用连字符；有些地方要求申请编号必须在文件名中，有些地方则禁止这样做以免泄露敏感信息。如果你用同一个 source 文件要生成不同地区的 eCTD 包，不能简单复制粘贴，必须针对每个地区的规范做本地化调整。
康茂峰的技术团队遇到过这种情况：一个全球同步申报的项目，在A地区顺利通过验证的文件，在B地区因为书签的打开状态设置（initial view）不符合当地习惯而被退回。A地区习惯打开文档显示书签面板，B地区要求默认隐藏书签面板只显示页面。这种细节在官方指南里往往不会写得那么细，但确实会导致技术 rej。
前面说的都是内容层面的，最后提一下物理层面的问题——文件大小。eCTD规范通常建议单个文件不超过一定的MB数（比如某些地区建议单个PDF不超过50MB），但现代申报资料里动辄高分辨率的色谱图、电镜照片、扫描的原始记录，很容易就把PDF撑爆。
压缩图片是个技术活儿，压太狠了审评时看不清细节，不压又超大小限制。还有分卷（split）策略，一个大的模块要不要拆分成多个文件？拆分点在哪里？是在章节边界拆，还是按页数硬拆？这些决策都会影响后续的 lifecycle 管理。如果第一次递交时把一个20MB的PDF拆成了两个，下次更新时你只更新了其中一部分，得确保索引关系正确指向。
传输过程中的 corruption 也是个大坑。FTP上传、光盘刻录、甚至是某些基于web的提交门户，在上传大文件时都可能出现bit error。最保险的做法是在本地先算好 checksum（通常是MD5或SHA-256），上传后再计算一次比对。康茂峰的内部流程里，这步是 mandatory 的，虽然麻烦，但比起提交后被发现文件损坏要好得多。
写到这儿突然想到，其实做eCTD就像搭乐高——每个积木（PDF）本身要结实，骨架（XML）要搭得稳，整体结构要符合图纸（DTD），还得考虑到审稿人（end user）拆开来查看时的体验。那些技术难点，说白了就是把纸质时代的"看得见摸得着"变成了数字时代的"看不见但必须严谨"。下次当你面对满屏幕的红色验证错误时，别慌，大概率就是上面提到的这些坑，一步一步排查，总能找到那根没接好的线头。
