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

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

Являются ли эти допустимые URL-адреса?

  • example.com/file[/].html
  • http://example.com/file[/].html

    10 Solutions collect form web for “Какие символы недействительны?”

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

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

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

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

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

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

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

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

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

      unwise = "{" | "}" | "|" | "\" | "^" | "[" | "]" | "`" 

    Символы, зарезервированные в компоненте запроса и / или имеющие особое значение в URI / URL:

      reserved = ";" | "/" | "?" | ":" | "@" | "&" | "=" | "+" | "$" | "," 

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

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

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

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

    Прежде всего, у нас есть два типа зарезервированных символов 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. В спецификации 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 является незаконным.

    В дополнительном вопросе вы спрашиваете, действителен ли URL-адрес www.example.com/file[/].html .

    Этот URL-адрес недействителен, поскольку URL-адрес является типом URI, а допустимый URI должен иметь такую ​​схему, как http: (см. RFC 3986 ).

    Если вы хотите спросить, является ли http://www.example.com/file[/].html допустимым URL-адресом, тогда ответа по-прежнему нет, потому что символы квадратной скобки там недействительны.

    Символы квадратной скобки зарезервированы для URL-адресов в этом формате: http://[2001:db8:85a3::8a2e:370:7334]/foo/bar (т. http://[2001:db8:85a3::8a2e:370:7334]/foo/bar IPv6 вместо имени хоста)

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

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

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

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

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

    Например, href docs говорят http://www.w3.org/TR/html5/links.html#attr-hyperlink-href :

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

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

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

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

    ASCII буквенно-числовые, “!”, “$”, “&”, “‘”, “(“, “)”, “*”, “+”, “,”, “-“, “.”, “/” , “:”, “;”, “=”, “?”, “@”, “_”, “~” и кодовые точки в диапазонах 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-адреса, а не «%», проанализируйте ошибку.

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

    Кроме того, валидатор http://validator.w3.org/ передает URL-адреса, такие как "你好" , и не передает URL-адреса с такими символами, как пробелы "ab"

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

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

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

    Регулярные выражения для обнаружения url’s изобилуют, google это 🙂

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

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

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

    Я придумал пару регулярных выражений для PHP, которые преобразуют URL-адреса в текст для привязки тегов. (Сначала он преобразует все www. Urls в http: // затем преобразует все URL-адреса с помощью https?: // в href = … html ссылки

    $string = preg_replace('/(https?:\/\/)([!#$&-;=?\-\[\]_a-z~%]+)/sim', '$2', preg_replace('/(\s)((www\.)([!#$&-;=?\-\[\]_a-z~%]+))/sim', '$1http://$2', $string) );

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

    Interesting Posts

    Где находится сообщение «Вы ответили на это сообщение …», хранящиеся в Outlook?

    Можно ли отслеживать MAC-адрес?

    Как мне переместить медиатеку iTunes?

    Жесткий диск 750Gig показывает полнофункциональный только 315Gigs

    Название каталога слишком длинное

    Рабочий стол перезагружается во время сна или спящего режима

    Не удается выполнить пинг других машин в моей сети

    Улучшен формат цитирования APA в Word 2007/2010?

    Могут ли устройства, подключенные к отдельным полосам на двухдиапазонных маршрутизаторах, обмениваться файлами?

    Изменение групповой политики с использованием окон CMD

    Как присоединиться к двум листам в Excel, как в SQL?

    Присоединение видео в командной строке

    Как связать файлы без расширения в Windows 7?

    Как заставить Windows 8 запускать 2 приложения Metro на каждом дисплее расширенного дисплея?

    Создание локальной библиотеки с сетевыми ресурсами / дисками

    Давайте будем гением компьютера.