在你的补充问题中，你问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。

在你的补充问题中，你问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。

通常，RFC 3986定义的uri(参见章节2:字符)可以包含以下84个字符中的任意一个:

ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789-._~:/?#[]@!$&'()*+,;=

注意，这个列表没有说明这些字符可能出现在URI中的哪个位置。

任何其他字符都需要使用百分比编码(%hh)进行编码。URI的每个部分对于百分比编码的单词需要表示哪些字符有进一步的限制。

我正在实现一个旧的HTTP(0.9, 1.0, 1.1)请求和响应读取器/写入器。请求URI是最有问题的地方。

你不能只使用RFC 1738、2396或3986。有许多旧的HTTP客户端和服务器允许更多的字符。因此，我根据意外发布的web服务器访问日志进行了研究:“GET URI HTTP/1.0”200。

我发现在uri中经常使用以下非标准字符:

\ { } < > | ` ^ "

这些字符在RFC 1738中被描述为不安全的。

如果你想兼容所有旧的HTTP客户端和服务器，你必须允许这些字符出现在请求URI中。

请在oghttp-request-collector中阅读更多关于这项研究的信息。

我提出了一些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: / / $, $管柱));

一些Unicode字符范围是有效的HTML5，尽管使用它们可能仍然不是一个好主意。

例如，href文档说http://www.w3.org/TR/html5/links.html#attr-hyperlink-href:

a和area元素上的href属性必须具有一个有效的URL值，该值可能被空格包围。

那么“有效URL”的定义指向http://url.spec.whatwg.org/，它说它的目标是:

将RFC 3986和RFC 3987与当代实现对齐，并在此过程中淘汰它们。

该文档将URL代码点定义为:

ASCII alphanumeric, "!", "$", "&", "'", "(", ")", "*", "+", ",", "-", ".", "/", ":", ";", "=", "?", "@", "_", "~", and code points in the ranges U+00A0 to U+D7FF, U+E000 to U+FDCF, U+FDF0 to U+FFFD, U+10000 to U+1FFFD, U+20000 to U+2FFFD, U+30000 to U+3FFFD, U+40000 to U+4FFFD, U+50000 to U+5FFFD, U+60000 to U+6FFFD, U+70000 to U+7FFFD, U+80000 to U+8FFFD, U+90000 to U+9FFFD, U+A0000 to U+AFFFD, U+B0000 to U+BFFFD, U+C0000 to U+CFFFD, U+D0000 to U+DFFFD, U+E1000 to U+EFFFD, U+F0000 to U+FFFFD, U+100000 to U+10FFFD.

然后在语句中使用术语“URL代码点”:

如果c不是URL代码点，也不是“%”，解析错误。

在解析算法的几个部分，包括模式，权限，相对路径，查询和片段状态:所以基本上是整个URL。

同样，验证器http://validator.w3.org/会通过“你好”这样的url，而不会通过像空格“a b”这样的字符的url

当然，正如Stephen C所提到的，这不仅与字符有关，还与上下文有关:你必须理解整个算法。但由于类“URL代码点”用于算法的关键点，它提供了一个很好的想法，你可以使用或不使用。

请参见:url中的Unicode字符