金色观察｜RSS3项目实现的基础：RFC3986统一资源识别符

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语法是分层组织的，组件重要性从左到右递减的顺序排列。

通用语法使用斜杠("/")、问号("?")和数字符号（“#”）字符来分隔组件，对通用解析器的层次解释很重要，除了此类的可读性标识符一致使用熟悉的语法，跨命名方案的层次结构的统一表示允许相对于该层次结构进行的独立于方案的引用。

通常情况下，一组或“树”形状的文档已经构建服务于一个共同目的，这些文档中绝大多数的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/"-"/"."/“_”/“~”

将非保留字符替换为不同的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/"+"/"-"/".")

权限

许多URI方案包括用于命名的分层元素权限，以便管理由URI的其余部分委托给该机构。通用语法提供了一个通用的基于注册名称或服务器地址，以及可选的端口和用户信息。

权限组件前面有一个双斜杠（“//”），并且是以下一个斜杠("/")、问号("?")或数字结尾符号（“#”）字符，或在URI的末尾。

权限=[用户信息“@”]主机[“：”端口]

主机

权限的主机子组件由IP文字标识封装在方括号中。在许多情况下，主机语法仅用于创建和部署的现有注册流程DNS，从而获得一个全球唯一的名称，无需花费部署另一个注册表。

主机=IP字段/IPv4address/reg-name

IP字段=“[”（IPv6地址/IPvFuture）“]”

IPvFuture="v"1*HEXDIG"."1*(未保留/子分隔符/":")

查询

查询组件包含非分层数据，以及路径组件中的数据，用于识别URI方案和命名机构范围内的资源。

查询组件由问题表示标记("?")字符并以数字符号("#")字符结尾。

查询=*(pchar/"/"/"?")

用法

当应用程序引用一个URI时，它们并不总是使用由“URI”语法规则定义的完整引用形式。保存空间和利用分层局部性，许多互联网协议元素和媒体类型格式允许缩写URI，而其他人将语法限制为特定形式的URI。

建立基础URI

除了仅片段引用，基本URI是已知需要的。解析器必须建立一个基本URI。基础URI必须符合<absolute-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&[email protected]/top_story.htm

可能会导致用户假设主机是“cnn.example.com”，而它实际上是'10.0.0.1'。一个误导性的URI，可能是对用户的攻击，这攻击的是用户先入为主的概念。关于软件本身，可以通过区分URI的各个组成部分来避免此类攻击。