2、PDB文件格式详解：标准PDB格式、常见字段说明、异常格式识别
PDB格式，说白了就是蛋白质结构的「身份证」。每个原子、每条链、每个残基的信息都写在里面。我刚开始接触PDB文件时，被那些固定列宽搞得一头雾水——为什么第13列必须是空一格？为什么原子名不能多写一个字母？后来踩了不少坑才明白，这些规则不是无缘无故的。你想想看，一个文件动辄几万行，如果每行格式不统一，解析器根本没法正常工作。
这一章我会带你彻底看懂PDB文件。从标准格式到每个字段的用途，再到怎么一眼认出格式异常的文件。我的习惯是，拿到一个PDB文件先做三件事：看头部、数原子、检查残基序号。下面我们就从最基础的说起。
2.1 标准PDB格式概览
每个PDB文件都是由若干行文本组成的。每行80个字符，行首是记录类型（Record Type），比如 ATOM、HETATM、TER、END。我记得曾经处理过一个来自早期结构生物学的文件，它只有72列，因为当时存储介质限制。现在标准规定80列，多出来的列要么补空格，要么用来说明可选的扩展信息。
| 记录类型 | 说明 | 必需/可选 |
|---|---|---|
| HEADER | 文件头，包含结构名称、实验方法、沉积日期 | 必需 |
| TITLE | 标题行，描述结构内容 | 必需 |
| COMPND | 化合物信息，包括分子名、链标识 | 必需 |
| SOURCE | 来源生物体、表达系统等 | 可选 |
| KEYWDS | 关键词 | 可选 |
| EXPDTA | 实验方法，如X-RAY DIFFRACTION | 必需 |
| REMARK | 备注，包含精化统计、赝原子等 | 可选 |
| ATOM | 标准氨基酸/核酸原子坐标 | 必需 |
| HETATM | 非标准原子（配体、水、修饰基团） | 可选 |
| TER | 链终止标志 | 必需 |
| END | 文件结束 | 必需 |
核心规则：每个ATOM/HETATM行必须严格遵循固定列宽格式，从第1列到第80列，每个字段的位置都不能错。一旦偏移，解析器就会把原子序号当成坐标，或者把坐标当成残基名——后果很严重。
2.2 ATOM记录字段详解
ATOM行是最常用的。它的格式如下（列号从1开始）：
COLUMNS DATA TYPE FIELD DEFINITION
-------------------------------------------------------------
1 - 6 Record name "ATOM "
7 - 11 Integer serial Atom serial number.
13 - 16 Atom name Atom name.
17 Character altLoc Alternate location indicator.
18 - 20 Residue name resName Residue name.
22 Character chainID Chain identifier.
23 - 26 Integer resSeq Residue sequence number.
27 AChar iCode Code for insertion of residues.
31 - 38 Real(8.3) x Orthogonal coordinates for X.
39 - 46 Real(8.3) y Orthogonal coordinates for Y.
47 - 54 Real(8.3) z Orthogonal coordinates for Z.
55 - 60 Real(6.2) occupancy Occupancy.
61 - 66 Real(6.2) tempFactor Temperature factor.
73 - 76 LString(4) segID Segment identifier (obsolete).
77 - 78 LString(2) element Element symbol.
79 - 80 LString(2) charge Charge on the atom.这里最容易出问题的是原子名（Atom name）的对齐方式。比如Cα（alpha碳）要写成“ CA ”，前面一个空格，中间CA，后面补一个空格；而Cβ（beta碳）则是“ CB ”。我见过一个错误：有人把Cα写成了“CA ”，少了一个前导空格，结果解析器把“CA”当成了碳和铝，完全乱套。嗯，要特别留意这个。
还有，occupancy和tempFactor。大多数结构文件会把occupancy设为1.0，但当你处理多构象或无序结构时，会有部分占据（比如0.5）。我个人习惯在修复流程里先检查所有ATOM的occupancy是否都在0~1之间，如果出现负数或大于1，就得标记异常。
| 字段 | 常见值 | 异常示例 | 解析影响 |
|---|---|---|---|
| serial | 1,2,3,… | 负数、0、重复编号 | 原子索引错乱，无法按序处理 |
| atom name | CA, CB, N, O, C | "CA " 少空格、"CA " 多空格 | 元素符号识别错误 |
| resSeq | 1,2,… 或 -1, 100A | 字符串混入数字、缺失 | 残基顺序错位 |
| occupancy | 1.00 | -0.5, 1.23, 空白 | 精化计算异常 |
| tempFactor | 0~100 | 9999.99, -1.0 | 结构质量评估失真 |
2.3 异常格式识别——我的避坑指南
光看懂标准格式还不够，实际工作中你遇到的PDB文件十有八九都有点“毛病”。到底哪些算异常？我曾经把这些情况归纳成三类：
- 结构异常——列号偏移、字段缺失、记录类型拼写错误。
- 语义异常——原子名不符合IUPAC命名、残基名不存在、链标识超出字母范围。
- 数值异常——坐标超出合理范围（比如x > 1000）、occupancy为0但温度因子很大。
小技巧：拿到一个PDB文件后，先用 grep -c 统计ATOM行数，再用简单的Python脚本检查每行长度是否为80。如果大量行长度不对，就说明这个文件不是标准格式——可能是从其他格式（如mmCIF或旧版PDB）转换来的。
我分享一个真实案例。有次我处理一个来自PDB数据库的早期结构文件（1BNA），发现ATOM行居然是72列格式。原来是1980年代发布的版本，后来PDB格式更新到80列后，部分仓库没有重新格式化。如果不做列宽检查直接解析，坐标直接错位，后面的精修全部白费。
2.4 如何快速识别异常格式
在开始自动化修复前，先手动看几个关键点：
- 行首记录类型：检查前6个字符是否为大写字母+空格，比如“ATOM ”、“HETATM”。如果有“ATOM ”（少一个空格），那么后面的字段都会错位。
- 第13列：原子名的第一个字符位置。标准是第13列，如果这里出现了数字或标点，那原子名格式就有问题。
- 第31、39、47列：坐标x,y,z的起始位置。这些列应该是数字或者空格（如果值是负数则包含负号）。如果出现了字母，一定是格式跑偏了。
- 第55、61列：occupancy和tempFactor。这两个字段通常为实数，如果出现“1.00”但occupancy列里写了“1.000”，长度就超了6列，后续字段可能会被吃掉。
我建议在修复流程的第一步，就用脚本来做这些检查。下面是一个简单的Python检查片段：
def check_pdb_format(pdb_file):
errors = []
with open(pdb_file) as f:
for line in f:
if line.startswith(("ATOM ", "HETATM")):
if len(line.rstrip()) < 80:
errors.append(f"Line length {len(line.rstrip())} < 80: {line[:10]}")
# 检查坐标是否可解析
try:
x = float(line[30:38].strip())
y = float(line[38:46].strip())
z = float(line[46:54].strip())
except ValueError:
errors.append(f"Coordinate parse error: {line[:30]}")
return errors注意，这里用了 line[30:38] 而非 line[31:38]，因为Python索引从0开始。很多新手在这里翻车，你以为的列25在代码里是24。所以写代码的时候，最好把PDB的列号对照表贴在屏幕旁边。
2.5 PDB文件结构全视图
为了让你对整个PDB文件有一个整体把握，我画了一张结构图。你可以看到文件从上到下依次是头部信息、坐标记录和结束标记。以及各个记录类型之间的依赖关系。
特别警告：不要以为从PDB数据库下载的文件就一定标准。我替人修结构时，遇到过官方文件里出现非打印字符、空行缺失、甚至是二进制污染。所以无论在哪个环节，都要带上格式检查的滤网。
总结一下，看懂PDB文件格式是结构修复的基础。标准格式的80列规则虽然死板，但它保证了跨工具的兼容性。常见字段里，原子名和坐标位置最容易犯错。异常格式的识别，有经验的人一眼就能看出来——当你看到ATOM行第13列是字母或数字时，心里就有数了。下次拿到一个PDB文件，你可以先做我前面说的三件小事：看头部、数原子、检查残基序号。养成习惯，后面修复流程会顺畅很多。