Какие символы делают URL недействительным?

Какие символы делают URL недействительным?

Это действительные URL?

  • example.com/file[/].html
  • http://example.com/file[/].html
вопрос задан 10.10.2009
good
2166 репутация

10 ответов


  • 519 рейтинг

    В целом URI, определенные в RFC 3986 (см. Раздел 2: символы ), могут содержать любой из следующих символов:

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

    Обратите внимание, что в этом списке не указано, где в URI могут присутствовать эти символы.

    Любой другой символ должен быть закодирован с использованием кодировки процентов (% hh ). Каждая часть URI имеет дополнительные ограничения относительно того, какие символы должны быть представлены в процентном коде слова.

    ответ дан Gumbo, с репутацией 493901, 10.10.2009
  • 144 рейтинг

    Чтобы добавить некоторые пояснения и непосредственно обратиться к вышеупомянутому вопросу, есть несколько классов символов, которые вызывают проблемы для URL-адресов и URI.

    Есть некоторые символы, которые запрещены и никогда не должны появляться в URL / URI, зарезервированных символах (описанных ниже) и других символах, которые могут вызывать проблемы в некоторых случаях, но помечаются как «неразумные» или «небезопасные». Объяснения, почему символы ограничены, четко изложены в RFC-1738 (URL-адреса) и RFC-2396 (URI). Обратите внимание, что более новый RFC-3986 (обновление до RFC-1738) определяет конструкцию того, какие символы разрешены в данном контексте, но более старая спецификация предлагает более простое и более общее описание того, какие символы не допускаются с помощью следующих правил.

    Исключенные символы US-ASCII, запрещенные в синтаксисе URI:

       control     = 
       space       = 
       delims      = "<" | ">" | "#" | "%" | <">
    

    Список неразумных символов разрешен, но может вызвать проблемы:

       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 будет выброшено URISyntaxException . сеть. URI конструктор, поэтому URL-адрес, такой как http://api.google.com/q?exp=a|b, не допускается и должен вместо этого кодироваться как http://api.google.com/q?exp=a%7Cb, если используется Java с экземпляром объекта URI.

    ответ дан JasonM1, с репутацией 11943, 21.11.2012
  • 56 рейтинг

    Большинство существующих ответов здесь нецелесообразно, потому что они полностью игнорируют реальное использование адресов, таких как:

    Хорошо, поэтому в соответствии с RFC 3986 такие адреса не являются URI (и, следовательно, не URL-адресами, поскольку URL являются типом URI ). Если мы считаем себя приверженными терминологии существующих стандартов IETF, то мы должны правильно называть их IRI (интернационализированные идентификаторы ресурсов), как определено в RFC 3987 , которые технически не являются URI, но могут быть преобразованы в URI просто путем кодирования процентов все не-ASCII символы в IRI. Обычные люди, тем не менее, никогда не слышали об IRI и просто называют эти URI или URL-адреса (и действительно, в настоящее время предпринимается усилие WHATWG по созданию новой более широкой спецификации URL, которая просто классифицирует все «URI» и «IRI» как «URL-адреса»). согласовать с современным использованием этих терминов в реальном мире).

    Предположим, мы хотим немедленно принять это значение URL (что противоречит спецификации IETF, но приводит нас в соответствие с повседневным использованием). В таком случае, какие символы допустимы в URL?

    Прежде всего, у нас есть два типа 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. Текущая спецификация WhatWG имеет более щедрый список :

    U + 00A0 до U + D7FF, U + E000 до U + FDCF, U + FDF0 до U + FFFD, U + 10000 до U + 1FFFD, U + 20000 до U + 2FFFD, U + 30000 до U + 3FFFD, U +40000 до U + 4FFFD, U + 50000 до U + 5FFFD, U + 60000 до U + 6FFFD, U + 70000 до U + 7FFFD, U + 80000 до U + 8FFFD, U + 90000 до U + 9FFFD, U + A0000 к U + AFFFD, U + B0000 к U + BFFFD, U + C0000 к U + CFFFD, U + D0000 к U + DFFFD, U + E0000 к U + EFFFD, U + F0000 к U + FFFFD, U + 100000 к U + 10FFFD

    Конечно, следует отметить, что простого знания того, какие символы могут юридически появляться в URL-адресе, недостаточно для определения того, является ли данная строка допустимым URL-адресом или нет, поскольку некоторые символы допустимы только в определенных частях URL-адреса. Например, зарезервированные символы [ и ] являются допустимыми как часть литерального хоста IPv6 в URL-адресе, например http: // [1080 :: 8: 800: 200C: 417A] / foo , но недопустимы в любом другом контекст, поэтому пример OP http://example.com/file[/].html является незаконным.

    ответ дан Mark Amery, с репутацией 55591, 16.04.2016
  • 18 рейтинг

    В своем дополнительном вопросе вы спросили, является ли 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 (i. е. литерал IPv6 вместо имени хоста)

    Стоит внимательно прочитать RFC 3986, если вы хотите полностью понять проблему.

    ответ дан Dominic Sayers, с репутацией 1592, 3.12.2009
  • 11 рейтинг

    Все действительных символов, которые можно использовать в URI (URL-адрес - это тип URI ), определены в RFC 3986 .

    Все остальные символы могут использоваться в URL-адресе при условии, что они сначала «закодированы». Это включает в себя изменение недопустимого символа для определенных «кодов» (обычно в форме символа процента (%), за которым следует шестнадцатеричное число).

    Эта ссылка, Ссылка на кодировку HTML-кода , содержит список кодировок для недопустимых символов.

    ответ дан CraigTP, с репутацией 34545, 10.10.2009
  • 9 рейтинг

    Некоторые из диапазонов символов Юникода действительны для HTML5 , хотя их использование может быть не очень хорошей идеей.

    E. г. , href документы говорят http: // www. w3. орг / TR / html5 / ссылки. html # attr-hyperlink-href :

    Атрибут href для элементов a и area должен иметь значение, которое является допустимым URL-адресом, потенциально окруженным пробелами.

    Тогда определение «действительный URL» указывает на http: // url. спекуляция WHATWG. org / , который говорит, что стремится:

    Совместите RFC 3986 и RFC 3987 с современными реализациями и устарели в процессе.

    Этот документ определяет URL-код точки как:

    ASCII буквенно-цифровой, "! "," $ "," & amp; "," '"," (",") "," * "," + ",", "," - ",". знак равно "," @ "," _ "," ~ "и кодовые точки в диапазонах U + 00A0 до U + D7FF, U + E000 до U + FDCF, U + FDF0 до U + FFFD, U + 10000 до U + 1FFFD, U + 20000 до U + 2FFFD, U + 30000 до U + 3FFFD, U + 40000 до U + 4FFFD, U + 50000 до U + 5FFFD, U + 60000 до U + 6FFFD, U + 70000 до U + 7FFFD, U + 80000 до U + 8FFFD, U + 90000 до U + 9FFFD, U + A0000 до U + AFFFD, U + B0000 до U + BFFFD, U + C0000 до U + CFFFD, U + D0000 до U + DFFFD, U + E1000 до U + EFFFD, U + F0000 до U + FFFFD, U + 100000 до U + 10FFFD.

    Затем в выражении используется термин «кодовые точки URL»:

    Если c не является точкой кода URL и не "%", ошибка синтаксического анализа.

    в нескольких частях алгоритма синтаксического анализа, включая схему, полномочия, относительный путь, запрос и состояния фрагмента: так в основном весь URL.

    Также, валидатор http: // validator. w3. org / проходит для URL-адресов, например "你好", и не проходит для URL-адресов с символами, такими как пробелы "a b"

    Конечно, как упомянул Стивен С, речь идет не только о символах, но и о контексте: вы должны понимать весь алгоритм. Но поскольку класс «кодовые точки URL» используется в ключевых точках алгоритма, он дает хорошее представление о том, что вы можете использовать или нет.

    См. Также: Юникод символов в URL

    ответ дан Ciro Santilli 新疆改造中心 六四事件 法轮功, с репутацией 124156, 29.08.2014
  • 5 рейтинг

    Мне нужно выбрать символ для разделения URL в строке, поэтому я решил создать список символов, которые не могут быть найдены в URL самостоятельно:

    >>> allowed = "-_.~!*'();:@&=+$,/?%#[]?@ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789"
    >>> from string import printable
    >>> ''.join(set(printable).difference(set(allowed)))
    '`" <\x0b\n\r\x0c\\\t{^}|>'
    

    Итак, возможный выбор: перевод строки, табуляция, пробел, обратный слеш и "<>{}^|. Я думаю, я пойду с пробелом или переводом строки. :)

    ответ дан Bunyk, с репутацией 3777, 11.02.2014
  • 4 рейтинг

    Не совсем ответ на ваш вопрос, но проверка URL-адреса действительно серьезный p. я. т. Возможно, вам лучше проверить доменное имя и оставить часть запроса в URL. Это мой опыт. Вы также можете прибегнуть к проверке URL-адреса и посмотреть, приводит ли он к правильному ответу, но это может быть слишком много для такой простой задачи.

    Регулярных выражений для определения URL-адресов в изобилии, Google это :)

    ответ дан ChrisR, с репутацией 11206, 10.10.2009
  • -3 рейтинг

    Используйте urlencode , чтобы разрешить произвольные символы в вашем URL.

    ответ дан knittl, с репутацией 146020, 10.10.2009