blocks|key|5704884|text|type|unstyled|depth|inlineStyleRanges|entityRanges|data|entityMap^0^^$0|@$1|2|3|-4|4|5|6|B|7|@]|8|@]|9|$]]]|A|$]]

Here is a more or less readable spec of unixfs (the dataformat used to encode merkle trees of directories and files).
<a href="https://github.com/ipfs/specs/pull/331" rel="nofollow noreferrer">https://github.com/ipfs/specs/pull/331</a>
First the thing you seems to have caught on but adding it for future readers, unixfs is a merkle datastructure, that means we use hashes as pointer, CIDs are hashes + metadata pointing to the next block.
Unixfs is then a kinda b-tree of blocks, instead of pointers cryptographic hashes are used to link data (this allows anyone to verify the whole tree starting from the root).
I said kinda b-tree because it doesn't actually have to be balanced, and there reasons you might want to not do that.
How to decode it ?
Unixfs is made of two kind of blocks:
You can decode this from the CID, here is an example CID:
<pre><code>bafkreifzjut3te2nhyekklss27nh3k72ysco7y32koao5eei66wof36n5e
</code></pre>
The first character is the multibase key, this allows the CID to use some different base encoding, you look it up in this table:
<a href="https://github.com/multiformats/multibase/blob/master/multibase.csv" rel="nofollow noreferrer">https://github.com/multiformats/multibase/blob/master/multibase.csv</a>
A <code>b</code> gives us <code>base32</code> <code>rfc4648 case-insensitive - no padding</code>.
You then decode the rest of CID using this spec and obtain binary data, I'll represent it as hex for convenience but the implementation works in binary from this point.
The next step is to read 4 back to back <code>uvarint</code>s, they are so called <a href="https://github.com/multiformats/unsigned-varint" rel="nofollow noreferrer">MSB-128</a> if you want to look them up (this is the sane version most programing languages implements).
Here unpacked we get:
<ul>
<li><code>0x01</code> this the version of the CID, must be 1 for a CIDv1 (what we are parsing right now)</li>
<li><code>0x55</code> this is the codec, this maybe tells you what the data is made off, or how you parse it, sadly there is more or less consistency between ways this is used.
You can lookup codecs in this table, here we want to look for codecs tagged <code>ipld</code>:
<a href="https://github.com/multiformats/multicodec/blob/master/table.csv" rel="nofollow noreferrer">https://github.com/multiformats/multicodec/blob/master/table.csv</a></li>
<li><code>0x12</code> this the multihash code, this tell you which hashing function was used. To find the correspondance between codes and hashing functions you lookup the same multicodec table from above but this time searching for <code>multihash</code> tagged ids.</li>
<li><code>0x20</code> this is the length in bytes of the hash digest (this is here to support truncated hashes and variable size output hashing functions).
And a bunch of trailing data, this is actually the digest: <code>b94d27b9934d3e08a52e52d7da7dabfac484efe37a5380ee9088f7ace2efcde9</code></li>
</ul>
So decoded our CID is:
<ul>
<li><code>v1</code></li>
<li><code>Raw</code></li>
<li><code>sha256</code></li>
<li><code>32 bytes</code></li>
<li><code>b94d27b9934d3e08a52e52d7da7dabfac484efe37a5380ee9088f7ace2efcde9</code></li>
</ul>
By some magic process we now need to find out the bytes that <code>multihashTable[0x12](bytes) == 0xb94d27b9934d3e08a52e52d7da7dabfac484efe37a5380ee9088f7ace2efcde9</code>.
This is taken care of by other layers, the key feature here is that the decoding merkle proofs do not depend of any underlying transport, you can exchange your data using whatever protocol you want as long as you are able to find the bytes that hashed produce the required digest this process can continue.
For this example <code>sha256(&quot;hello world&quot;)</code> is the answer.
So we have our root block it's <code>hello world</code>.
We can now proceed to decoding it, for unixfs we handle two possible codecs:
<h3><code>0x55</code> Raw codec</h3>
The content of the block is the content of the file.
There is literally no encoding here, <code>hello world</code> is the block content, so it's also a file with length 9 and content <code>hello world</code>.
We just decoded a raw block!
<h3><code>0x70</code> Dag-pb codec</h3>
Let's take this new cid as example: <code>bafybeiejivmdhj3y62h5ejgzctp6oky2dct2ierrqzxlhe3znkt7jusuay</code>
Going through the same cid decoding process I described above (multibase then read 4 uvaruints we get):
<ul>
<li><code>v1</code></li>
<li><code>dag-pb</code></li>
<li><code>sha256</code></li>
<li><code>32 bytes</code></li>
<li><code>0x89455833a778f68fd224d914dfe72b1a18a7a41231866eb393796aa7f4d25406</code> digest.</li>
</ul>
This time we need a protobuf decoder and some schemas:
<ul>
<li><a href="https://github.com/ipld/ipld/blob/master/specs/codecs/dag-pb/spec.md#serial-format" rel="nofollow noreferrer"><code>ipld.proto</code></a></li>
<li><a href="https://github.com/ipfs/specs/blob/6c250e676ac2e3d19693e03404c698d56345aad7/UNIXFS.md#data-format" rel="nofollow noreferrer"><code>unixfs.proto</code></a></li>
</ul>
Here is me decoding it using the <code>protoc</code> compiler:
<pre><code>$ ipfs block get bafybeiejivmdhj3y62h5ejgzctp6oky2dct2ierrqzxlhe3znkt7jusuay | protoc --decode=PBNode ipld.proto 
Data: &quot;\010\001&quot;
Links {
 Hash: &quot;\001U\022 \271M\'\271\223M&gt;\010\245.R\327\332}\253\372\304\204\357\343zS\200\356\220\210\367\254\342\357\315\351&quot;
 Name: &quot;hi.txt&quot;
 Tsize: 11
}
</code></pre>
Now the next thing to do which is a bit weird (history &amp; backward compatiblity) is to take the <code>.Data</code> <code>bytes</code> field and decode it again but this time using <code>unixfs.proto</code>:
<pre><code>$ echo CAE= | base64 -d | protoc --decode=Data unixfs.proto 
Type: Directory
</code></pre>
This tells us this a directory, Dag-pb blocks can be many other things (lookup the spec for a complete description), mainly <code>File</code>! The point of using <code>Dag-pb</code> instead of <code>Raw</code> is that this allows us to link and concatenate smaller files into bigger ones.
There are lots of reasons in P2P why downloading many smaller blocks is better than huge ones.
With this new knowledge we can look again at the first decoded protobuf and read the links, for a simple directory, links is a list of various children blocks,
<ul>
<li><code>Hash</code> is a binary CID, we would then apply the same steps (read 4 uvarints, download the block, parse it, ...) in this case this is the first Raw <code>hello world</code> CID we looked at earlier.</li>
<li><code>Name</code> field tell you the file name.</li>
<li><code>TSize</code> is almost unused and not the size of the file (this is not used while decoding anything).</li>
</ul>
Directories can point to other directories (for nested structures), files, ...
So the structure we have here is:
<pre><code>.
└── hi.txt -&gt; hello world
</code></pre>
<h2><code>Qm...</code> CIDv0 CIDs</h2>
Thoses are called CIDv0, they can be converted losslessly to CIDv1 easily.
First you decode them with bitcoin base58 then you skip two magic bytes and then read 32 bytes.
The 32 bytes you just red are the hash digest, the varuints are hardcoded to be <code>dag-pb</code>, <code>sha256</code>, <code>32 bytes</code>.
When you do this conversion, there is not two files, one of them CIDv0 and an other CIDv1. They both encode the same link.

