не преобразовывать адреса url в ссылки что такое
URI — сложно о простом (Часть 1)
Появилось таки некоторое количество времени, и я решил написать сий пост, идея которого возникла уже давно.
Связан он будет будет с такой, казалось бы, простой вещью, как URI, детальному рассмотрению которой в рунете уделяется как-то мало внимания.
«Пфф, ссылки они и в Африке ссылки, чего тут разбираться?» — скажете вы, тогда я задам вопрос:
Перед тем как начать хотел бы обозначить, что есть пост на схожую тему, в котором все обозначено проще и немного понятнее. Целью же этого поста, я ставлю более глубокое изучение вопроса и сбор информации об URI в одном месте, дабы «не потерять». Ну, почти в одном месте, статья будет разделена на две части
А для удобства бахнем оглавление, которое работает не без особенностей URI, которую мы рассмотрим попозжа, в этой статье.
Ознакомление
1. URI
Унифицированный Идентификатор Ресурса, в простонародье — URI
Самое свежее описание того, чем же все-таки являются эти пресловутые URI датируется январем аж 2005-го, а именно RFC3986, написанный самим Тимом Бёнесом-Ли, родоначальника всеми нами любимого тырнета.
Резюмируя п.1.1 можно сформулировать определение:
Многие из вас замечали, что на разных ресурсах ссылки называют то URL, то URI и, вероятно, становилось интересно — какой же из вариантов правильный?
Дело в том, что URL увидел свет и был документирован в 1990 году, в то время как URI был документирован лишь в 1994 году. И вплоть до 2002 года, до выхода RFC3305, уместными были оба варианта именования, что, порой вносило путаницу.
В п.2 RFC3305 сообщается об устаревании такого термина как URL, применимо к ссылкам, и что отныне верным будет именование URI, с того момента, во всех документах W3C использует термин URI. Исходя из этого, применяя термин URL к соответствующим ссылкам, вы не делаете смысловой ошибки, но делаете ее с точки зрения правильного именования.
Так же примечателен тот момент, что вплоть до выхода RFC2396, в 1997 году, URI расшифровывался как Universal Resource Identifier, что можно увидеть в RFC1630
1.1. Синтаксис
URI составлен из ограниченного набора символов, состоящих из цифр, букв и нескольких графических символов, все эти символы вписываются в кодировку US-ASCII (ASCII). Зарезервированное подмножество символов может использоваться, чтобы разграничить компоненты синтаксиса в URI, в то время как остающиеся символы: не зарезервированный набор и включая те зарезервированные символы, которые не действуют как разделители в данной компоненте URI, определяют данные идентификации каждого компонента.
Зарезервированные символы
Не зарезервированные символы
Для данного случая, согласно ABNF :
ALPHA — любая буква верхнего и нижнего регистров кодировки ASCII (в regExp [A-Za-z])
DIGIT — любая цифра (в regExp 7)
HEXDIG — шестнадцатиричная цифра (в regExp [0-9A-F])
Процентное кодирование
Т.о., %20, например, означает пробел.
1.2. Компоненты URI
где в квадратных скобках опциональные компоненты
Переходя по указанной в оглавлении ссылке, браузер производит переход ко вторичному ресурсу относительно данной страницы, т.е. скроллит вниз, до появления нужного на экране.
На этом, пожалуй, знакомство с URI можно закончить и начать углубляться в отдельные подвиды URI, а именно
2. URL
URL используются, чтобы определить местоположение ресурсов, обеспечивая абстрактную идентификацию расположения ресурса. Определив местоположение ресурса, система может выполнить множество операций на ресурсе, которые могут быть характеризованы такими словами как ‘доступ’, ‘обновление’, ‘замена’, ‘поиск атрибутов’. В целом только метод доступа должен быть определен для любой схемы URL.
2.1. Структура
В целом, URL имеет схожую структуру, для всех схем, хотя для каждой отдельно взятой схемы, структура может отличаться от общего шаблона.
Графически ее можно выразить в следующем виде: 
3. URN
Унифицированные имена ресурсов (URN) предназначены, чтобы служить постоянными, независимыми от расположения, идентификаторами ресурсов и разработаны для упрощения отображения других пространств имен (которые совместно используют свойства URN) в URN-пространство. Таким образом, синтаксис URN обеспечивает средство закодировать символьные данные в форме, которая может быть отправлена посредством существующих протоколов, записана при помощи большинства клавиатур, и т.д.
3.1. Структура
Самоидентифицирующийся URN
Такие URN содержат в NID название хэш-функции, а в NSS значение хэша, вычисленного для идентифицируемого объекта. Такие ссылки используются в magnet-ссылках и заголовках p2p-сети Gnutela2.
Например, URN из magnet-ссылки с одного торрент-трекера:
magnet:?xt=urn:btih:c68abc1ba9b8c7c4bc373862cad1a8c01d69e53d.
С теорией все, во второй части рассмотрим, что можно и что нужно делать с URI, если мы их обрабатываем, а именно — нормализация, разбор и т.д.
За сим откланяюсь, спасибо что читали, надеюсь не было скучно, удачи!
Articles
RegExp: преобразование URL в ссылку
Практикум веб-девелопера: использование регулярных выражений для работы с интернет-адресами
Уровень сложности: ●●●●● ■■■■■
Воистину, нет пределов глубине и ширине простого, на первый взгляд, проекта «Ответов» (ныне почивших). Начавшись на уровне игры, с размещения обычного html-файла, сделанного на коленке вручную, — к базе данных и, затем, к полностью автоматизированной системе импорта через RSS. Самодельный Гугль, типа.
Нет сомнений (мы даже не пытались искать в Сети аналоги), что всё давно кем-то сделано и где-то работает хорошо. Речь не об этом, а о том, говоря отвлечённо, что любая самостоятельная разработка, как кажется, «ненужного» или сверхпростого ведёт к развитию умений и навыков, делает человека человеком. Именно поэтому мы всегда рекомендуем не гнаться за славой или быстрыми деньгами, а доводить начатое до совершенства; в мелочах, подчас, закопаны сокровища, недостижимые для тех, кто «жить торопится и чувствовать спешит». И не только в области программирования.
Дальнейшее обсуждение предназначено для людей, знакомых хотя бы в общих чертах с регулярными выражениями и программированием, с проблемами, стоящими перед веб-разработчиками.
На этот раз пришлось решать простую с виду задачу автоматического превращения интернет-адресов в ссылки, т. е., адресов вида http://bichkov.com, которые обычно люди копируют из адресной строки и просто «кидают» в текст сообщения, — в полноценную ссылку http://bichkov.com, по которой удобно кликать другим пользователям, читающим текст.
Увы! Если вы думаете, что всё так просто и задача давно решена, попробую переубедить вас, приведя всего два примера. Один из них — из книги «PHP 5» уважаемых авторов М. Кузнецова, И. Симдянова и С. Голышева (С.-П., 2006). Вот что мы читаем в главе 5, посвящённой регулярным выражениям («Автоподсветка URL», листинг 5.7):
Нетрудно убедиться, что код работает (мы, правда, исправили одну несомненную опечатку в листинге, приведённом выше) лишь до тех пор, пока после адреса идёт пробел. Адреса, после которых идут знаки препинания, получают эти знаки в конце как часть ссылки, например: http://bichkov.com, Это не всегда хорошо. Скорее, всегда нехорошо для достижения желаемой страницы.
Нет, скажет скептически настроенный читатель, — пример нехорош! Во-первых, он старый, 2006 года, во-вторых, приведён в учебном пособии, для «начинающих». ОК, вот вам другой пример, посвежее. Американский ресурс, имеющий миллионы пользователей, делает так:
Нравится!? Трудно даже сказать, какое регулярное выражение используется для получения такого замечательного эффекта. Разумеется, попытка пройти по приведённым ссылкам обречена на неудачу. Придётся ручками-ручками править адрес в адресной строке браузера, чтобы попасть туда, куда предполагал автор цитат.
Кажется, я убедил читателей в том, что очевидные, простые, полезные и само-собой разумеющиеся вещи иногда не работают. Не работают даже там, где, казалось бы, должны и даже обязаны работать.
Перейдём теперь к изложению нашего решения данной проблемы. Оно просто, как всё гениальное 🙂 Надеемся, кому-то будет полезно если не пройти вместе с нами все ступеньки к решению, то хотя бы воспользоваться готовым результатом.
Попробуем теперь составить регулярное выражение, справляющееся с подобными трудностями. Но вначале перечислим эти трудности — напишем формальную постановку задачи.
Всего-то! Начнём, пожалуй.
1. По п. 1 условия задачи, выражение должно работать с символами Юникода. Модификатор u служит этой цели (хотя, на страницах с отличными от UTF-8 кодировками, оно, наоборот, работать перестанет — тогда этот модификатор лучше будет убрать); i тоже не помешает, чтобы сделать выражение регистронезависимым. (Примечание: при использовании модификатора x (PCRE_EXTENDED) следует пробелы предварить обратным слешем «\»).
Вот так: /выражение/iu, где «выражение» — нерождённое ещё регулярное выражение, заготовка.
2. В начале адреса идёт http://, поэтому пишем: http:\/\/ с «экранированными» для PHP символами. Можно, конечно, усложнить по вкусу: добавить s? для защищённого протокола https:// и ещё наворотить возможность использования ftp:// и проч. Но это всего лишь усложнение, не меняющее сути.
Что такое URL адрес и как с ним работать
Заблудиться можно не только в лесу, но и в онлайне. И тому виной может стать неверный путь или адрес, ведущий к ресурсу. Вы не знаете, что такое URL адрес? Тогда прежде, чем пускаться в дальнейшее путешествие по виртуальному пространству, давайте разберемся с системой электронных адресов.
Что такое URL
Основной формат записи структуры URL адреса выглядит так:
://:@:/?#
— чаще всего имеется в виду протокол.
логин – логин пользователя, используемый для авторизации на ресурсе.
пароль – пароль пользователя для авторизации.
хост – доменное имя хоста.
порт – порт хоста, используемый во время подключения.
URL – путь, по которому находится запрашиваемый ресурс на сервере.
параметры и якорь – значение переменных и идентификатор на определенном ресурсе.
Рассмотрим формат URL адреса страницы запрашиваемого ресурса на практических примерах. На клиентской стороне URL отображается в адресной строке браузера:
Чаще всего встречаются такие варианты:
Любой формат URL адреса представляет собой, прежде всего, символьную строку. В ее состав могут входить:
2; Латинские буквы.
2; Арабские цифры (0-9).
2; Зарезервированные символы («+», «=», «!» и другие).
2; Специальные символы – на них остановимся более подробно.
Использование специальных символов в URL
Конечно, таких уж слишком «специальных» символов в URL не используют. Но несколько есть:
Но все это лишь теория. Поэтому перед тем, как узнать остальное, рассмотрим небольшой практический пример.
Наглядный пример
Возьмем для наглядности вот такую простую форму регистрации:
Первой строкой в начале формы мы прописали для нее файл обработчика (php) и метод передачи данных через URL адрес сервера:
Теперь приведем код файла обработчика (1.php) :
Введем данные в форму и отправим их для обработки на сервер. Вот что мы получим в итоге:
Перед тем, как посмотреть на результат обработки, взгляните на адресную строку на втором рисунке. В ней отображаются значения полей, переданных на обработку с помощью метода GET.
Для того чтобы скрыть данные, отправляемые на сервер, используется метод POST. Тогда приведенный выше URL будет выглядеть следующим образом:
Формат URL адресов на сайтах
Разберем его по частям:
Чаще всего URL адреса основных разделов полностью отображают карту сайта. Но не все так просто обстоит с переадресацией на сайтах, развернутых на основе популярных движков ( CMS ).
Особенности построения URL в WordPress
Причем это ущемляет не только эстетическую составляющую отображения адресов, но и неоднозначно воспринимается поисковиками. А это может негативно влиять на продвижение сайта:
Поэтому лучше использовать на своем сайте чистые URL адреса. Но где взять их, если CMS система не предусматривает возможности их редактирования.
Самый простой способ настройки отображения URL в WordPress – это использование специализированных плагинов:
Руководство по сокращению URL-адресов и отслеживанию социальных сетей
Прежде чем начинать подсчет просмотров и цитирований, необходимо сделать все, чтобы пользователь захотел перейти по ссылке:
Что такое сокращение URL-адресов?
Сокращение URL-адресов не только помогает вычистить ваши сообщения в социальных сетях, но и дает возможность отслеживать потенциальных клиентов, приходящих через различные каналы. А также определить, в какое время лучше всего размещать твиты, и какие каналы лучше всего подходят для продвижения.
Миллионы людей используют Bitly каждый день, чтобы сокращать ссылки и отслеживать, как они работают:
Вам не нужна учетная запись для элементарного сокращения ссылок:
Если вам нужны более продвинутые функции, тогда необходимо создать учетную запись. В этом случае вы получаете доступ к таким инструментам, как настройки и архивирование ссылок, а также статистика, обновляемая в режиме реального времени.
Хотя с помощью бесплатного аккаунта в этом генераторе ссылок нельзя изменить домен, но можно настроить строку из букв и цифр и конце Bitly-ссылки ( или Bitlink ). Это отличная функция для ссылок, которые используются в кампаниях.
Отслеживание ссылок
Bitly предоставляет пользователям базовую аналитику по сокращенным ссылкам, которая позволяет определять и отслеживать их эффективность. Ее можно использовать для улучшения маркетинговой стратегии. Например, чтобы определить, какой тип контента пользуется популярностью и у кого.
Также можно увидеть, какие социальные медиа каналы, устройства и операционные системы используют самые активные посетители.
Создать сокращенный URL-адрес с помощью генератора ссылок Гугл очень просто:
Отслеживание ссылок в Goo.gl
Основное преимущество t.co заключается в его простоте. Просто вставьте длинную ссылку, и Twitter позаботится обо всем остальном. Вас также может сбить с толку то, что видимая ссылка на Twitter.com отображается как URL-адрес назначения, а не случайная последовательность букв и цифр:
Отслеживание ссылок в t.co
Генератор коротких ссылок Twitter предоставляет основную информацию, сколько раз была нажата ссылка. Доступ к этой информации можно получить, нажав на иконку графика, расположенную под твитом:
Откроется окно с информацией по конкретному твиту. В том числе о том, сколько раз была нажата ссылка:
Это бесплатный сервис для сокращения ссылок, которые в числе первых начали широко использоваться на Twitter.
Если вы являетесь участником партнерской программы, то можете скрыть свои партнерские ссылки, чтобы они не были видны посетителям. И если вы ограничены во времени, то можно добавить TinyURL на панель закладок в браузере, чтобы иметь возможность сокращать URL-адреса одним нажатием кнопки.
Этот бесплатный генератор ссылок для сайта не требует регистрации. Просто вставьте длинную ссылку в поле ввода и получите результат.
Вы можете создавать собственные ссылки, нажав на кнопку « Дополнительные опции / пользовательские URL-адреса » в выпадающем меню прямо под полем для ввода.
Сокращенные с помощью этого сервиса URL-адреса состоят из случайных заглавных, строчных букв и цифр. Здесь можно решить, нужно ли вам, чтобы ссылка состояла полностью из строчных букв, что сделает ее более удобной для пользователей:
Также можно включить отслеживание отдельных ссылок. Если эта опция активирована, можно будет просматривать статистику по URL-адресу на странице предварительно просмотра. Она создается автоматически во время сокращения ссылки. Убедитесь, что для опции « Журнал статистики по этой ссылке » установлен флажок.
Данный сервис позволяет сокращать ссылки прямо в окне создания сообщения нажатием одной кнопки:
С помощью четырех различных переменных Sprout автоматически генерирует:
Если вы хотите сделать ссылки более запоминающимися или вам просто нужно облегчить их отслеживание, генераторы ссылок помогут вам в этом.
Пожалуйста, опубликуйте ваши отзывы по текущей теме статьи. Мы крайне благодарны вам за ваши комментарии, отклики, подписки, дизлайки, лайки!
Пожалуйста, опубликуйте свои отзывы по текущей теме материала. Мы очень благодарим вас за ваши комментарии, дизлайки, подписки, лайки, отклики!
Мой URL — это не ваш URL
Когда давным-давно в 1996 году я приступил к работе над программой httpget, предшественницей проекта Curl, я написал свой первый синтаксический анализатор URL. Как раз тогда этот универсальный адрес получил название URL: Uniform Resource Locator (единый указатель ресурсов). Его спецификация была опубликована IETF в 1994 году. Аббревиатура «URL» была затем использована как источник вдохновения для названия инструмента и проекта Curl.
Термин «URL» был позднее изменён; его стали называть URI (Uniform Resource Identifier — единый идентификатор ресурсов), согласно спецификации, опубликованной в 2005 году, однако основное сохранилось: синтаксис для строки, задающей онлайн-ресурс и указывающей протокол для получения этого ресурса. Мы требуем, чтобы curl принимал указатели URL, как определено данной спецификацией RFC 3986. Ниже я расскажу, почему на самом деле это не совсем так.
Был ещё родственный RFC, описывающий IRI: Internationalized Resource Identifier (международный идентификатор ресурсов). IRI, по существу, то же самое, что URI, но IRI позволяют использовать символы, не входящие в ASCII.
Консорциум WHATWG позднее создал свою собственную спецификацию URL, в основном, сведя вместе форматы и идеи от URI и IRI с сильным упором на браузеры (что неудивительно). Одна из объявленных ими целей — «Модернизировать RFC 3986 и RFC 3987 в соответствии с современными реализациями и постепенно вывести их из употребления». Они хотят вернуться к использованию термина «URL», справедливо заявляя, что термины URI и IRI просто запутывают ситуацию и что люди так и не поняли их (или часто даже не знают, что эти термины существуют).
Спецификация WHATWG написана в духе старой доброй мантры браузеров: быть как можно более либеральными с пользователями, всегда пытаться угадать, что они имеют в виду, и выворачиваться наизнанку, пытаясь сделать это. Хотя при этом мы все знаем сейчас, что закон Постеля — не самый лучший подход к делу. На деле это значит, что спецификация позволяет использовать в URL слишком много слэшей, пробелы и символы, не входящие в ASCII.
С моей точки зрения, такую спецификацию также очень трудно читать и соблюдать, поскольку она не очень подробно описывает синтаксис или формат, но при этом навязывает обязательный алгоритм парсинга. Чтобы проверить моё утверждение: посмотрите, что это спецификация говорит о концевой точке после имени хоста в URL.
Вдобавок ко всем этим стандартам и спецификациям, в интерфейсе всех браузеров есть адресная строка (которую часто называют и по-другому), которая позволяет пользователям вводить какие угодно забавные строки и преобразовывает их в URL. Если ввести » http://localhost/%41 » в адресную строку, то участок с процентом будет преобразован в «A» (поскольку 41 в шестнадцатеричном исчислении является заглавной буквой A в ASCII), но если ввести » http://localhost/A A «, то фактически в исходящий HTTP-запрос GET будет отправлено » /A%20A » (с пробелом в URL-кодировке). Я говорю об этом, так как люди часто думают, что всё, что можно ввести в эту строку — и есть URL.
Указанное выше — в основном моё (искаженное) представление, с какими спецификациями и стандартами нам пока приходится работать. Теперь давайте добавим реальности и посмотрим, какие проблемы мы получаем, когда мой URL — это не ваш URL.
Так что же такое URL?
Или более конкретно — как мы пишем их? Какой синтаксис используем?
Думаю, одна из самых больших ошибок в спецификации WHATWG (и в ней причина, почему я выступаю против этой спецификации в её текущей форме с твёрдым убеждением, что они неправы) состоит в том, что они полагают, будто только им позволено работать с URL и давать им определение; они ограничивают свое представление об URL исключительно браузерами, HTML и адресными строками. Конечно, WHATWG создан большими компаниями, представляющими браузеры, которые использует почти каждый, а в этих браузерах широко работают указатели URL, но сами URL — явление значительно большее.
Представление об URL, существующее у WHATWG, не слишком широко принимается за пределами браузеров.
Двоеточие-слэш-слэш
Если спросить пользователей — обычных людей без какого-либо особого знания протоколов или сети — о том, что такое URL, то что они ответят? Последовательность «://» (двоеточие-слэш-слэш) была бы в начале списка ответов; несколько лет назад, когда браузеры показывали URL более полно, это было бы еще заметнее. Увидев эту последовательность, мы сразу понимаем, что перед нами именно URL.
Однако давайте отойдём от пользователей и оглядимся — в мире существуют почтовые клиенты, эмуляторы терминалов, текстовые редакторы, Perl-скрипты и многое-многое другое, что способно распознавать URL и работать с ними. Например, открыть URL в браузере, превратить в активную ссылку в сгенерированном HTML и так далее. Огромное количество названных скриптов и программ будет использовать именно последовательность «двоеточие-слэш-слэш» как главный признак.
Спецификация WHATWG говорит, что должен быть как минимум один слэш и что парсер при этом обязан принимать какое угодно количество слэшей. Это значит, что » http:/example.com » и » http:///////////////example.com » — полностью подходящие варианты. RFC 3986 и многие другие с этим не согласны. Ну, действительно, большинство из людей, с которыми я спорил последние несколько дней, даже те, кто работает в вебе, говорит, думает и убеждено, что URL имеет два слэша. Просто посмотрите внимательнее на скриншот результата поиска картинок в Гугл по запросу «URL» выше в этой статье.
Мы просто знаем, что у URL есть два слэша (хотя, да, URL типа file: обычно имеют три слэша, но давайте пока проигнорируем это). Не один. Не три. Два. Но WHATWG с этим не согласен.
«Есть хоть одна настоящая причина принимать более двух слэшей для не-файловых URL?» (спрашиваю я раздраженно у членов WHATWG)
Спецификация говорит это, потому что браузеры реализовали её именно так.
Никакое лучшее объяснение не было дано даже после того, как я указал, что это утверждение неправильное и далеко не все браузеры делают так. Возможно, эта ветка обсуждения покажется вам весьма познавательной.
В проекте Curl мы как раз недавно начали обсуждать, как обращаться с указателями URL, имеющими число слэшей, отличное от двух, потому что, оказывается, уже есть серверы, передающие обратно такие URL в заголовке “Location:”, и некоторые браузеры без возражений принимают их. Curl — нет, так же как и большинство из множества других библиотек и инструментов командной строки. Кого нам поддержать?
Пробелы
Символ пробела (код 32 в ASCII, шестнадцатеричный код 0x20) не может быть частью URL. Если требуется отправить его, то следует использовать URL-кодировку, как это делают с любым другим недопустимым символом, который надо сделать частью URL. URL-кодировка — это байтовое значение в шестнадцатеричном исчислении со знаком процента перед ним. Таким образом, «%20» означает пробел. Это также означает, что синтаксический анализатор, например, сканирующий текст на предмет указателей URL, узнаёт, что достиг конца URL, когда он обнаруживает недопустимый символ. Например, пробел.
Браузеры обычно преобразовывают все %20 в своих адресных строках в символ пробела, чтобы ссылки выглядели прилично. При копировании адреса в буфер и вставке его в текстовый редактор мы видим пробелы как %20, что и требуется.
Я не уверен, в этом ли причина, но браузеры также принимают пробелы как часть URL, получая, например, переадресацию в HTTP-ответе. Такие URL передаются от сервера к клиенту в заголовке «Location:». Браузеры без проблем допускают пробелы в них URL, кодируя их в виде %20 и отправляя следующий запрос. Это заставляет curl принимать пробелы в перенаправляемых «URL».
Не-ASCII
Поддержка в URL языков, включающих символы, не входящие в ASCII, конечно, важно, особенно для незападных сообществ, и я согласен, что спецификация IRI никогда не была достаточно хороша. Я лично далёко не эксперт в интернационализации, поэтому я руководствуюсь тем, что слышал от других. Но, конечно, пользователи нелатинских алфавитов и систем печати должны иметь возможность записывать свои «интернет-адреса» в ресурсы и использовать их как ссылки.
В идеальном случае у нас была бы интернационализированная версия для показа пользователю, и версия в кодировке ASCII для внутреннего использования в сетевых запросах.
Для международных доменных имён имя преобразуется в кодировку punycode так, чтобы оно могло быть прочитано обычными серверами DNS, которые ничего не знают об именах в кодировке, отличной от ASCII. Идентификаторы URI не имеют IDN-имён; IRI и URL по версии WHATWG — имеют. Сurl поддерживает IDN-имена хостов.
WHATWG заявляет, что URL могут использовать UTF-8, тогда как URI — только ASCII. Curl не воспринимает не-ASCII-символы в части адреса, задающей путь, но кодирует их процентом в исходящих запросах; это порождает “интересные» побочные эффекты, когда не-ASCII-символы представлены в коде, отличном от UTF-8, что является, например, стандартным для Windows.
Подобно тому, что я написал выше, это приводит к серверам, отправляющим назад не-ASCII-коды в HTTP-заголовках, которые браузеры охотно принимают, и не-браузерам тоже приходится работать с ними.
Стандарта URL не существует
Я не пытался представить полный список проблем или несоответствий — здесь просто некоторая подборка трудностей, с которыми я недавно столкнулся. «URL», выданный в одном месте, конечно, совсем необязательно будет принят или понят в другом месте как «URL».
В наши дни даже curl уже не следует строго ни одной опубликованной спецификации — мы медленно деградируем в угоду “веб-совместимости”.
Единый стандарт URL отсутствует, и какая-либо работа в этом направлении не ведётся. Я не могу считать, что WHATWG прилагает настоящие усилия к этому, поскольку она пишет спецификацию закрытой группой без серьёзных попыток привлечь более широкое сообщество.