所有可以在URI中使用的有效字符(URL是URI的一种类型)都在RFC 3986中定义。

所有其他字符都可以在URL中使用，只要它们是“URL编码”的。这涉及为特定的“代码”更改无效字符(通常是百分号(%)后面跟着十六进制数的形式)。

此链接HTML URL Encoding Reference包含无效字符的编码列表。

来源(需要时加强调):

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

大多数现有的答案都是不切实际的，因为它们完全忽略了地址在现实世界中的用法，比如:

https://en.wikipedia.org/wiki/Mobius_strip or https://zh.wikipedia.org/wiki/Wikipedia: about the Chinese wikipedia/en.

首先，进入术语。这些地址是什么?它们是有效的url吗?

从历史上看，答案是“不”。根据RFC 3986，从2005年开始，这样的地址不是uri(因此也不是url，因为url是uri的一种)。根据2005 IETF标准的术语，我们应该正确地称它们为IRI(国际化资源标识符)，如RFC 3987中定义的那样，它们在技术上不是uri，但可以通过简单地对IRI中的所有非ascii字符进行百分比编码来转换为uri。

根据现代规范，答案是“是的”。WHATWG生活标准简单地将以前被称为“uri”或“iri”的东西归类为“url”。这使规范术语与没有阅读规范的普通人使用“URL”这个词的方式保持一致，这是规范的目标之一。

WHATWG生活标准下允许哪些角色?

根据“URL”的新含义，允许使用哪些字符?在URL的许多部分，例如查询字符串和路径，我们被允许使用任意的“URL单位”，它们是

URL代码点和百分比编码的字节。

什么是“URL代码点”?

URL代码点是ASCII字母数字，U+0021 (!)， U+0024 ($)， U+0026 (&)， U+0027 (')， U+0028左括号，U+0029右括号，U+002A (*)， U+002B (+)， U+002C (，)， U+002D (-)， U+002E (.)， U+002F (/)， U+003A (:)， U+003B (;)， U+003D (=)， U+003F (?)， U+0040 (@)， U+005F (_)， U+007E(~)，以及U+00A0到U+10FFFD范围内的代码点，包括，不包括代理和非字符。

(请注意，“URL代码点”列表不包括%，但如果%s是百分比编码序列的一部分，则允许在“URL代码单位”中使用%s。)

我能发现的唯一一个规范允许使用不在这个集合中的任何字符的地方是在主机中，其中IPv6地址包含在[和]字符中。URL中的其他地方，要么允许URL单位，要么使用一些更严格的字符集。

旧的rfc允许哪些字符?

出于历史的考虑，由于在这里的答案中没有充分探讨，让我们检查一下旧眼镜下允许的情况。

首先，我们有两种类型的RFC 3986保留字符:

: / ?#[]@，它们是RFC 3986中定义的URI的通用语法的一部分 !$&'()*+，;=，它们不是RFC通用语法的一部分，而是保留用于特定URI方案的语法组件。例如，分号和逗号被用作数据uri语法的一部分，&和=被用作查询字符串中普遍存在的?foo=bar&qux=baz格式的一部分(RFC 3986没有指定)。

上面的任何保留字符都可以在URI中合法地使用而不进行编码，可以用于它们的语法目的，也可以作为数据中的文字字符，在某些地方这样的使用不会被误解为用于其语法目的的字符。(例如，尽管/在URL中具有语法意义，但您可以在查询字符串中使用它，因为它在查询字符串中没有意义。)

RFC 3986还指定了一些无保留字符，它们总是可以简单地用来表示没有任何编码的数据:

abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789 - _ ~

最后，允许%字符本身用于百分比编码。

这样就只留下以下ASCII字符被禁止出现在URL中:

控制字符(字符0-1F和7F)，包括换行、制表符和回车符。 “< > ^ ' {|}

来自ASCII的每一个其他字符都可以合法地出现在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编写后的十年中添加的。

---

最后，也许值得注意的是，仅仅知道哪些字符可以合法地出现在URL中还不足以识别某个给定的字符串是否是合法的URL，因为有些字符只在URL的特定部分合法。例如，保留字符[和]在像http://[1080::8:800:200C:417A]/foo这样的URL中作为IPv6字面主机的一部分是合法的，但在任何其他上下文中都是不合法的，因此OP的例子http://example.com/file[/].html是非法的。

这并不是对你的问题的真正答案，但验证URL确实是一个严肃的p.i.t.a。你可能最好验证域名，并留下URL的查询部分。这是我的经验。

您还可以通过ping URL来查看它是否会得到一个有效的响应，但是对于这样一个简单的任务来说，这可能有点太过了。

正则表达式检测url是丰富的，谷歌它:)

在这个例子中，“[”和“]”是“不明智的”字符，但仍然是合法的。如果[]中的'/'是文件名的一部分，那么它是无效的，因为'/'是保留的，应该正确编码:

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。

我正在实现一个旧的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中阅读更多关于这项研究的信息。