Krona 数据格式介绍
你拿到了一个宏基因组样本。跑完了 blast，拿到了物种分类结果。然后呢？你想用 Krona 画个交互饼图，美滋滋地展示给导师看。
嗯，先别急着拖拽文件。Krona 能识别的数据格式有好几种。选错了，或者格式没对齐，轻则报错，重则画出来的图牛头不对马嘴。我见过不止一个新手，拿着 Excel 改的制表符文件往里塞，结果 Krona 直接吐一堆乱码节点。
这一讲，咱就把 Krona 的三种输入格式——文本、XML、JSON——掰开揉碎讲清楚。你以后碰到任何分类数据，都能一眼判断：该用哪种格式喂给 Krona。
Krona 的数据本质：层级和计数
先搞清楚核心逻辑。Krona 展示的是层级数据，说白了就是树形结构。根节点是“所有序列”，往下一层是“界”，再往下是“门”、“纲”、“目”、“科”、“属”、“种”。每个节点都有一个数值，叫“计数”，表示这个分类下有多少条序列。
所以，无论你用文本、XML 还是 JSON，传递给 Krona 的信息无非就是两样：
- 层级路径：从根节点到叶子节点的完整分类链。
- 计数：这条路径上的序列条数，或者相对丰度。
我个人习惯，先把这个树形结构在脑子里过一遍。你想想看，如果数据里出现了“细菌→变形菌门→γ-变形菌纲→肠杆菌科”，但计数是 0，Krona 会怎么处理？它会直接忽略这个空节点。所以，数据里的层次必须完整，计数必须正确。
三种格式速览
我整理了一个表格，你一眼就能看出来区别。
| 特性 | 文本格式（.txt/.tsv） | XML 格式（.xml） | JSON 格式（.json） |
|---|---|---|---|
| 可读性 | 非常好，随便一个文本编辑器就能看 | 一般，标签多，结构啰嗦 | 较好，结构清晰，比 XML 紧凑 |
| 文件大小 | 最小 | 最大（标签重复） | 中等 |
| 层级嵌套 | 靠制表符缩进表示 | 靠 XML 元素嵌套表示 | 靠 JSON 对象嵌套表示 |
| 元数据支持 | 几乎不支持，只能写路径和数值 | 强，可以塞颜色、链接、描述 | 中等，可以塞基本属性 |
| Krona 原生支持 | ktImportText 直接导入 | ktImportXML 直接导入 | ktImportJSON 直接导入 |
| 我推荐的场景 | 快速出图、数据量小时 | 需要精确控制样式时 | 程序化生成、数据量较大时 |
文本格式：最常用，但最容易被坑
文本格式是 Krona 的“默认语言”。它的结构极其简单：每一行代表一条分类路径，层级之间用制表符缩进。注意，是制表符（Tab），不是空格。很多人在 Excel 里生成文件，默认用的是空格对齐，拿到 Krona 里直接报错。
我曾经在项目里接过一个合作者的数据，他用空格对齐了层级，我折腾了半天才发现问题。
正确的文本格式长这样：
root 1000
root Bacteria 800
root Bacteria Proteobacteria 500
root Bacteria Proteobacteria Gammaproteobacteria 300
root Bacteria Proteobacteria Gammaproteobacteria Enterobacteriaceae 200
root Bacteria Firmicutes 200
root Eukaryota 150
root Eukaryota Chordata 80
root Eukaryota Chordata Mammalia 50
root Viruses 50看这例子。第一列是“root”，这是必须的根节点名。每个制表符代表一层缩进。最后一列是计数，这个数字可以是整数，也可以是浮点数（比如相对丰度 0.05）。
我曾经因为没注意“root”的大小写，导致 Krona 画出来的图有一个孤立的“root”节点，看着特别奇怪。Krona 默认把“root”作为根节点名称，你要么老老实实写“root”，要么在命令行里用
-r 参数指定其他名称。
另一个坑：空白行。文本格式里如果出现了空行，Krona 会直接忽略后面的行，导致数据丢失。所以写脚本导出数据时，一定要记得过滤掉空行和注释行（以 # 开头的行）。
XML 格式：强大，但写起来太累
XML 格式是 Krona 的“高级模式”。它允许你对每个节点进行精细的样式控制，比如设置节点颜色、添加超链接、附上描述文字。但代价是，你得写一大堆标签。
一个典型的 Krona XML 文件结构如下：
<?xml version="1.0" encoding="UTF-8"?>
<krona>
<attributes>
<attr name="totalCount">1000</attr>
</attributes>
<node name="root">
<node name="Bacteria">
<node name="Proteobacteria">
<node name="Gammaproteobacteria">
<node name="Enterobacteriaceae">
<val>200</val>
</node>
</node>
</node>
</node>
<node name="Eukaryota">
<node name="Chordata">
<val>80</val>
</node>
</node>
</node>
</krona>注意看，每个层级的嵌套是通过 <node> 标签的层级关系实现的。计数写在 <val> 标签里。根节点的名字依然在 <node name="root"> 里。
XML 最实用的场景是给节点上色。比如想突出显示“Enterobacteriaceae”为红色，可以在
<node> 里加 color="#e74c3c" 属性。但说真的，手写 XML 太痛苦了，我建议你通过程序自动生成，或者直接用 Krona 自带的参数来染色。
JSON 格式：程序员的宠儿
JSON 格式是 Krona 的“中间路线”。它比文本格式结构性强，比 XML 格式简洁。如果你是用 Python 或者其他脚本语言处理数据，生成 JSON 是最自然的选择。
JSON 格式的本质是一个多层嵌套的字典。每个节点包含 name（节点名）、children（子节点列表）和可选的 size（计数）。看例子：
{
"name": "root",
"children": [
{
"name": "Bacteria",
"children": [
{
"name": "Proteobacteria",
"children": [
{
"name": "Gammaproteobacteria",
"children": [
{
"name": "Enterobacteriaceae",
"size": 200
}
]
}
]
}
]
},
{
"name": "Eukaryota",
"children": [
{
"name": "Chordata",
"size": 80
}
]
}
],
"size": 1000
}你发现没？JSON 里每个节点都可以有 size 字段。Krona 会从叶子节点向上聚合计数。如果你只给叶子节点设置了 size，它会自动把父节点的计数加起来。这比文本格式灵活得多。
文本格式的缩进层级数决定了分类深度，JSON 格式的嵌套层级数决定了分类深度。相同的逻辑，不同的表达。但 JSON 格式天然支持更复杂的数据结构，比如可以在
children 里动态添加属性。
格式之间的选择建议
我给你一个我自己的决策流程：
- 如果数据量小于 1 万行，且不需要特殊样式：直接用文本格式。简单，快，不出错。
- 如果数据从脚本或管道生成：用 JSON。Python 的
json.dumps一行就能搞定。 - 如果你需要为不同分类设置不同颜色：用 XML。Krona 的 XML 格式对颜色支持最好。
- 如果数据来源是数据库，字段本身是树形结构：优先用 JSON，因为大多数数据库的 API 返回的就是 JSON。
下面这张图总结了三种格式与 Krona 工具的对应关系：
一个实操小技巧
如果你不确定自己的数据格式对不对，可以用 Krona 自带的 ktCheck 命令做一个快速校验。你想想看，如果数据有几百兆，跑一遍 ktImport 可能要等几分钟。但 ktCheck 几乎瞬间就能告诉你格式是否有误。
我自己的流程是：写脚本 → 导出数据 → ktCheck 验证 → 确认无误 → ktImport 生成报告。这一步看似多余，但曾经帮我抓出过不少笔误。
Krona 自带一个
ktClassify 工具，可以根据输入的 blasthit 文件自动生成文本格式数据。如果你手头只有原始比对结果，不妨先用它做一步预处理。
三种格式，各有千秋。文本格式上手最快，JSON 格式程序最友好，XML 格式控制最精细。选哪一种，取决于你的数据来源和后续需求。但有一件事是不变的：数据必须构成一棵完整的树，每个节点必须有合理的计数。记住了这点，Krona 就能为你所用。