url - 完整可能的 URL 语法和语法

Question

我正在查看有关 URL 组件的一些信息，但找不到对可能的全长 url 以及每个组件可能是什么的合理解释。我想知道一个完整的 URL 会是什么样子，利用所有的复杂性。一旦我更好地理解它们，我也希望构建一个小的 GUI 来帮助解释它们，但在那之前我会尝试使用我知道的组件:
[ ]括号包含一个完整的组件
|管道显示组件的可能子组件
( )括号包含关于子/组件的注释、想法和假设

我的完整理解:
[type][://][subdomain][domain][port][path][file][query][hash]
以下是每个组件的描述:如果它有 * ，它是可选的
[type] * = [(输入 {http | https | ftp | 文件 | 等...})]
(虽然这是可选的，但我相信它也是必需的，这意味着现代浏览器插入类型以向服务器请求它，服务器也可能返回不同的类型)
[://] =(不知道叫什么)
[subdomain] * = [ [子域] | [子域]子域]
[domain] = [名称。 (输入 {com | org | 等..})]
[port] * = [(空白，默认端口:80)|港口:** ]
[path] * = [(空白)| [路径] | [路径]路径]
[file] = [名称。 (输入 {html | php | php | (etc...) }) ]
[query] * = [ ?[ 空白(即没有查询)|参数=值|参数=值&参数=值(等...)]]
[hash] * = [ #[ 空白(即没有散列)| anyStringToBeParsedClientSide(通常用于持久性)]
(刚刚学习了一个哈希值也称为 fragment identifier )

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

Answer 1

如果您真的想要所有错综复杂的内容，标准文档是唯一的出路，并且学习查找和阅读它们绝对是值得的。并且 RFC 通常不是很难阅读。

在这种情况下，RFC 1738 (Uniform Resource Locators)是你想要的资源。它并不比你目前提出的更“过于技术化”；事实上，第 5 节具有与您所写的类似的正式 BNF 语法。

您可能还对 RFC 3986 (Uniform Resource Identifiers) 感兴趣它描述了 URI 格式，它比单纯的 URL 更通用。

您提到的某些内容是特定于 HTTP 的，在 RFC 2616 (Hypertext Transfer Protocol 1.1) 中有所描述。 . Section 3.2简要介绍 URI。