6

我正在查看有关 URL 组件的一些信息,但找不到对可能的全长 url 以及每个组件可能是什么的合理解释。我想知道一个完整的 URL 会是什么样子,利用所有的复杂性。一旦我更好地理解它们,我也希望构建一个小 GUI 来帮助解释它们,但在那之前我会尝试使用我知道的组件:

[ ]括号包含完整的组件 | 管道显示组件的可能子组件 ( )括号包含关于子/组件的注释、想法和假设

我的完整理解:

[type][://][subdomain][domain][port][path][file][query][hash]

下面是每个组件的描述:如果它有一个*,它是可选的

[type]* = [ (type {http | https | ftp | file | etc...}) ] (虽然这是可选的,但我相信它也是必需的,这意味着现代浏览器会插入类型以向服务器请求它,并且服务器也可能返回不同的类型)

[://]=(不知道这个叫什么)

[subdomain]* = [ [子域] | [子域]子域]

[domain]= [名称。(类型 {com | org | etc..})]

[port]* = [(默认为空白端口:80)| 港口:** ]

[path]* = [(空白)| [路径] | [路径]路径]

[file]= [名称。(类型 {html | php | php | (etc...) }) ]

[query]* = [ ?[ 空白(即无查询)| 参数=值 | 参数=值&参数=值(等...)]]

[hash]* = [ #[ 空白(即没有哈希)| anyStringToBeParsedClientSide(通常用于持久化)](刚刚学习了哈希也称为片段标识符

我还忘记了什么,或者我忽略了一个解释它们的好网站。请更正我的命名,因为它们可能不正确,因为我也在尝试了解它们的名称。

4

1 回答 1

6

如果您真的想要所有错综复杂的东西,标准文档是唯一的出路,学习查找和阅读它们肯定会有所回报。并且 RFC 通常不是很难阅读。

在这种情况下,RFC 1738(统一资源定位器)是您想要的资源。它并不比您迄今为止提出的“过于技术化”。事实上,第 5 节的正式 BNF 语法与您所写的类似。

您可能还对描述 URI 格式的RFC 3986(统一资源标识符)感兴趣,它比单纯的 URL 更通用。

您提到的某些内容特定于 HTTP,在RFC 2616(超文本传输​​协议 1.1)中进行了描述。第 3.2 节简要介绍了 URI。

于 2012-11-14T20:37:00.607 回答