ipfs dag get输出编码怎么选？

同一个CID可以被当作DAG节点、UnixFS文件入口或原始区块来观察，选择错误命令会得到“看似乱码”的正确数据。ipfs dag get适合查看IPLD表示和路径解析结果；它不是所有文件下载或字节级核验任务的通用替代品。

先决定你要看哪一层

ipfs dag get接受IPLD路径并解析返回对应节点。

输入可以是CID，也可以是从根节点继续解析的IPLD路径。路径解析会跟随链接到目标节点，因此结果不一定是根CID本身的结构。调试时先保存完整输入路径，再分别查看根节点和目标路径，避免把子节点内容误归到根。

命令支持—output-codec选择输出编解码器，默认使用dag-json。

dag-json把IPLD数据映射为可读JSON，其中链接和字节值有特定表示。它适合人工审阅和结构化处理，但不能用于证明原始块字节完全相同。做哈希或编码器回归时，应取得原始区块并按对应multicodec解码。

选择—output-codec前确认当前Kubo版本支持目标codec。脚本还应记录输出codec，而不是只保存扩展名。若后续工具按普通JSON解释dag-json中的链接对象或字节包装，语义会被悄悄改写。

dag get面向IPLD节点；读取UnixFS文件内容通常应使用ipfs cat，检查原始区块可用block get。

UnixFS文件可能由多个DAG节点组成，ipfs cat会遍历结构并输出拼接后的文件内容；dag get只展示当前解析节点的IPLD值。block get则返回单个CID对应的原始块，里面可能仍包含编码层，不能直接当文件。

因此“dag get看不到完整文件”通常不是数据缺失。先问目标是内容、结构还是原始块，再选命令。对CAR导入验收，可结合根CID、dag stat、抽样block get与实际文件hash，而不是只截图一段JSON。

对象必须在本地或可从网络获取，离线或提供者不可达会导致解析失败。

第一步检查根CID语法和codec；第二步确认本地blockstore是否有根块；第三步确认节点在线、DHT或网关可找到提供者；第四步定位是根缺失还是路径中间某个链接缺失。日志中保存失败的精确CID，不只保存整条命令。

离线模式下，本地没有的块不会凭空获取。在线模式也可能因提供者离线、网络超时或限流失败。重复请求前先判断失败类型，避免用更长超时掩盖永久缺块。

对自动化解析，固定Kubo版本和codec，限制最大输出，校验根CID与路径，保存stderr与退出码。不要把不受信任DAG中的字段直接渲染成HTML，也不要假设所有JSON键都能安全用作文件名。

当对象很大时，先用dag stat了解规模，再决定是否完整读取。运维平台应把“获取失败”“解码失败”“路径不存在”分成不同错误，便于判断网络、数据还是应用问题。

把输出交给后续程序时，再增加内容长度、递归深度和允许codec白名单。即使CID能够通过校验，节点内容仍可能包含极深结构或超大字节字段，造成解析器资源耗尽。生产工具应在隔离环境中处理不受信任对象，并对截断结果明确标记，不能把未完整读取写成核验通过。

CID表示基础见CIDv0和CIDv1选择，离线备份验收见IPFS CAR备份验完整，垃圾回收边界见repo gc删除哪些区块。本文不把可读取等同于永久可用，重要数据仍需独立备份和Pin策略。

资料访问时间为2026-08-14。仍需保留的边界：实际可用codec由Kubo版本和已注册multicodec支持决定，示例需注明版本。