4. 输出格式解析：从TSV到JSON的字段密码
拿到InterProScan结果，第一眼看到的是什么？一堆文件。
TSV、GFF3、XML、JSON，四种格式摆在你面前。新手常问：「我该用哪个？」
我的回答是：都学一遍。因为每个格式都有自己的战场，选错了后面全是坑。
4.1 TSV/CSV：轻量级表格，人类友好
这俩是最直观的格式。一行一条记录，列用制表符或逗号隔开。
我个人习惯用TSV，因为基因ID和描述里偶尔会带逗号，用TSV省心。
先看一个真实输出的表头结构：
# InterProScan 5.63-95.0
# Job ID: job_20250201_001
# Sequence: Seq_001
# MD5: a1b2c3d4e5f6...
# Length: 450
# Analysis: InterProScan
# Database: Pfam,PRINTS,SUPERFAMILY,ProSiteProfiles,ProSitePatterns,SFLD,Gene3D,Hamap,Coils,PANTHER
# 1. 序列ID 2. MD5 3. 序列长度 4. 分析数据库 5. 签名访问号
# 6. 签名描述 7. 起始位置 8. 终止位置 9. 得分 10. 状态
# 11. 日期 12. InterPro访问号 13. InterPro描述 14. GO注释
# 15. 通路注释
Seq_001 a1b2c3... 450 Pfam PF00001 7tm_1 35 310 1.2E-45 T 2025-02-01 IPR000276 G protein-coupled receptor
GO:0004930|GO:0007186 REACT_1234大家注意第14列和第15列。GO注释是以竖线分隔的，通路注释是逗号分隔的。我踩过这个坑——写脚本解析时没考虑多值字段，结果丢了很多信息。
关键字段快速对照表：
| 列序号 | 字段名 | 说明 |
|---|---|---|
| 1 | 序列ID | 匹配到数据库的序列标识 |
| 4 | 分析数据库 | 例如 Pfam、PANTHER 等 |
| 5 | 签名访问号 | 数据库内部ID，如 PF00001 |
| 12 | InterPro访问号 | 跨数据库统一ID，如 IPR000276 |
| 14 | GO注释 | 多个GO用竖线分隔 |
TSV最大的优点是能直接丢进Excel。快速浏览、筛选、画个柱状图都非常方便。
4.2 GFF3：基因组的结构语言
GFF3是基因组领域的老大哥。InterProScan用它输出域结构注释，说白了就是给每条序列画一张「功能域地图」。
看一个GFF3片段就懂了：
##gff-version 3
##sequence-region Seq_001 1 450
Seq_001 InterProScan mobile_genetic_element 1 20 . + . ID=mge00001;Name=REP_1
Seq_001 InterProScan protein_match 35 310 1.2E-45 + . ID=pfam00001;Name=7tm_1;DbXref=InterPro:IPR000276
Seq_001 InterProScan similarity 200 250 5.6E-12 + . ID=sim00001;Target=SUPERFAMILY:SSF12345 200 250GFF3有九列，固定格式。我刚开始做的时候，老记不住第九列是属性列，里面可以放一大堆东西，用分号隔开。
| 列号 | 字段 | 说明 |
|---|---|---|
| 1 | seqid | 序列ID |
| 2 | source | 固定为 InterProScan |
| 3 | type | 特征类型：protein_match、domain、repeat 等 |
| 4-5 | start, end | 匹配到的起始/终止位置 |
| 6 | score | E-value 或位分值 |
| 7 | strand | 链方向，蛋白质通常为 + |
| 8 | phase | 阅读框，蛋白质注释用 . |
| 9 | attributes | 包含 ID、Name、DbXref 等 |
避坑指南：GFF3的第九列属性解析最容易被忽略。我曾经因为没解析 DbXref 字段里的 InterPro ID，绕了一大圈去数据库查冗余信息。
4.3 XML：结构化但庞杂
XML格式非常完整，但也非常重。内容很详细，适合做深度的跨数据库交叉查询。
下面是我提取的一个XML关键片段：
<protein>
<protein_seqid>Seq_001</protein_seqid>
<length>450</length>
<matches>
<match>
<database>Pfam</database>
<signature_ac>PF00001</signature_ac>
<locations>
<location>
<start>35</start>
<end>310</end>
<score>1.2e-45</score>
</location>
</locations>
<interpro_ac>IPR000276</interpro_ac>
<go_terms>
<go_term>GO:0004930</go_term>
</go_terms>
</match>
</matches>
</protein>XML里 <locations> 和 <annotation> 是嵌套的，层级很深。如果你打算解析XML，我建议直接用Python的 ElementTree，别自己写字符串切割。
不过说真的，大部分时间我们并不需要全部字段。XML里有的信息TSV里基本都有。只有在需要做多对多关联的时候，XML的树形结构才显示出优势。
4.4 JSON：现代管道的最佳搭档
如果你写Python或者JavaScript做进一步分析，JSON是不二之选。
嗯，这里注意看JSON的数组结构：
{
"seqid": "Seq_001",
"length": 450,
"matches": [
{
"database": "Pfam",
"signature_ac": "PF00001",
"locations": [
{
"start": 35,
"end": 310,
"score": 1.2e-45
}
],
"interpro_ac": "IPR000276",
"go_terms": ["GO:0004930", "GO:0007186"]
}
]
}JSON的好处就是键值对清晰，容易遍历。不像GFF3那样还得解析字符串。而且不冗余，相比XML少了将近一半的字符，网络传输快很多。
你可能会问：既然JSON这么好，为什么还要学其他格式？
因为下游工具只认特定的格式。比如做基因组浏览器的，就要GFF3。做统计分析批量处理的，就要TSV。做自动化管道的，JSON最顺手。
4.5 四种格式的横向对比
我把各格式的特点和适用场景整理成一个表，方便你回顾：
| 特点 | TSV/CSV | GFF3 | XML | JSON |
|---|---|---|---|---|
| 人类可读性 | ★★★★★ | ★★★★☆ | ★★☆☆☆ | ★★★★☆ |
| 机器可读性 | ★★★★☆ | ★★★☆☆ | ★★★★★ | ★★★★★ |
| 典型行数 | 多行并列 | 多行并列 | 单行嵌套 | 单行嵌套 |
| 多值字段 | 分隔符拼接 | 第九列属性 | 子元素 | 数组 |
| 推荐使用 | 初步浏览、Excel分析 | 基因组浏览器集成 | 深度交叉查询 | 管道自动处理 |
4.6 格式枢纽：数据流的十字路口
看到这张图了吗？四种格式就像四条分叉路。你要去哪个目标，就选哪条路。
4.7 我的一点经验之谈
最后，说说我自己的选择标准：
- 快速看看结果长什么样 → 用TSV，直接cat或less
- 给导师或审稿人提交数据 → 附一份TSV，他随时能打开
- 搭建自动化流程 → 用JSON，Python的json模块一行搞定
- 做基因组可视化 → 用GFF3，IGV或JBrowse直接拖进去
- 批量跨库交叉查询 → 用XML，结构最严谨
我记得有一次搭建生产环境自动化管道时，团队里有人坚持只用TSV，结果解析GO注释时维度全拆开了。后来替换成JSON，问题迎刃而解。
你想想看，同样一份数据，四种语言。多学一种不亏，但选错一种，后面就全是补丁。改代码的痛，我太懂了。