So, my understanding is that ipfs uses the ipld format to link data. Once a file is uploaded it is divided up and hashed. The whole thing is then bundled up in a Merkle dag. How to resolve the blobs of data? Given a CIDv0 or CIDv1 which we shall call <code>root</code>:
<pre><code>bafybeihbqaitndot2arwcwxq7i66jjbfpgaurkzkizwhyq74xcnamkc7wm

</code></pre>
we may find all the CIDs that &quot;make up&quot; that root. the standard ipfs client gives us the command <code>ipfs dag get cid</code>. In this case for choosing <code>cid=root</code> those resolved cids are:
<pre><code>QmNmigQh6aETtpCjMgb7TZy75XaktAvdyAqcPVhqvvQdW8
QmNoymPywjiE29Q4PyghBgh9WWqGQwYphTFLcuE82CqEPG
QmSA5p69qqjnYLvSNP8fLLkwvD9Fqmt5CEHA4DwbKaE9yD
QmREdziekNW4yLkPC4GsxLRoLWVCWCKfMYcykpbRGMdMQV
QmNWkQ4ozM1rwnLouJsawsgCWcwAyZnPHV5uoJbZycDdSR
</code></pre>
And in fact, these are already the little content blobs of my react app sitting on ipfs. Now my question is: where is this information stored? Like the information that resolves those cids? In fact there is also a little bit of metadata that comes with it, depending on the format/codec that is used in the ipld format. For instance:
<pre><code>$ ipfs dag get bafybeihbqaitndot2arwcwxq7i66jjbfpgaurkzkizwhyq74xcnamkc7wm 
{
 &quot;Data&quot;: {
 &quot;/&quot;: {
 &quot;bytes&quot;: &quot;CAIY04BIIICAECCAgBAggIAQIICAECDTgAg&quot;
 }
 },
 &quot;Links&quot;: [
 {
 &quot;Hash&quot;: {
 &quot;/&quot;: &quot;QmNmigQh6aETtpCjMgb7TZy75XaktAvdyAqcPVhqvvQdW8&quot;
 },
 &quot;Name&quot;: &quot;&quot;,
 &quot;Tsize&quot;: 262158
 },
 {
 &quot;Hash&quot;: {
 &quot;/&quot;: &quot;QmNoymPywjiE29Q4PyghBgh9WWqGQwYphTFLcuE82CqEPG&quot;
 },
 &quot;Name&quot;: &quot;&quot;,
 &quot;Tsize&quot;: 262158
 },
 {
 &quot;Hash&quot;: {
 &quot;/&quot;: &quot;QmSA5p69qqjnYLvSNP8fLLkwvD9Fqmt5CEHA4DwbKaE9yD&quot;
 },
 &quot;Name&quot;: &quot;&quot;,
 &quot;Tsize&quot;: 262158
 },
 {
 &quot;Hash&quot;: {
 &quot;/&quot;: &quot;QmREdziekNW4yLkPC4GsxLRoLWVCWCKfMYcykpbRGMdMQV&quot;
 },
 &quot;Name&quot;: &quot;&quot;,
 &quot;Tsize&quot;: 262158
 },
 {
 &quot;Hash&quot;: {
 &quot;/&quot;: &quot;QmNWkQ4ozM1rwnLouJsawsgCWcwAyZnPHV5uoJbZycDdSR&quot;
 },
 &quot;Name&quot;: &quot;&quot;,
 &quot;Tsize&quot;: 131169
 }
 ]
}
</code></pre>
where is that information stored? And is the <code>root</code> cid just the (multi-)hash of the consituent cids or is it the (multi-)hash of the above object?

Where does ipfs store the pathing data that resolves the content?

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云AI代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

功能1上新10个字符

功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符。

功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符。

功能5描述100个字符功能5描述100个字符功能5描述100个字符功能5描述100个字符功能5描述100个字符功能5描述100个字符

功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符

功能4上新

文章&问答评论现已支持表情

全新交互，全新视觉，新增快捷键、悬浮工具栏、高亮块等功能并同时优化现有功能，全面提升创作效率和体验

社区富文本编辑器全新改版！诚邀体验～ 

精选全网热门MCP server，让你的AI更好用 🚀

💥开发者 MCP广场重磅上线！

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

因此，我的理解是ipfs使用ipld格式链接数据。一旦一个文件被上传，它就会被分割和散列。整个事情然后被捆绑在一个默克尔达格。如何解决数据的问题？给定一个CIDv0或CIDv1，我们称之为root：bafybeihbqaitndot2arwcwxq7i66jjbfpgaurkzkizwhyq74xcnamkc7wm我们可以找到所有的CID“组成”那个根。标准ipfs客户端给我们命令ipfs dag

问ipfs将解析内容的数据存储在哪里？
EN

回答 1

Ethereum用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问ipfs将解析内容的数据存储在哪里？EN