http url 的path究竟可以包含哪些字符?

本文深入探讨了HTTP URL路径部分的字符规则,通过解析RFC1738文件,明确了路径段(pathsegment)中允许出现的字符类型,解答了为什么一些看似奇怪的URL实际上是合法的问题。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

你觉得下面这些看起来像url的东西是啥?

http://my.oschina.net/@&/;:=***/new-blog
http://my.oschina.net/*+/-9!/new-blog
http://my.oschina.net/*+/-9!/+-_)(

其实它们也是url,而且但从语义和语法来讲,它们都是正确的url,但是osc肯定没有这些url所对应的资源(我试过了^_^)。

因为开发mvc时,我要解析url中 path 部分,就要知道path中能包含什么字符,所以就研究rfc中关于url的path部分的定义。

一个典型的http url 大概是长这样的(只讨论你手动在浏览器中输入url的情况):

http://bornmoney.com/money/rmb?quantity=1000000

它的结构分析如下:

part data
协议 http
协议和主机名的分隔符 ://
主机 bornmoney.com
查询路径 /money/rmb
路径与查询参数的分隔符 ?
查询参数 quantity=1000000

本文讨论内容局限在“查询路径”部分,探讨查询路径中每个path segment(上表中的money or rmb)最终所能包含的字符。

开始在网上找了好久都找到满意的答案,全部都是说url中 哪些字符需要转码,而哪些字符不需要转码的。至于最终哪些字符会出现在path segment上,并没有直接说明。最终只能自己动手了——查rfc文件。

rfc1738文件的17~18页中有关于http url的语法和文法定义。我后来把与path segment相关的部分摘抄如下:

httpurl        = "http://" hostport [ "/" hpath [ "?" search ]]
hpath          = hsegment *[ "/" hsegment ]
hsegment       = *[ uchar | ";" | ":" | "@" | "&" | "=" ]
uchar          = unreserved | escape
unreserved     = alpha | digit | safe | extra
alpha          = lowalpha | hialpha
lowalpha       = "a" | "b" | "c" | "d" | "e" | "f" | "g" | "h" |
                 "i" | "j" | "k" | "l" | "m" | "n" | "o" | "p" |
                 "q" | "r" | "s" | "t" | "u" | "v" | "w" | "x" |
                 "y" | "z"
hialpha        = "A" | "B" | "C" | "D" | "E" | "F" | "G" | "H" | "I" |
                 "J" | "K" | "L" | "M" | "N" | "O" | "P" | "Q" | "R" |
                 "S" | "T" | "U" | "V" | "W" | "X" | "Y" | "Z"
digit          = "0" | "1" | "2" | "3" | "4" | "5" | "6" | "7" | "8" | "9"
safe           = "$" | "-" | "_" | "." | "+"
extra          = "!" | "*" | "'" | "(" | ")" | ","
escape         = "%" hex hex
hex            = digit | "A" | "B" | "C" | "D" | "E" | "F" | "a" | "b" | "c" | "d" | "e" | "f"

一开始我看不懂那个定义到底是怎么回事,后来才知道这是用 扩充巴科斯-瑙尔范式(ABNF)定义的,关于ABNF的规则较多,可以参考这里:http://zh.wikipedia.org/zh/扩充巴科斯范式

用ABNF范式去解读 rfc1738 对http url的定义,我们就知道定义规则右边出现的所有字符都可以出现在path segment中,这就能解释开头哪些奇怪的url居然是正确的了。


部分参考资料:

每个 Web 开发者都应该知道的关于 URL 编码的知识

关于URL编码

RFCEditor

其他的忘了

转载于:https://my.oschina.net/cnlw/blog/355234

<think>好的,用户的问题是关于HTTP POST请求中URL包含哪些字段。我需要先回顾一下HTTP请求的基本结构,特别是POST请求的相关知识。 根据引用[4],HTTP请求分为三个部分:请求行、请求头和请求体。对于POST请求来说,URL通常出现在请求行中,而请求体则用来传输数据。不过用户问的是URL包含哪些字段,可能需要更具体的信息。 在引用[2]中提到,params用于GET请求的URL参数,形成查询字符串。但POST请求是否也会在URL中带参数呢?根据引用[1],POST请求的数据默认在请求体中,而params通常用于GET的查询字符串。不过有些情况下,POST请求的URL也可能带有查询参数,比如需要同时传递路径参数和提交数据的情况。 引用[3]指出,POST请求的数据放在消息主体中,编码方式由开发者决定。但URL部分的结构应该和GET请求类似,包含路径和可能的查询参数。因此,POST请求的URL字段可能包括协议、域名、端口、路径和查询字符串,但查询字符串在这里的作用可能与GET不同,比如用于标识资源的不同状态或分页信息。 总结下来,POST请求的URL结构通常由以下几个部分组成: 1. 协议(如HTTP/HTTPS) 2. 域名或IP地址 3. 端口(可选,默认HTTP是80,HTTPS是443) 4. 路径(资源的位置) 5. 查询字符串(Query String,以?开头,键值对形式) 不过需要注意,POST请求的查询参数并不常见,更多数据是通过请求体发送的。例如,一个POST请求的URL可能是`https://api.example.com/resource?page=2`,其中查询参数page=2用于分页,而实际提交的数据在请求体中。 需要验证引用中的内容是否支持这一点。引用[1]提到params用于GET请求的URL参数,但并没有明确禁止POST使用查询参数。引用[3]说明POST的数据在消息主体,但URL的结构仍然可以包含路径和查询参数。因此,正确的回答应该是POST请求的URL包含协议、域名、端口、路径和可选的查询字符串,但主要的数据传输在请求体中。</think>HTTP POST 请求的 URL 字段组成与 GET 请求类似,但数据传递方式存在显著差异。以下是其包含的字段解析: 1. **协议与域名** - 格式为 `协议://域名(或IP地址):端口号/路径` - 例如:`https://api.example.com:8080/users` - 端口号可省略(默认HTTP为80,HTTPS为443) 2. **路径(Path)** - 表示资源位置,如 `/users` 或 `/data/upload` - 支持RESTful风格路径参数,如 `/users/{id}` 3. **查询字符串(Query String)** - 以 `?` 开头,键值对用 `&` 连接,如 `?page=2&category=books` - **与GET的区别**:POST的查询参数通常用于过滤/标识资源,而非传递主要数据[^1][^2] ```python # 示例:带查询参数的POST请求(Python requests库) import requests url = "https://api.example.com/data?source=external" data = {"content": "test"} response = requests.post(url, data=data) ``` 4. **特殊说明** - POST请求的**核心数据**通过请求体(Body)传输,支持多种编码格式(如`application/x-www-form-urlencoded`、`multipart/form-data`等)[^3][^4] - URL中的查询参数与请求体可**同时存在**,但设计上应保持语义清晰(如用路径参数标识资源,查询参数过滤数据,请求体提交内容)
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值