goo*_*ood 486 validation url rfc3986
哪些字符使网址无效？
这些有效的网址是？
example.com/file[/].htmlhttp://example.com/file[/].htmlGum*_*mbo 568
通常,RFC 3986定义的URI (请参阅第2节:字符)可以包含以下任何字符:
ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789-._~:/?#[]@!$&'()*+,;=
请注意,此列表未说明URI中可能出现这些字符的位置.
任何其他字符都需要使用percent-encoding(%hh)进行编码.URI的每个部分对于需要由百分比编码的单词表示的字符有进一步的限制.
Jas*_*nM1 183
为了添加一些说明并直接解决上面的问题,有几类字符会导致URL和URI出现问题.
有些字符是不允许的,不应出现在URL/URI,保留字符(如下所述)中,以及在某些情况下可能导致问题的其他字符,但标记为"不明智"或"不安全".RFC-1738(URL)和RFC-2396(URI)中明确说明了字符受限制的原因.请注意,较新的RFC-3986(对RFC-1738的更新)定义了在给定上下文中允许使用哪些字符的构造,但较旧的规范提供了对以下规则不允许哪些字符的更简单和更一般的描述.
URI语法中不允许排除的US-ASCII字符:
control = <US-ASCII coded characters 00-1F and 7F hexadecimal>
space = <US-ASCII coded character 20 hexadecimal>
delims = "<" | ">" | "#" | "%" | <">
允许列出不明智的字符,但可能会导致问题:
unwise = "{" | "}" | "|" | "\" | "^" | "[" | "]" | "`"
在查询组件中保留的字符和/或在URI/URL中具有特殊含义:
reserved = ";" | "/" | "?" | ":" | "@" | "&" | "=" | "+" | "$" | ","
上面的"保留"语法类指的是URI中允许的那些字符,但在通用URI语法的特定组件中可能不允许这些字符."保留"集中的字符不会在所有上下文中保留.例如,主机名可以包含可选的用户名,因此它可能类似于ftp://user@hostname/'@'字符具有特殊含义的地方.
以下是包含无效和不明智字符的网址示例(例如'$','[',']'),并且应正确编码:
http://mw1.google.com/mw-earth-vectordb/kml-samples/gp/seattle/gigapxl/$[level]/r$[y]_c$[x].jpg
URI/URL的一些字符限制是依赖于编程语言的.例如,'|' (0x7C)字符虽然在URI规范中仅标记为"不明智",但会在Java java.net.URI构造函数中抛出URISyntaxException,因此不允许使用URL,而必须编码,就像使用带有URI对象实例的Java一样.http://api.google.com/q?exp=a|bhttp://api.google.com/q?exp=a%7Cb
Mar*_*ery 79
这里的大多数现有答案都是不切实际的,因为它们完全忽略了地址的实际使用情况,例如:
好的,所以根据RFC 3986,这样的地址不是URI(因此不是URL,因为URL 是一种URI).如果我们认为自己受惠于现有的IETF标准的术语,那么我们应该正确地调用它们的IRI(国际化资源标识符),如定义RFC 3987,这在技术上不是URI的,但可以通过简单地转换为URI的百分之编码所有非-IRI中的-ASCII字符.正常的人,但是,从来没有听说过虹膜和简单地调用这些URI或URL(实际上有一个WHATWG的努力正在创造一个新的,更广阔的URL规范,简单地分类所有"的URI"和"IRIS"的"网址"对齐在现实世界中现代使用这些术语).
假设我们想立即采用URL的这个含义(这与IETF规范不一致,但是我们将其与日常用法联系起来).在这种情况下,哪些字符在URL中有效？
首先,我们有两种类型的RFC 3986 保留字符:
%,这是RFC 3986中定义的URI的通用语法的一部分%,它们不是RFC的通用语法的一部分,但保留用作特定URI方案的语法组件.例如,分号和逗号被用作的语法的一部分的数据的URI,并[和]被用作普遍存在的一部分:/?#[]@在查询字符串格式(其未由RFC 3986规定).上面的任何保留字符都可以在没有编码的URI中合法使用,既可以用于语法目的,也可以作为数据中的文字字符,在某些地方,这些使用不能被误解为服务于其语法目的的字符.(例如,虽然!$&'()*+,;=在URL中具有语法含义,但您可以在查询字符串中使用未编码的,因为它在查询字符串中没有意义.)
RFC 3986还指定了一些未保留的字符,这些字符总是可以简单地用于表示没有任何编码的数据:
&最后,=允许字符本身进行百分比编码.
只留下以下禁止出现在URL中的ASCII字符:
?foo=bar&qux=bazASCII中的每个其他字符都可以合法地显示在URL中.
然后RFC 3987使用以下unicode字符范围扩展该组未保留字符:
%xA0-D7FF / %xF900-FDCF / %xFDF0-FFEF
/ %x10000-1FFFD / %x20000-2FFFD / %x30000-3FFFD
/ %x40000-4FFFD / %x50000-5FFFD / %x60000-6FFFD
/ %x70000-7FFFD / %x80000-8FFFD / %x90000-9FFFD
/ %xA0000-AFFFD / %xB0000-BFFFD / %xC0000-CFFFD
/ %xD0000-DFFFD / %xE1000-EFFFD
但鉴于最新的Unicode 块定义,这些块选择看起来很奇怪和随意; 这可能是因为在编写RFC 3987之后的十年中已经添加了块.WhatWG正在进行的规范有一个更慷慨的列表:
U + 00A0到U + D7FF,U + E000到U + FDCF,U + FDF0到U + FFFD,U + 10000到U + 1FFFD,U + 20000到U + 2FFFD,U + 30000到U + 3FFFD,U + 40000到U + 4FFFD,U + 50000到U + 5FFFD,U + 60000到U + 6FFFD,U + 70000到U + 7FFFD,U + 80000到U + 8FFFD,U + 90000到U + 9FFFD,U + A0000至U + AFFFD,U + B0000到U + BFFFD,U + C0000到U + CFFFD,U + D0000到U + DFFFD,U + E0000到U + EFFFD,U + F0000到U + FFFFD,U + 100000到U + 10FFFD
当然,应该注意的是,仅仅知道哪些字符可以合法地出现在URL中不足以识别某些给定字符串是否是合法URL,因为某些字符仅在URL的特定部分中是合法的.例如,保留字符/和abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789-._~是合法的,因为在像URL的IPv6文字主机的一部分的http:// [1080 :: 8:800:200℃:417A] /富但不合法的任何其他上下文中,所以OP的例子%是非法的.
Dom*_*ers 19
在您的补充问题中,您询问是否www.example.com/file[/].html是有效的URL.
该URL无效,因为URL是一种URI,有效的URI必须具有类似的方案http:(参见RFC 3986).
如果您打算询问是否http://www.example.com/file[/].html是有效的URL,则答案仍然是否定的,因为方括号字符在那里无效.
方括号字符是为此格式的URL保留的:( http://[2001:db8:85a3::8a2e:370:7334]/foo/bar即IPv6文字而不是主机名)
如果你想完全理解这个问题,那么值得仔细阅读RFC 3986.
Cra*_*gTP 11
可以在URI中使用的所有有效字符(URL是一种URI)在RFC 3986中定义.
所有其他字符都可以在URL中使用,前提是它们首先是"URL编码".这涉及更改特定"代码"的无效字符(通常以百分号(%)后跟十六进制数字的形式).
此链接HTML URL编码参考包含无效字符的编码列表.
一些Unicode字符范围是有效的HTML5,尽管使用它们可能仍然不是一个好主意.
例如,href文档说http://www.w3.org/TR/html5/links.html#attr-hyperlink-href:
a和area元素上的href属性必须具有可能由空格包围的有效URL的值.
然后,"有效网址"的定义指向http://url.spec.whatwg.org/,该网站的目的是:
将RFC 3986和RFC 3987与当代实现保持一致,并在此过程中废弃它们.
该文档将URL代码点定义为:
ASCII字母数字,"!","$","&","'","(",")","*","+",","," - ",".","/" ,":",";","=","？","@","_","〜"和代码点的范围为U + 00A0至U + D7FF,U + E000至U + FDCF ,U + FDF0至U + FFFD,U + 10000至U + 1FFFD,U + 20000至U + 2FFFD,U + 30000至U + 3FFFD,U + 40000至U + 4FFFD,U + 50000至U + 5FFFD,U +60000到U + 6FFFD,U + 70000到U + 7FFFD,U + 80000到U + 8FFFD,U + 90000到U + 9FFFD,U + A0000到U + AFFFD,U + B0000到U + BFFFD,U + C0000到U + CFFFD,U + D0000到U + DFFFD,U + E1000到U + EFFFD,U + F0000到U + FFFFD,U + 100000到U + 10FFFD.
然后在语句中使用术语"URL代码点":
如果c不是URL代码点而不是"%",则解析错误.
在解析算法的几个部分,包括模式,权限,相对路径,查询和片段状态:所以基本上是整个URL.
此外,验证器http://validator.w3.org/传递的URL类似于"??",并且不传递具有空格等字符的URL"a b"
当然,正如Stephen C所提到的,它不仅仅是关于角色,还关系到背景:你必须要理解整个算法.但是由于类"URL代码点"用于算法的关键点,它可以很好地了解您可以使用或不使用的内容.
另请参见:URL中的Unicode字符
我需要选择字符来分割字符串中的URL,所以我决定创建自己无法在URL中找到的字符列表:
>>> allowed = "-_.~!*'();:@&=+$,/?%#[]?@ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789"
>>> from string import printable
>>> ''.join(set(printable).difference(set(allowed)))
'`" <\x0b\n\r\x0c\\\t{^}|>'
因此,可能的选择是换行符,制表符,空格,反斜杠和"<>{}^|.我想我会选择空格或换行符.:)
这并不是您问题的真正答案，但验证 URL 确实是一个严重的问题。您可能最好验证域名并保留 URL 的查询部分。这是我的经验。
您还可以对 URL 进行 ping 操作，看看是否会产生有效的响应，但这对于这样一个简单的任务来说可能太过了。
检测 URL 的正则表达式很丰富，google 一下:)
| 归档时间： |
|
| 查看次数： |
472970 次 |
| 最近记录： |