A-A+

重新认识URL 详解URL ../与./

2018年10月14日 21:58 学习笔记 暂无评论 阅读 571 views 次

【注意:此文章为博主原创文章!转载需注意,请带原文链接,至少也要是txt格式!】

统一资源定位符 (URL)

统一资源定位符(或称统一资源定位器/定位地址URL地址英语:Uniform Resource Locator,常缩写为URL),有时也被俗称为网页地址网址)。如同在网上上的门牌,是因特网上标准的资源的地址(Address)。它最初是由蒂姆·伯纳斯-李发明用来作为万维网的地址。现在它已经被万维网联盟编制为因特网标准 RFC 1738

在互联网的历史上,统一资源定位符的发明是一个非常基础的步骤。统一资源定位符的语法是一般的,可扩展的,它使用ASCII代码的一部分来表示因特网的地址。统一资源定位符的开始,一般会标志着一个计算机网络所使用的网络协议。

统一资源定位符的标准格式如下:

协议类型:[//服务器地址[:端口号]][/资源层级UNIX文件路径]文件名[?查询][#片段ID]

统一资源定位符的完整格式如下:

协议类型:[//[访问资源需要的凭证信息@]服务器地址[:端口号]][/资源层级UNIX文件路径]文件名[?查询][#片段ID]

其中【访问凭证信息@ :端口号 ?查询 #片段ID】都属于选填项。

URL语法

主条目:统一资源标志符 § 文法

超文本传输协议(HTTP)的统一资源定位符将从因特网获取信息的五个基本元素包括在一个简单的地址中:

  1. 传送协议。Data URI scheme
  2. 层级URL标记符号(为[//],固定不变)
  3. 访问资源需要的凭证信息(可省略)
  4. 服务器。(通常为域名,有时为IP地址)
  5. 端口号。(以数字方式表示,若为HTTP的默认值“:80”可省略)
  6. 路径。(以“/”字符区别路径中的每一个目录名称)
  7. 查询。(GET模式的窗体参数,以“?”字符为起点,每个参数以“&”隔开,再以“=”分开参数名称与数据,通常以UTF8的URL编码,避开字符冲突的问题)
  8. 片段。以“#”字符为起点

http://zh.wikipedia.org:80/w/index.php?title=Special:%E9%9A%8F%E6%9C%BA%E9%A1%B5%E9%9D%A2 为例, 其中:

  1. http,是协议;
  2. zh.wikipedia.org,是服务器;
  3. 80,是服务器上的网络端口号;
  4. /w/index.php,是路径;
  5. ?title=Special:%E9%9A%8F%E6%9C%BA%E9%A1%B5%E9%9D%A2,是询问。

大多数网页浏览器不要求用户输入网页中“http://”的部分,因为绝大多数网页内容是超文本传输协议文件。同样,“80”是超文本传输协议文件的常用端口号,因此一般也不必写明。一般来说用户只要键入统一资源定位符的一部分(zh.wikipedia.org/wiki/Special:%E9%9A%8F%E6%9C%BA%E9%A1%B5%E9%9D%A2)就可以了。

由于超文本传输协议允许服务器将浏览器重定向到另一个网页地址,因此许多服务器允许用户省略网页地址中的部分,比如 www。从技术上来说这样省略后的网页地址实际上是一个不同的网页地址,浏览器本身无法决定这个新地址是否通,服务器必须完成重定向的任务。

url其它使用

统一资源定位符不但被用作网页地址,JDBC 客户端也使用统一资源定位符连接其数据库服务器。作为对比,ODBC 的连接字符串作用相同,但并不采用 URL 格式,而是分号和等号分隔的键值对。

以下是一个 Oracle 数据库的统一资源定位符:

jdbc:datadirect:oracle://myserver:1521;sid=testdb

--------------- ---------------- ----------------

URI文法由URI协议名(例如“http”,“ftp”,“mailto”或“file”),一个冒号,和协议对应的内容所构成。特定的协议定义了协议内容的语法和语义,而所有的协议都必须遵循一定的URI文法通用规则,亦即为某些专门目的保留部分特殊字符。URI文法同时也就各种原因对协议内容加以其他的限制,例如,保证各种分层协议之间的协同性。百分号编码也为URI提供附加信息。

通用URI的格式如下:

scheme:[//[user[:password]@]host[:port]][/path][?query][#fragment]

 

下图展示了两个 URI 例子及它们的组成部分。

                    hierarchical part
        ┌───────────────────┴─────────────────────┐
                    authority               path
        ┌───────────────┴───────────────┐┌───┴────┐
  abc://username:password@example.com:123/path/data?key=value&key2=value2#fragid1
  └┬┘   └───────┬───────┘ └────┬────┘ └┬┘           └─────────┬─────────┘ └──┬──┘
scheme  user information     host     port                  query         fragment

  urn:example:mammal:monotreme:echidna
  └┬┘ └──────────────┬───────────────┘
scheme              path

绝对URI的例子

  • http://example.org/absolute/URI/with/absolute/path/to/resource.txt
  • ftp://example.org/resource.txt
  • urn:issn:1535-3613

URI引用的例子

  • http://en.wikipedia.org/wiki/URI#Examples_of_URI_references ("http" 指定协议名, "en.wikipedia.org"是“典据”, "/wiki/URI"是指向英文维基页面的“路径”,而"#Examples_of_URI_references"是指向英文维基页面相应片段的“片段”。)
  • http://example.org/absolute/URI/with/absolute/path/to/resource.txt
  • //example.org/scheme-relative/URI/with/absolute/path/to/resource.txt
  • /relative/URI/with/absolute/path/to/resource.txt
  • relative/path/to/resource.txt
  • ../../../resource.txt
  • ./resource.txt#frag01
  • resource.txt
  • #frag01
  • (空字符串)

绝对URL和相对URL

我们上面看到的是一个绝对的URL,但也有一个叫做相对URL的东西。我们来看看这个区别意味着什么呢?

URL的必需部分在很大程度上取决于使用URL的上下文。在浏览器的地址栏中,网址没有任何上下文,因此您必须提供一个完整的(或绝对的)URL,就像我们上面看到的一样。您不需要包括协议(浏览器默认使用HTTP)或端口(仅当目标Web服务器使用某些异常端口时才需要),但URL的所有其他部分都是必需的。

当文档中使用URL时,例如HTML页面中的内容有所不同。因为浏览器已经有文档自己的URL,它可以使用这些信息来填写该文档中可用的任何URL的缺失部分。我们可以通过仅查看URL的路径部分来区分绝对URL和相对URL。如果URL的路径部分以“/”字符开头,则浏览器将从服务器的顶部根目录获取该资源,而不引用当前文档给出的上下文

我们来看一些例子来使这个更清楚。

绝对URL示例

完整网址(与之前使用的网址相同)
https://developer.mozilla.org/en-US/docs/Learn
隐去协议
//developer.mozilla.org/en-US/docs/Learn

在这种情况下,浏览器将使用与用于加载该URL的文档相同的协议来调用该URL。

隐去域名
/en-US/docs/Learn

这是HTML文档中绝对URL最常见的用例。浏览器将使用与用于加载托管该URL的文档相同的协议和相同的域名。注意:不可能省略该域名而不省略协议。

相对URL示例

为了更好地了解以下示例,我们假设从位于以下URL的文档中调用URL: https://developer.mozilla.org/en-US/docs/Learn

子资源
Skills/Infrastructure/Understanding_URLs

因为该URL不以/开头,浏览器将尝试在包含当前资源的子目录中查找文档。所以在这个例子中,我们真的想要达到这个URLhttps://developer.mozilla.org/en-US/docs/Learn/Skills/Infrastructure/Understanding_URLs

回到目录树中
../CSS/display

在这种情况下,我们使用从UNIX文件系统世界继承的../写入约定来告诉我们要从一个目录上升的浏览器。在这里,我们要达到以下URL:https://developer.mozilla.org/en-US/docs/Learn/../CSS/display,可以将其简化为:https://developer.mozilla.org/en-US/docs/CSS/display

  • path component, consisting of a sequence of path segments separated by a slash (/). A path is always defined for a URI, though the defined path may be empty (zero length). A segment may also be empty, resulting in two consecutive slashes (//) in the path component. A path component may resemble or map exactly to a file system path, but does not always imply a relation to one. If an authority component is present, then the path component must either be empty or begin with a slash (/). If an authority component is absent, then the path cannot begin with an empty segment, that is with two slashes (//), as the following characters would be interpreted as an authority component.The final segment of the path may be referred to as a 'slug'.

 

文章来源参考资料:

https://zh.wikipedia.org/wiki/%E7%BB%9F%E4%B8%80%E8%B5%84%E6%BA%90%E5%AE%9A%E4%BD%8D%E7%AC%A6

https://zh.wikipedia.org/wiki/%E7%BB%9F%E4%B8%80%E8%B5%84%E6%BA%90%E6%A0%87%E5%BF%97%E7%AC%A6

https://en.wikipedia.org/wiki/URL

https://en.wikipedia.org/wiki/Uniform_Resource_Identifier

https://zh.wikipedia.org/wiki/%E8%B7%AF%E5%BE%84_(%E8%AE%A1%E7%AE%97%E6%9C%BA%E7%A7%91%E5%AD%A6)

https://developer.mozilla.org/zh-CN/docs/Learn/Common_questions/What_is_a_URL

 

 

个人简单总结其中一个知识点自己的理解(也许可能有误,自行斟酌):首先就是路径一定要是以/开头。如果不是则会出现错误。其次可以理解为域名最后面的那个/表示指向网址根目录。

 

-------------下方测试均在windows10 wamp环境测试-----------

-------------其他环境下会有很大差异,不要同理。了解大概意思即可------------

现在开始讲解“../”,它代表的是返回上一级目录。例如:

一、https://woj.app  请求“” 无法请求。If the abs_path is not present in the URL, it MUST be given as "/" when used as a Request-URI for a resource (section 5.1.2).参考最下方资料的最后两条。

 

二、https://woj.app  请求“/”    正常的请求。指向网址根目录(再多个/也是根目录)   d:/wwwroot/

 

三、https://woj.app  请求“../” 结果是错误的。可以理解为跟第一个是一样的。看错误日志就能看出。(同时都有404)

[core:error] [pid 9988:tid 604] [client 127.0.0.1:58034] AH00126: Invalid URI in request GET HTTP/1.1
[core:error] [pid 9988:tid 604] [client 127.0.0.1:58809] AH00126: Invalid URI in request GET ../ HTTP/1.1

而“../” 则是返回上一级目录。也许可以理解为“三”的请求最后变成了“一”,或者说没有找到“../”这个目录(这句话不一定准,我自己这么理解的吧)。跟“一”也许可能还有些区别。那如果再加一个/呢,继续分析。

 

四、https://woj.app  请求“..//”  结果变成了“二”。正确的,指向了根目录 d:/wwwroot/

 

五、https://woj.app  请求“xxxx/”  这里结果跟“三”是一样的,错误的,程序找不到对应目录,则错误并404。

 

六、https://woj.app  请求“xxxx//”  这里结果跟“三”还是一样的,错误的,因为请求内容并不具备“三”的属性,不会返回上一级。

 

七、https://woj.app  请求“xxxx/../” 这里结果跟“一”是一样的,错误的,但是注意,这里因为请求中有“../”所以这里的请求会略过“xxxx/”变成“一”。

 

八、https://woj.app  请求“xxxx/..//”  这里结果跟“二”是一样的。正确的。


现在开始讲解“./”,它代表的是当前目录。例如:

一、https://woj.app  请求“./”  结果是错误的,无法请求,跟上方的“一、三”是一样的。

二、https://woj.app  请求“.//”  结果是正确的,正常的请求,它的理解应该是跟上方的“四”是一样的。

 

这里还有一个比较注意的点,组合路径的时候“../”前面必须是“\”或“/”否则这个“../”就不会生效。

上面讲的所有例子,凡是正确的注意看 REQUEST_URI 的值,都是不一样的哦。但是能出现同样的结果。

 

文章来源参考资料:

https://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.2.1

https://www.w3.org/Protocols/rfc2616/rfc2616-sec5.html

布施恩德可便相知重

微信扫一扫打赏

支付宝扫一扫打赏

×

给我留言