Большинство существующих ответов здесь нецелесообразно, поскольку они полностью игнорируют реальное использование адресов, таких как:
Во-первых, отступление от терминологии? Что являются этими адресами? Это действительные URL-адреса?
Исторически ответом было «нет». Согласно RFC 3986 , с 2005 года такие адреса не являются URI (и, следовательно, не являются URL, поскольку URL являются типом URI ). Согласно терминологии стандартов IETF 2005 года, мы должны правильно называть их IRI (интернационализированные идентификаторы ресурсов), как определено в RFC 3987 , которые технически не являются URI, но могут быть преобразованы в URI просто путем процентного кодирования всех не -ASCII символы в IRI.
В соответствии с современной спецификацией ответ - «да». WHATWG Living Standard просто классифицирует все, что раньше называлось "URIs" или "IRIs", как "URL-адреса". Это согласовывает терминологию specced с тем, как обычные люди, которые не читали спецификацию, используют слово «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» не включает %, но что % разрешены в «кодовых единицах URL», если они являются частью последовательности кодирования процентов.)
Единственное место, где я могу определить, где спецификация позволяет использовать любой символ, который не в этом наборе, находится на хосте , где адреса IPv6 заключены в [ и ] символов. В других местах URL-адреса разрешены либо единицы измерения URL, либо еще более ограничительный набор символов.
Какие символы были разрешены в старых RFC?
Ради истории, и поскольку он не был полностью исследован в других разделах ответов, давайте рассмотрим, что было разрешено в соответствии со старшей парой спецификаций.
Прежде всего, у нас есть два типа RFC: 3986 зарезервированные символы :
:/?#[]@, которые являются частью общего синтаксиса для URI, определенного в RFC 3986 !$&'()*+,;=, которые не являются частью общего синтаксиса RFC, но зарезервированы для использования в качестве синтаксических компонентов определенных схем URI. Например, точки с запятой и запятые используются как часть синтаксиса URI данных , а & и = используются как часть вездесущего формата ?foo=bar&qux=baz в строках запроса (который не указано RFC 3986).
Любой из вышеупомянутых зарезервированных символов может по закону использоваться в URI без кодирования, либо для выполнения их синтаксической цели, либо просто как буквальные символы в данных в некоторых местах, где такое использование не может быть неверно истолковано как символ, служащий его синтаксической цели. (Например, хотя / имеет синтаксическое значение в URL-адресе, вы можете использовать его без кодировки в строке запроса, поскольку не не имеет значения в строке запроса.)
RFC 3986 также указывает некоторые незарезервированные символов, которые всегда можно использовать просто для представления данных без какой-либо кодировки:
abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789-._~
Наконец, сам символ % разрешен для процентного кодирования.
Это оставляет только следующие символы ASCII, которым запрещено появляться в URL:
- Управляющие символы (символы 0-1F и 7F), включая новую строку, символ табуляции и возврат каретки.
"<>\^`{|}
Каждый другой символ из ASCII может быть юридически представлен в URL.
Затем RFC 3987 расширяет этот набор незарезервированных символов следующими диапазонами символов Юникода:
%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-адреса. Например, зарезервированные символы [ и ] являются допустимыми как часть литерального хоста IPv6 в URL-адресе, подобном http://[1080::8:800:200C:417A]/foo, но недопустимы в любом другом контексте, поэтому пример OP http://example.com/file[/].html незаконно.