RSS3被web3領域視為一個很有前景的項目，近期，我一直在體驗web3應用，想試著去找到web3核心要素的一些定義範式，恰巧在看RSS3時，發現了我想找的一個協議，可以定義為數據規範協議，協議為RFC3986統一資源識別符，也可以理解為一個通用語法。
其文檔原文3w餘字，不易閱讀，因此我把文檔做了大量刪改，為理解web3的數據格式，做一個範例。
要知曉的是，該規範是互聯網信息標準，出現應用時間很早，RSS3是在這個基礎上作出的一些開發實踐以在web3領域應用。
RSS3
RSS3是一個開放的信息聯合協議，旨在支持Web3中高效和分散的信息分發。它定義了信息呈現和通信的格式，其他使用方可以輕鬆地以統一的格式訪問各種內容源，而無需大量的兼容邏輯。
在RSS3協議裡將信息分為四種類型：配置文件、鏈接、資產、註釋
RSS3應用程序使用RSS3SDK以RSS3協議定義的格式訪問和發布數據，RSS3 SDK從RSS3網絡獲取數據並將數據發佈到RSS3支持的網絡，RSS3 Network從各種RSS3 Supported Networks爬取數據，將數據緩存到自己的高效數據庫中，做一些預處理，例如應用人工智能推薦算法，提供搜索功能。
在這樣的產品設計裡，其最原始的數據規範，是對網絡傳輸數據進行一些細節的定義來完成的，定義了數據，就完成了基礎的數據可用性部分。上層應用就可以更輕鬆實現，讓我們來看這個協議：RFC3986統一資源識別符。經過刪改後的內容，筆者力求達到簡略了解互聯網數據處理的一些相關要求。
RFC3986:統一資源識別符
本規范源自RFC2396[RFC2396]、RFC1808[RFC1808]和RFC1738[RFC1738]，還包含更新（與更正）用於主機語法中的IPv6文字。
統一資源標識符(URI)是一個緊湊的序列標識抽像或表示物理資源的字符，提供了一個簡單且可擴展的用於識別資源的方法。規範定義了通用URI語法和相對形式的URI引用的過程解析，以及使用URI的指南和安全注意事項。
URI語法則定義了一個語法超集，有效的URI允許實現公共組件解析，實現在非特定方案要求的情況下使用URI引用每個可能的標識符，規範沒有定義URI的生成語法。
統一資源標識符(URI)語義來源於World Wide引入的概念Web全球信息倡議，語法旨在滿足“Internet功能性建議”中列出的資源定位器[RFC1736]和統一資源名稱功能的要求[RFC1737]。
本文檔廢棄了[RFC2396]，合併了“統一資源定位器”[RFC1738]和“相對統一資源定位器”[RFC1808]以便為所有URI定義一個單一的通用語法。廢棄[RFC2732]，引入了IPv6地址的語法。
URI的特點
均勻性
它允許不同類型的資源在同一上下文中使用相同的資源標識符，即使在用於訪問這些資源的機制可能不同。
它允許對常見句進行統一的語義解釋完成對跨不同類型資源標識符的約定。
它允許引入新類型的資源標識符，而不會干擾現有標識符的使用方式。
它允許標識符在許多不同的上下文中重複使用，從而允許新的應用程序或協議利用現有的、大量且廣泛使用的資源標識符集。
資源
“資源”一詞在一般意義上指任何可能由URI標識的內容。熟悉的例子包括電子文檔、圖像、信息源、服務和其他的資源集。資源不一定通過互聯網訪問。同樣地，抽象概念也可以是資源，例如運算符和數學方程的操作數，關係的類型（例如，“父母”或“員工”），或數值（例如，零，一，無窮大）。
標識符
標識符體現了對所需信息區分並從其範圍內的所有其他事物中識別出的內容鑑別過程。但這些定義不應該被誤認為是標識符的定義或體現所引用內容的身份，在許多情況下，URI用於表示資源，但不表示可以被訪問。同樣，標識的“一個”資源可能本質上不是單數的（例如，一個資源可能是一個命名集或一個隨時間變化的映射）。
URI具有全局範圍，並且無論何種情況都被用來一致地解釋上下文，儘管這種解釋的結果可能在與最終用戶的上下文相關。例如，“http://localhost/”對該引用的每個用戶都有相同的解釋，即使與“localhost”對應的網絡接口可能是不同的用戶，這代表：解釋與訪問無關。
通用語法
URI語法是一種聯合且可擴展的命名系統，其中每個方案的規範可以進一步限制使用該方案的標識符的語法和語義。
URI引用使用獨立解析機制，通過該機制，協議和數據使用URI引用的格式可以參考這個規範的所有允許語法範圍來定義URI，還包括那些尚未定義的方案。
通用URI語法的解析器可以將任何URI引用解析為其主要組成部分。方案確定後，進一步
可以對組件執行特定於方案的解析。換句話說，URI通用語法是所有URI語法的超集
URI、URL和URN
URI可以進一步分類為定位符、名稱或兩者。
“統一資源定位器”（URL）指的是URI的子集。除了識別資源之外，還提供了一種通過描述資源的訪問機制來定位資源的方法（例如，它的網絡“位置”）。
“統一資源名稱”(URN)曾用於指代在資源不復存在或變為不可用情況下仍保持全局唯一屬性的任何其他URI。
URI是來自非常有限的集合：拉丁字母、數字、和一些特殊字符。
URI可以用多種形式表示方式；例如，紙上的墨水、屏幕上的像素或一系列字符編碼八位字節。 URI的解釋僅取決於使用的字符。在本地或區域環境中，隨著技術的進步，用戶能夠使用更廣泛的字符。
識別與交互分離
對URI的一個常見誤解是它們僅用於引用到可訪問的資源。 URI本身只提供鑑別，不保證訪問資源URI的存在暗示。相反，任何相關的URI引用由協議元素定義，例如數據格式屬性或它出現的自然語言文本。
給定一個URI，系統可能會嘗試在資源上執行各種操作，可能以“訪問”“更新”、“替換”或“查找屬性”等詞為特徵。這樣的操作是由使用URI的協議定義。
分層標識符
URI語法是分層組織的，組件重要性從左到右遞減的順序排列。
通用語法使用斜杠(“https://www.jinse.com/”)、問號(“?”)和數字符號（“#”）字符來分隔組件，對通用解析器的層次解釋很重要，除了此類的可讀性標識符一致使用熟悉的語法，跨命名方案的層次結構的統一表示允許相對於該層次結構進行的獨立於方案的引用。
通常情況下，一組或“樹”形狀的文檔已經構建服務於一個共同目的，這些文檔中絕大多數的URI引用指向樹中的資源而不是在它之外。位於特定位置的文檔站點更有可能引用該站點上的其他資源而不是遠程站點的資源。 URI的引用允許文檔樹部分獨立於其位置和訪問方案。
語法符號
使用ABNF[RFC2234]的表示法，包括以下核心ABNF語法規則：
ALPHA（字母）、CR（回車）、DIGIT（十進制數字）、DQUOTE（雙引號）、HEXDIG（十六進制位）、LF（換行）和SP（空格）等。
URI語法提供了一種編碼數據的方法，大概是為了為了將資源標識為字符序列。 URI反過來，字符經常被編碼為八位字節以進行傳輸或演示。
ABNF表示法將其終端值定義為非負數，基於US-ASCII編碼字符集的整數（代碼點）[ASCII]。因為URI是一個字符序列，所以我們必須反轉該關係以便理解URI語法。因此，ABNF使用的整數值必須映射回US-ASCII對應字符以完成語法規則。
保留字符
URI包括各項分隔的組件和子組件“保留”的字符。
保留字符的目的是提供一組分隔符與URI中的其他數據區分開的字符。保留字符的子集（gen-delims）用作通用URI組件的分隔符。一種組件的ABNF語法規則不會使用reserved或gen-delims直接命名，相反，每個語法規則都列出了字符允許在該組件內（即，不定界），其他子組件可以由URI方案的規範定義。
無保留字符
URI中允許但沒有保留字符的字符，包括大寫和小寫字母、十進制數字、連字符、句點、下劃線和波浪號。
未保留=ALPHA/DIGIT/”-“https://www.jinse.com/”.”/“_”/“~”
將非保留字符替換為不同的URI，但其相應的百分比編碼的US-ASCII八位字節是等效的：它們識別相同的資源。為了一致性，在ALPHA範圍內的百分比編碼八位字節(%41-%5A和%61-%7A)、DIGIT(%30-%39)、連字符(%2D)、句點(%2E)、URI不應創建下劃線(%5F)或波浪號(%7E)生產者，當在URI中找到時，應將其解碼為URI規範器對應的未保留字符。
識別數據
URI字符為每個URI提供標識數據組件，作為識別的系統外部接口。
URIs的生產和傳輸：本地名稱和數據編碼，公共接口編碼、URI字符編碼、數據格式編碼和協議編碼。
本地名稱（例如文件系統名稱）存儲在本地字符編碼。 URI生成應用程序（例如，源服務器）通常使用本地編碼作為基礎產生有意義的名字。 URI生產者將轉換本地編碼為適合公共接口的編碼，並且然後將公共接口編碼轉換為受限集URI字符（保留、未保留和百分比編碼）。
反過來，這些字符被編碼為八位字節以用作數據格式（例如，文檔字符集）中的引用等數據格式通常隨後被編碼以傳輸互聯網協議。
在某些情況下，URI組件和識別它所代表的數據要直接比字符編碼翻譯少得多。
語法組件
通用URI語法由一個分層序列組成，有方案、權限、路徑、查詢和分段。
方案和路徑組件是必需的，儘管路徑可能是空（無字符）。當權限存在時，路徑必須可以為空或以斜杠（“/”）字符開頭。什麼時候權限不存在，路徑不能以兩個斜杠開頭人物（”//”）。這些限制導致五種不同的ABNF路徑規則，其中只有一個匹配任何給定的URI引用。
方案
每個URI都以一個方案名稱開頭，該方案名稱引用了一個規範在該方案中分配標識符。
方案名稱由一系列以a開頭的字符組成字母，後跟字母、數字和加號的任意組合(“+”)、句點(“.”)或連字符(“-“)。
方案=ALPHA*(ALPHA/DIGIT/”+”https://www.jinse.com/”-“https://www.jinse.com/”.”)
權限
許多URI方案包括用於命名的分層元素權限，以便管理由URI的其餘部分委託給該機構。通用語法提供了一個通用的基於註冊名稱或服務器地址，以及可選的端口和用戶信息。
權限組件前面有一個雙斜杠（“//”），並且是以下一個斜杠(“https://www.jinse.com/”)、問號(“?”)或數字結尾符號（“#”）字符，或在URI的末尾。
權限=[用户信息“@”]主機[“：”端口]
主機
權限的主機子組件由IP文字標識封裝在方括號中。在許多情況下，主機語法僅用於創建和部署的現有註冊流程DNS，從而獲得一個全球唯一的名稱，無需花費部署另一個註冊表。
主機=IP字段/IPv4address/reg-name
IP字段=“[”（IPv6地址/IPvFuture）“]”
IPvFuture=”v”1*HEXDIG”.”1*(未保留/子分隔符/”:”)
查詢
查詢組件包含非分層數據，以及路徑組件中的數據，用於識別URI方案和命名機構範圍內的資源。
查詢組件由問題表示標記(“?”)字符並以數字符號(“#”)字符結尾。
查詢=*(pchar/”https://www.jinse.com/”https://www.jinse.com/”?”)
用法
當應用程序引用一個URI時，它們並不總是使用由“URI”語法規則定義的完整引用形式。保存空間和利用分層局部性，許多互聯網協議元素和媒體類型格式允許縮寫URI，而其他人將語法限制為特定形式的URI。
建立基礎URI
除了僅片段引用，基本URI是已知需要的。解析器必須建立一個基本URI。基礎URI必須符合
基本URI可以通過以下四種方式之一建立
嵌入在內容中的基本URI
封裝實體的基礎URI
用於檢索實體的URI
默認基礎URI（取決於應用程序）
規範化和比較
URI上最常見的操作是簡單的比較：在不使用URI的情況下確定兩個URI是否等價訪問他們各自的資源。在比較URI之前通常進行廣泛的規範化。 URI比較是為了某些特定目的而執行。
等價
因為URI的存在是為了識別資源，所以當他們識別相同的資源時被認為是等效的。然而，這個等價的定義沒有太大的實際用途，因為是沒有辦法比較兩個資源的，除非它完全了解或控制它們。
即使可以確定兩個URI是等價的，URI比較不足以確定兩個URI識別不同的資源。
基於語法的規範化
基於語法的規範化包括以下技術案例歸一化、百分比編碼歸一化和去除點段。
安全注意事項
URI本身並不構成安全威脅。但是URI通常用於提供一組緊湊的指令以訪問
網絡資源，必須注意在URI中正確解釋數據，以防止該數據導致意外訪問，避免包含不應公開的數據文本。
敏感信息
URI生產者不應提供包含用戶名或旨在保密的密碼。 URI經常由瀏覽器顯示，存儲在明文書籤中，並由用戶代理歷史和中間應用程序（代理）。
語義攻擊
因為userinfo子組件很少使用，出現在權限組件中的主機，可以用來構造一個URI來誤導用戶信任，例如
ftp://cnn.example.com&story=break_news@10.0.0.1/top_story.htm
可能會導致用戶假設主機是“cnn.example.com”，而它實際上是’10.0.0.1’。一個誤導性的URI，可能是對用戶的攻擊，這攻擊的是用戶先入為主的概念。關於軟件本身，可以通過區分URI的各個組成部分來避免此類攻擊。
