IPFS CID 2026: คู่มือการระบุที่อยู่ตามเนื้อหา
คู่มือใช้งานจริงสำหรับ IPFS CID: CIDv0 vs CIDv1, หลักการระบุที่อยู่ตามเนื้อหา, สร้าง CID ด้วย Node.js และ Python และตรวจสอบความถูกต้อง อัปเดตปี 2026
Nacho founded IPFS.NINJA to make content-addressed storage feel as simple as an S3 PUT — a single API call, a permanent CID, no wallets or peer discovery to reason about.

- สร้าง CID ที่ทำซ้ำได้จากไบต์ของไฟล์ใดก็ได้ — เนื้อหาเดียวกันให้แฮชเดียวกันเสมอ
- ใช้ CIDv1 สำหรับการอัปโหลดใหม่: เป็น Base32 ตัวพิมพ์เล็ก และใช้งานได้กับ subdomain gateway ในขณะที่ CIDv0 ทำไม่ได้
- ไบต์เดียวที่เปลี่ยนแปลงในไฟล์จะทำให้ CID เปลี่ยนไปโดยสิ้นเชิง ทำให้ตรวจจับการดัดแปลงได้ทันที
- การระบุที่อยู่ตามเนื้อหาหมายความว่าไฟล์ถูกระบุตัวตนจากสิ่งที่มันเป็น ไม่ใช่จากตำแหน่งที่โฮสต์อยู่
หากคุณเคยทำงานกับ IPFS (InterPlanetary File System) คุณอาจจะเคยพบกับสตริงเช่น QmYwAPJzv5CZsnA625s3Xf2nemtYgPpHdWEz79ojWnPbdG หรือ bafybeigdyrzt5sfp7udm7hu76uh7y26nf3efuylqabf3oclgtqy55fbzdi สิ่งเหล่านี้ไม่ใช่ตัวอักษรสุ่ม — แต่เป็น Content Identifiers (CIDs) กระดูกสันหลังของระบบระบุที่อยู่เนื้อหาของ IPFS
การเข้าใจ CIDs เป็นสิ่งสำคัญสำหรับทุกคนที่กำลังสร้างบน IPFS ไม่ว่าคุณจะอัปโหลดไฟล์ สร้างแอปพลิเคชันแบบกระจายอำนาจ หรือใช้งานระบบกระจายเนื้อหา คู่มือนี้จะอธิบายทุกสิ่งที่คุณต้องรู้เกี่ยวกับ IPFS CIDs การระบุที่อยู่เนื้อหาทำงานอย่างไร และวิธีเริ่มใช้งานในโครงการของคุณ
สร้าง CID ใน 5 บรรทัด (Python)#
import hashlib, base58
def cidv0(content: bytes) -> str:
sha256 = hashlib.sha256(content).digest()
return base58.b58encode(b"\x12\x20" + sha256).decode()
print(cidv0(b"hello world"))
# QmaozNR7DZHQK1ZcU9p7QdrshMvXqWK6gpvBw3cWE69N3Tทุกคนสามารถสร้าง CID นี้ซ้ำได้ — รันโค้ดเดียวกันด้วยไบต์เดียวกันที่ไหนก็ได้ในโลก จะได้สตริงเดียวกัน นี่คือการระบุที่อยู่ตามเนื้อหา
เทียบเท่าใน Node.js:
import { sha256 } from 'multiformats/hashes/sha2';
import { CID } from 'multiformats/cid';
const bytes = new TextEncoder().encode('hello world');
const hash = await sha256.digest(bytes);
const cid = CID.create(1, 0x55, hash); // version 1, raw codec
console.log(cid.toString());
// bafkreif7l7mvyofhyo6fgs6mjf5gguvm5jcahzgvfb3o7t5lmhz3...
IPFS CID คืออะไร?#
Content Identifier (CID) คือลายนิ้วมือเฉพาะที่แสดงถึงเนื้อหาบน IPFS ต่างจาก URL บนเว็บแบบดั้งเดิมที่ชี้ไปยังตำแหน่ง (เช่น https://example.com/file.pdf) CIDs ชี้ไปยังตัวเนื้อหาเอง โดยไม่คำนึงถึงที่จัดเก็บ
ลองคิดแบบนี้:
- การระบุที่อยู่ตามตำแหน่ง: “ไปที่ถนนเมน 123 และขอหนังสือสีแดง”
- การระบุที่อยู่ตามเนื้อหา: “ค้นหาหนังสือที่มี ISBN 978-0-123456-78-9” (ไม่สำคัญว่าห้องสมุดไหนจะมี)
CIDs ทำงานในลักษณะเดียวกัน — พวกเขาระบุเนื้อหาตามแฮชเข้ารหัสของมัน ทำให้เนื้อหา ไม่สามารถเปลี่ยนแปลงได้ และ ตรวจสอบได้ หากมีไบต์เดียวที่เปลี่ยนแปลงในไฟล์ CID จะเปลี่ยนแปลงโดยสิ้นเชิง
ทำไมการระบุที่อยู่เนื้อหาจึงสำคัญ#
สถาปัตยกรรมเว็บแบบดั้งเดิมพึ่งพาการระบุที่อยู่ตามตำแหน่ง เมื่อคุณเข้าชม https://example.com/image.jpg คุณเชื่อว่า:
- เจ้าของโดเมนไม่ได้เปลี่ยนเนื้อหา
- เซิร์ฟเวอร์ออนไลน์และเข้าถึงได้
- เนื้อหาไม่ถูกแก้ไข
ด้วยการระบุที่อยู่เนื้อหาโดยใช้ CIDs:
- ความไม่เปลี่ยนแปลง: CID รับประกันว่าเนื้อหาไม่ได้เปลี่ยนแปลง
- การกระจายอำนาจ: เนื้อหาสามารถดึงมาได้จากโหนด IPFS ใดๆ ที่มีอยู่
- การตรวจสอบ: คุณสามารถตรวจสอบเข้ารหัสว่าได้รับเนื้อหาที่ถูกต้อง
- ประสิทธิภาพ: เนื้อหาที่เหมือนกันจะถูก deduplicate โดยอัตโนมัติ
กายวิภาคของ CID#
มาแยกย่อย CID ทั่วไปเพื่อทำความเข้าใจส่วนประกอบของมัน:
bafybeigdyrzt5sfp7udm7hu76uh7y26nf3efuylqabf3oclgtqy55fbzdi
└─┬─┘└─────────────────┬─────────────────────────────────┘
│ │
│ └─ แฮชเนื้อหา (เข้ารหัส Base32)
└─ คำนำหน้า Multibase (ระบุการเข้ารหัส)CID มีข้อมูลหลายส่วน:
1. คำนำหน้า Multibase#
อักขระตัวแรกระบุว่า CID เข้ารหัสอย่างไร:
Q= เข้ารหัส Base58 (CIDv0)b= เข้ารหัส Base32 (CIDv1)f= Base16/เลขฐานสิบหก (CIDv1)z= Base58 (CIDv1)
2. เวอร์ชัน CID#
- CIDv0: เริ่มต้นด้วย
Qmเสมอ ใช้ SHA-256 จำกัดที่ DAG-PB codec - CIDv1: ยืดหยุ่นมากขึ้น รองรับฟังก์ชันแฮชและ codec หลายแบบ
3. Multicodec#
ระบุว่าเนื้อหาถูกจัดโครงสร้างอย่างไร (DAG-PB, DAG-CBOR, raw bytes ฯลฯ)
4. Multihash#
แฮชเข้ารหัสจริงของเนื้อหา ประกอบด้วย:
- ตัวระบุฟังก์ชันแฮช (ปกติคือ SHA-256)
- ความยาวแฮช
- ค่า digest ของแฮช
CIDv0 vs CIDv1: ทำความเข้าใจความแตกต่าง#
IPFS ได้พัฒนาผ่านสองเวอร์ชัน CID หลัก แต่ละเวอร์ชันมีลักษณะเฉพาะ:
CIDv0: รูปแบบดั้งเดิม#
CIDv0 CIDs เริ่มต้นด้วย Qm เสมอ และมีลักษณะดังนี้:
QmYwAPJzv5CZsnA625s3Xf2nemtYgPpHdWEz79ojWnPbdGลักษณะ:
- เฉพาะการเข้ารหัส Base58
- เฉพาะฟังก์ชันแฮช SHA-256
- เฉพาะ DAG-PB (Protobuf) codec
- ยาว 46 อักขระ
- เข้ากันได้กับการใช้งาน IPFS ทั้งหมด
เมื่อใดควรใช้ CIDv0:
- ความเข้ากันได้สูงสุดกับโหนด IPFS เก่า
- ทำงานกับระบบที่มีอยู่ที่คาดหวังคำนำหน้า
Qm - การจัดเก็บไฟล์ (กรณีการใช้งานที่พบบ่อยที่สุด)
CIDv1: มาตรฐานสมัยใหม่#
CIDv1 CIDs มีความยืดหยุ่นมากกว่าและอาจมีลักษณะดังนี้:
bafybeigdyrzt5sfp7udm7hu76uh7y26nf3efuylqabf3oclgtqy55fbzdi # Base32
zb2rhj7crUKTQYRGCRATFaQ6YFLTde2YzdqbbhAASkL9uRDXn # Base58
f01551220d1e2c35... # Base16ลักษณะ:
- รูปแบบการเข้ารหัสหลายแบบ (Base32, Base58, Base16)
- รองรับฟังก์ชันแฮชต่างๆ (SHA-256, SHA-512, BLAKE2 ฯลฯ)
- หลาย codec (Raw, DAG-CBOR, DAG-JSON ฯลฯ)
- รูปแบบที่อธิบายตนเองได้
- ไม่คำนึงถึงตัวพิมพ์เล็กใหญ่เมื่อใช้ Base32
เมื่อใดควรใช้ CIDv1:
- สร้างแอปพลิเคชันใหม่
- ต้องการตัวระบุที่ไม่คำนึงถึงตัวพิมพ์
- ทำงานกับข้อมูลที่มีโครงสร้าง (JSON, CBOR)
- ใช้ฟังก์ชันแฮชทางเลือก
การแปลงระหว่างเวอร์ชัน#
คุณสามารถแปลง CIDs ระหว่างเวอร์ชันได้ในขณะที่คงการอ้างอิงเนื้อหาเดียวกัน:
// CIDv0
const cidv0 = "QmYwAPJzv5CZsnA625s3Xf2nemtYgPpHdWEz79ojWnPbdG";
// Convert to CIDv1 Base32
const cidv1 = "bafybeigdyrzt5sfp7udm7hu76uh7y26nf3efuylqabf3oclgtqy55fbzdi";
// Both reference the same content!การระบุที่อยู่เนื้อหาทำงานอย่างไร#
การระบุที่อยู่เนื้อหาใน IPFS ปฏิบัติตามกระบวนการที่กำหนดได้ ซึ่งรับประกันว่าเนื้อหาเดียวกันจะสร้าง CID เดียวกันเสมอ:
1. การเตรียมเนื้อหา#
เมื่อคุณเพิ่มเนื้อหาลงใน IPFS มันจะถูกแบ่งก่อน:
- ไฟล์เล็ก: จัดเก็บเป็นบล็อกเดียว
- ไฟล์ใหญ่: แบ่งเป็นชิ้นๆ และจัดระเบียบใน Merkle DAG (graph แบบกำหนดทิศทางที่ไม่มีวงจร)
- ไดเรกทอรี: แสดงเป็นโครงสร้าง DAG ที่เชื่อมโยงกับไฟล์
2. กระบวนการแฮช#
แต่ละชิ้นของเนื้อหาผ่าน:
- การ Serialize: เนื้อหาถูกจัดรูปแบบตาม codec ของมัน
- การแฮช: ฟังก์ชันแฮชเข้ารหัสประมวลผลข้อมูลที่ serialize
- การสร้าง Multihash: แฮชถูกห่อด้วยข้อมูลอัลกอริทึมและความยาว
- การประกอบ CID: เวอร์ชัน codec และ multihash ถูกรวมกัน
3. โครงสร้าง Merkle DAG#
IPFS จัดระเบียบเนื้อหาใน Merkle DAG ที่:
- แต่ละโหนดมี CID
- โหนดพ่อแม่อ้างอิงโหนดลูกผ่าน CID
- การเปลี่ยนแปลงในโหนดใดๆ จะแพร่กระจายขึ้นในต้นไม้
- โครงสร้างทั้งหมดสามารถตรวจสอบเข้ารหัสได้
Root CID: bafybeigdyrzt5sfp7udm7hu76uh7y26nf3efuylqabf3oclgtqy55fbzdi
├── file1.txt (QmHash1...)
├── file2.jpg (QmHash2...)
└── subdirectory/
├── file3.pdf (QmHash3...)
└── file4.mp4 (QmHash4...)ตัวอย่างเชิงปฏิบัติ: การทำงานกับ CIDs#
มาสำรวจวิธีทำงานกับ CIDs ในทางปฏิบัติโดยใช้ IPFS Ninja API:
การอัปโหลดเนื้อหาและรับ CID#
// Upload a file and get its CID
const uploadFile = async (content, filename) => {
const response = await fetch('https://api.ipfs.ninja/upload/new', {
method: 'POST',
headers: {
'X-Api-Key': 'bws_1234567890abcdef1234567890abcdef12345678',
'Content-Type': 'application/json'
},
body: JSON.stringify({
content: btoa(content), // Base64 encode binary content
description: `Upload of ${filename}`
})
});
const result = await response.json();
console.log('CID:', result.cid);
console.log('IPFS URL:', result.uris.ipfs);
console.log('HTTP URL:', result.uris.url);
return result.cid;
};
// Example usage
uploadFile('Hello, IPFS!', 'greeting.txt');
// Returns: bafkreifjxz6zwqh27k5xnr5qfbx4w6n5vuwwwdcngguwjewzj2e3xxfgviการปักหมุดเนื้อหาที่มีอยู่ตาม CID#
หากคุณมี CID อยู่แล้ว คุณสามารถปักหมุดเพื่อรับประกันความพร้อมใช้งาน:
const pinByCID = async (cid) => {
const response = await fetch('https://api.ipfs.ninja/pin', {
method: 'POST',
headers: {
'X-Api-Key': 'bws_1234567890abcdef1234567890abcdef12345678',
'Content-Type': 'application/json'
},
body: JSON.stringify({
cid: cid,
description: 'Pinned via API'
})
});
const result = await response.json();
console.log('Pinned CID:', result.cid);
return result;
};
// Pin the "Hello World" of IPFS
pinByCID('QmWATWQ7fVPP2EFGu71UkfnqhYXDYH566qy47CnJDgvs8u');การเข้าถึงเนื้อหาผ่าน CID#
เมื่อคุณมี CID คุณสามารถเข้าถึงเนื้อหาผ่านวิธีต่างๆ:
// Direct IPFS gateway access
const ipfsUrl = `https://ipfs.ninja/ipfs/${cid}`;
// Custom gateway (if configured)
const customGatewayUrl = `https://my-app.gw.ipfs.ninja/ipfs/${cid}`;
// Fetch content programmatically
const fetchContent = async (cid) => {
const response = await fetch(`https://ipfs.ninja/ipfs/${cid}`);
const content = await response.text();
return content;
};แนวทางปฏิบัติที่ดีที่สุดของ CID สำหรับนักพัฒนา#
1. ตรวจสอบ CIDs เสมอ#
ก่อนใช้ CID ในแอปพลิเคชันของคุณ ให้ตรวจสอบรูปแบบของมัน:
const isValidCID = (cid) => {
// Basic validation patterns
const cidv0Pattern = /^Qm[1-9A-HJ-NP-Za-km-z]{44}$/;
const cidv1Pattern = /^[bf][a-z2-7]{58}$/;
return cidv0Pattern.test(cid) || cidv1Pattern.test(cid);
};2. จัดการ CID ทั้งสองเวอร์ชัน#
แอปพลิเคชันของคุณควรทำงานได้กับทั้ง CIDv0 และ CIDv1:
const normalizeCID = (cid) => {
if (cid.startsWith('Qm')) {
// CIDv0 - can convert to CIDv1 if needed
return cid;
} else if (cid.startsWith('b') || cid.startsWith('f') || cid.startsWith('z')) {
// CIDv1
return cid;
} else {
throw new Error('Invalid CID format');
}
};3. แคชการแมป CID#
หากคุณสร้าง CIDs บ่อยครั้ง พิจารณาการแคช:
const cidCache = new Map();
const getCachedCID = (content) => {
const contentHash = btoa(content);
if (cidCache.has(contentHash)) {
return cidCache.get(contentHash);
}
// Upload and cache result
return uploadFile(content).then(cid => {
cidCache.set(contentHash, cid);
return cid;
});
};4. ใช้คำอธิบายที่มีความหมาย#
เมื่ออัปโหลดเนื้อหา ให้รวมเมตาดาต้าที่อธิบาย:
const uploadWithMetadata = async (content, metadata) => {
return fetch('https://api.ipfs.ninja/upload/new', {
method: 'POST',
headers: {
'X-Api-Key': 'bws_1234567890abcdef1234567890abcdef12345678',
'Content-Type': 'application/json'
},
body: JSON.stringify({
content: btoa(content),
description: metadata.name || 'Uploaded file',
metadata: {
filename: metadata.filename,
contentType: metadata.contentType,
uploadedAt: new Date().toISOString(),
version: metadata.version || '1.0'
}
})
});
};กรณีการใช้ CID ทั่วไป#
1. การปรับใช้เว็บไซต์แบบสถิต#
ปรับใช้เว็บไซต์ทั้งหมดไปยัง IPFS และอ้างอิงด้วย CID:
// Upload website directory structure
const deployWebsite = async (files) => {
const uploads = await Promise.all(
files.map(file => uploadFile(file.content, file.path))
);
// Root CID references entire site
const rootCID = uploads.find(u => u.path === 'index.html').cid;
console.log(`Website deployed: https://ipfs.ninja/ipfs/${rootCID}`);
return rootCID;
};หากต้องการเรียนรู้เพิ่มเติมเกี่ยวกับการปรับใช้เว็บไซต์ ดูคู่มือของเราเกี่ยวกับ วิธีอัปโหลดไฟล์ไปยัง IPFS
2. การจัดเก็บเมตาดาต้า NFT#
จัดเก็บเมตาดาต้า NFT ไม่ให้เปลี่ยนแปลงโดยใช้ CIDs:
const nftMetadata = {
name: "My Awesome NFT",
description: "A unique digital collectible",
image: "ipfs://bafkreibc5sgo2plmjkq2tzmhrn54bk3crhnqekiy7u66fqvqm37pu2e5gw",
attributes: [
{ trait_type: "Color", value: "Blue" },
{ trait_type: "Rarity", value: "Epic" }
]
};
const metadataCID = await uploadFile(
JSON.stringify(nftMetadata, null, 2),
'metadata.json'
);
// Use in smart contract
console.log(`Token URI: ipfs://${metadataCID}`);3. การกระจายเนื้อหา#
ใช้ CIDs สำหรับการส่งมอบเนื้อหาแบบกระจาย:
// Upload once, access everywhere
const distributeContent = async (content) => {
const cid = await uploadFile(content, 'content.txt');
// Content available via multiple gateways
const gateways = [
`https://ipfs.ninja/ipfs/${cid}`,
`https://ipfs.io/ipfs/${cid}`,
`https://cloudflare-ipfs.com/ipfs/${cid}`
];
return { cid, gateways };
};การเข้าใจ IPFS pinning ด้วย CIDs#
CIDs เป็นแบบชั่วคราวโดยค่าเริ่มต้น — ต้องถูก “ปักหมุด” เพื่อให้ยังคงพร้อมใช้งาน เรียนรู้เพิ่มเติมเกี่ยวกับแนวคิดสำคัญนี้ในคู่มือที่ครอบคลุมของเราเกี่ยวกับ IPFS pinning คืออะไร
เมื่อเลือกบริการ IPFS pinning พิจารณาการอ่านการเปรียบเทียบของเรา IPFS Ninja vs Pinata หรือสำรวจการรวบรวม บริการ IPFS pinning ที่ดีที่สุด ที่มีอยู่ในวันนี้
สร้าง CID แรกของคุณใน 30 วินาที#
พร้อมที่จะสร้าง CID แรกของคุณแล้วหรือยัง? นี่คือตัวอย่างด่วนโดยใช้ IPFS Ninja API:
# Using curl (replace with your actual API key)
curl -X POST https://api.ipfs.ninja/upload/new \
-H "X-Api-Key: bws_YOUR_API_KEY_HERE" \
-H "Content-Type: application/json" \
-d '{
"content": "SGVsbG8sIElQRlMgV29ybGQh",
"description": "My first IPFS upload"
}'// Using JavaScript
const createFirstCID = async () => {
const response = await fetch('https://api.ipfs.ninja/upload/new', {
method: 'POST',
headers: {
'X-Api-Key': 'bws_YOUR_API_KEY_HERE',
'Content-Type': 'application/json'
},
body: JSON.stringify({
content: btoa('Hello, IPFS World!'), // Base64: "SGVsbG8sIElQRlMgV29ybGQh"
description: 'My first IPFS upload'
})
});
const result = await response.json();
console.log('🎉 Your first CID:', result.cid);
console.log('🌐 Access it at:', result.uris.url);
return result;
};
createFirstCID();นี่จะส่งคืนบางอย่างเช่น:
{
"cid": "bafkreif2pall7dybz7vecqka3zo24irdwabf7rbiiweuhau7a2hjlqvfjw",
"sizeMB": 0.000017,
"uris": {
"ipfs": "ipfs://bafkreif2pall7dybz7vecqka3zo24irdwabf7rbiiweuhau7a2hjlqvfjw",
"url": "https://ipfs.ninja/ipfs/bafkreif2pall7dybz7vecqka3zo24irdwabf7rbiiweuhau7a2hjlqvfjw"
}
}สำหรับตัวอย่าง API ที่ละเอียดยิ่งขึ้น ดูที่ บทช่วยสอน API การอัปโหลด IPFS ของเรา
บทสรุป#
CIDs เป็นรากฐานของระบบระบุที่อยู่เนื้อหา IPFS ให้การระบุตัวเนื้อหาที่ไม่สามารถเปลี่ยนแปลงได้ ตรวจสอบได้ และกระจายอำนาจ การเข้าใจว่าพวกเขาทำงานอย่างไร — จากรายละเอียดทางเทคนิคของ CIDv0 vs CIDv1 ไปจนถึงรูปแบบการใช้งานเชิงปฏิบัติ — เป็นสิ่งจำเป็นสำหรับการสร้างแอปพลิเคชันแบบกระจายอำนาจที่แข็งแกร่ง
ประเด็นสำคัญ:
- CIDs ระบุเนื้อหาอย่างเฉพาะตัวไม่ใช่ตำแหน่ง
- CIDv0 ให้ความเข้ากันได้สูงสุด, CIDv1 ให้ความยืดหยุ่น
- การระบุที่อยู่เนื้อหาเปิดใช้งานการตรวจสอบและการ deduplicate
- การจัดการ CID ที่เหมาะสมเป็นสิ่งสำคัญสำหรับแอปพลิเคชัน production
ไม่ว่าคุณจะจัดเก็บเมตาดาต้า NFT, ปรับใช้เว็บไซต์แบบกระจายอำนาจ หรือสร้างระบบกระจายเนื้อหา CIDs ให้รากฐานที่เชื่อถือได้ที่คุณต้องการสำหรับแอปพลิเคชันแบบกระจายอำนาจอย่างแท้จริง
พร้อมที่จะเริ่ม pinning แล้วหรือยัง? สร้างบัญชีฟรี — 50 ไฟล์, 1 GB พื้นที่จัดเก็บ, 2 GB แบนด์วิดธ์/เดือน ไม่ต้องใช้บัตรเครดิต
เกี่ยวกับบทความนี้
บทความนี้จัดทำด้วยความช่วยเหลือของ AI ตรวจสอบโดยมนุษย์ และยืนยันความถูกต้องกับแพลตฟอร์ม IPFS.NINJA จริงก่อนเผยแพร่ ดูวิธีที่เราใช้ AI ในเนื้อหาของเรา .

เกี่ยวกับผู้เขียน
Nacho Coll
Founder & Engineer at IPFS.NINJA
Nacho founded IPFS.NINJA to make content-addressed storage feel as simple as an S3 PUT — a single API call, a permanent CID, no wallets or peer discovery to reason about. Writes about IPFS internals, decentralized storage patterns, and the pinning-service landscape from the operator side of the wire.
