哪些字符使URL无效?
这些url是否有效?
example.com/file [/] . html http://example.com/file [/] . html
哪些字符使URL无效?
这些url是否有效?
example.com/file [/] . html http://example.com/file [/] . html
当前回答
通常,RFC 3986定义的uri(参见章节2:字符)可以包含以下84个字符中的任意一个:
ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789-._~:/?#[]@!$&'()*+,;=
注意,这个列表没有说明这些字符可能出现在URI中的哪个位置。
任何其他字符都需要使用百分比编码(%hh)进行编码。URI的每个部分对于百分比编码的单词需要表示哪些字符有进一步的限制。
其他回答
在这个例子中,“[”和“]”是“不明智的”字符,但仍然是合法的。如果[]中的'/'是文件名的一部分,那么它是无效的,因为'/'是保留的,应该正确编码:
http://example.com/file[/].html
为了澄清并直接解决上面的问题,有几种类型的字符会导致url和uri出现问题。
There are some characters that are disallowed and should never appear in a URL/URI, reserved characters (described below), and other characters that may cause problems in some cases, but are marked as "unwise" or "unsafe". Explanations for why the characters are restricted are clearly spelled out in RFC-1738 (URLs) and RFC-2396 (URIs). Note the newer RFC-3986 (update to RFC-1738) defines the construction of what characters are allowed in a given context but the older spec offers a simpler and more general description of which characters are not allowed with the following rules.
URI语法中不允许的US-ASCII字符:
control = <US-ASCII coded characters 00-1F and 7F hexadecimal>
space = <US-ASCII coded character 20 hexadecimal>
delims = "<" | ">" | "#" | "%" | <">
字符“#”被排除在外,因为它用于将URI与片段标识符分隔开来。百分比字符“%”被排除,因为它用于转义字符的编码。换句话说,“#”和“%”是保留字符,必须在特定的上下文中使用。
不明智的字符列表是允许的,但可能会导致问题:
unwise = "{" | "}" | "|" | "\" | "^" | "[" | "]" | "`"
在查询组件中保留的字符和/或在URI/URL中具有特殊含义的字符:
reserved = ";" | "/" | "?" | ":" | "@" | "&" | "=" | "+" | "$" | ","
上面的“保留”语法类指的是在URI中允许的字符,但在通用URI语法的特定组件中可能不允许这些字符。“保留”集中的字符并非在所有上下文中都是保留的。例如,主机名可以包含一个可选的用户名,所以它可以是ftp://user@hostname/,其中“@”字符具有特殊含义。
下面是一个URL的例子,它有无效和不明智的字符(例如:'$', '[', ']'),并且应该正确编码:
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异常,因此像http://api.google.com/q?exp=a|b这样的URL是不允许的,如果使用Java的URI对象实例,则必须将其编码为http://api.google.com/q?exp=a%7Cb。
通常,RFC 3986定义的uri(参见章节2:字符)可以包含以下84个字符中的任意一个:
ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789-._~:/?#[]@!$&'()*+,;=
注意,这个列表没有说明这些字符可能出现在URI中的哪个位置。
任何其他字符都需要使用百分比编码(%hh)进行编码。URI的每个部分对于百分比编码的单词需要表示哪些字符有进一步的限制。
在你的补充问题中,你问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。
我提出了一些PHP正则表达式,可以将文本中的url转换为锚标记。(首先它转换所有的www。url到http://,,然后转换所有的url与https?:// to a href=…HTML链接
美元管柱= preg_replace (' / (https ?:\/\/)([!#$&-;=?\-\[\]_ a - z ~ %] +) / sim’,'“$ 1 $ 2”< a href = > $ 2 < / a > ', preg_replace(' /(±s) ( \.)([!#$&-;=?\-\[\]_ a - z ~ %] +) / sim’' $ 1http: / / $, $管柱));
来源(需要时加强调):
Unsafe: Characters can be unsafe for a number of reasons. The space character is unsafe because significant spaces may disappear and insignificant spaces may be introduced when URLs are transcribed or typeset or subjected to the treatment of word-processing programs. The characters "<" and ">" are unsafe because they are used as the delimiters around URLs in free text; the quote mark (""") is used to delimit URLs in some systems. The character "#" is unsafe and should always be encoded because it is used in World Wide Web and in other systems to delimit a URL from a fragment/anchor identifier that might follow it. The character "%" is unsafe because it is used for encodings of other characters. Other characters are unsafe because gateways and other transport agents are known to sometimes modify such characters. These characters are "{", "}", "|", "", "^", "~", "[", "]", and "`". All unsafe characters must always be encoded within a URL. For example, the character "#" must be encoded within URLs even in systems that do not normally deal with fragment or anchor identifiers, so that if the URL is copied into another system that does use them, it will not be necessary to change the URL encoding. Source