哪些字符使網址無效? html
這些有效的網址是? java
example.com/file[/].html
http://example.com/file[/].html
爲了添加一些說明並直接解決上面的問題,有幾類字符會致使URL和URI出現問題。 正則表達式
有些字符是不容許的,不該出如今URL / URI,保留字符(以下所述)中,以及在某些狀況下可能致使問題的其餘字符,但標記爲「不明智」或「不安全」。 RFC-1738 (URL)和RFC-2396 (URI)中明確說明了字符受限制的緣由。 請注意,較新的RFC-3986 (對RFC-1738的更新)定義了給定上下文中容許使用哪些字符的構造,但較舊的規範提供了對如下規則不容許哪些字符的更簡單和更通常的描述。 編程
URI語法中不容許排除的US-ASCII字符: api
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/
,其中'@'字符具備特殊含義。 google
如下是包含無效和不明智字符的網址示例(例如'$','[',']'),而且應正確編碼: 編碼
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
。
不是你的問題的答案,但驗證網址確實是一個嚴重的皮塔餅你可能只是更好地驗證域名並留下網址的查詢部分。 這是個人經歷。 您也可使用ping網址並查看它是否會產生有效的響應,但這對於這麼簡單的任務來講可能太多了。
檢測網址的正則表達式很豐富,google it :)
能夠在URI中使用的全部有效字符( URL是一種URI )在RFC 3986中定義。
全部其餘字符均可以在URL中使用,前提是它們首先是「URL編碼」。 這涉及更改特定「代碼」的無效字符(一般以百分號(%)後跟十六進制數字的形式)。
此連接HTML URL編碼參考包含無效字符的編碼列表。
一般, RFC 3986定義的URI(請參閱第2節:字符 )能夠包含如下任何字符:
ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789-._~:/?#[]@!$&'()*+,;=
請注意,此列表未說明URI中可能出現這些字符的位置。
任何其餘字符都須要使用百分比編碼( %
hh
)進行編碼。 URI的每一個部分對於須要由百分比編碼的單詞表示的字符有進一步的限制。
在您的補充問題中,您詢問www.example.com/file[/].html
是否爲有效的網址。
該URL無效,由於URL是一種URI,有效的URI必須具備http:
參見RFC 3986 )。
若是您打算詢問http://www.example.com/file[/].html
是不是有效的網址,則答案仍然是否認的,由於方括號字符在那裏無效。
方括號字符是爲如下格式的URL保留的: http://[2001:db8:85a3::8a2e:370:7334]/foo/bar
(即IPv6文字而不是主機名)
若是你想徹底理解這個問題,那麼值得仔細閱讀RFC 3986。