Url формат файла: что нужно знать о таких файлах?

Файл формата URL — программы для открытия файлов .url

Файл ярлыка, используемый веб-браузерами, включая Microsoft Internet Explorer (MSIE) и Apple Safari. Содержит информацию для URL-адреса. Также иногда включает в себя ссылку на файл иконки favicon.ico, которая отображается в качестве иконки для файла ярлыка.

Файлы URL открывают страницу в Интернете, например, веб-адрес, в браузере, установленном у пользователя по умолчанию. Обычно место размещения ярлыка можно просмотреть, открыв файл к текстовом редакторе, например, Microsoft Notepad или Apple TextEdit.

Примечание: Microsoft Windows не отображает расширение файла «.url», даже если оно стоит в названии файла. Поэтому файлы URL, сохраненные при помощи веб-браузеров Windows, будут видны только с префиксом названия файла.

Описание на русском	Ярлык Интернета
Описание на английском	Internet Shortcut
Разработчик
HEX:	5B
ASCII:	[

Расширение файла .url представляет собой ярлык Интернета. Данный файл может быть открыт с помощью следующих программ: Microsoft Internet Explorer, Google Chrome, Mozilla Firefox, Блокнот Windows.

Как открыть файл MP3URL? Расширение файла .MP3URL

Что такое файл MP3URL?

Полное имя формата файлов, которые используют расширение MP3URL: MP3 Songs Playlist Format. Файлы с расширением MP3URL могут использоваться программами, распространяемыми для платформы Windows. MP3URL файл относится к категории Аудиофайлы так же, как #NUMEXTENSIONS # других расширений файлов, перечисленных в нашей базе данных. Самым популярным программным обеспечением, поддерживающим MP3URL файлы, является Winamp. Программное обеспечение Winamp было разработано Radionomy, и на его официальном веб-сайте вы можете найти дополнительную информацию о файлах MP3URL или программном обеспечении Winamp.

Программы, которые поддерживают MP3URL расширение файла

Следующий список функций MP3URL -совместимых программ. Файлы с расширением MP3URL, как и любые другие форматы файлов, можно найти в любой операционной системе. Указанные файлы могут быть переданы на другие устройства, будь то мобильные или стационарные, но не все системы могут быть способны правильно обрабатывать такие файлы.

Updated: 07/21/2020

Как открыть файл MP3URL?

Отсутствие возможности открывать файлы с расширением MP3URL может иметь различное происхождение. С другой стороны, наиболее часто встречающиеся проблемы, связанные с файлами MP3 Songs Playlist Format, не являются сложными. В большинстве случаев они могут быть решены быстро и эффективно без помощи специалиста. Приведенный ниже список проведет вас через процесс решения возникшей проблемы.

Шаг 1. Получить Winamp

Основная и наиболее частая причина, препятствующая открытию пользователями файлов MP3URL, заключается в том, что в системе пользователя не установлена программа, которая может обрабатывать файлы MP3URL. Чтобы решить эту проблему, перейдите на веб-сайт разработчика Winamp, загрузите инструмент и установите его. Это так просто В верхней части страницы находится список всех программ, сгруппированных по поддерживаемым операционным системам. Одним из наиболее безопасных способов загрузки программного обеспечения является использование ссылок официальных дистрибьюторов. Посетите сайт Winamp и загрузите установщик.

Шаг 2. Проверьте версию Winamp и обновите при необходимости

Вы по-прежнему не можете получить доступ к файлам MP3URL, хотя Winamp установлен в вашей системе? Убедитесь, что программное обеспечение обновлено. Иногда разработчики программного обеспечения вводят новые форматы вместо уже поддерживаемых вместе с новыми версиями своих приложений. Это может быть одной из причин, по которой MP3URL файлы не совместимы с Winamp. Все форматы файлов, которые прекрасно обрабатывались предыдущими версиями данной программы, также должны быть открыты с помощью Winamp.

Шаг 3. Назначьте Winamp для MP3URL файлов

Если у вас установлена последняя версия Winamp и проблема сохраняется, выберите ее в качестве программы по умолчанию, которая будет использоваться для управления MP3URL на вашем устройстве. Процесс связывания форматов файлов с приложением по умолчанию может отличаться в деталях в зависимости от платформы, но основная процедура очень похожа.

Процедура изменения программы по умолчанию в Windows

• Выберите пункт Открыть с помощью в меню «Файл», к которому можно щелкнуть правой кнопкой мыши файл MP3URL.
• Выберите Выбрать другое приложение → Еще приложения
• Последний шаг — выбрать опцию Найти другое приложение на этом… указать путь к папке, в которой установлен Winamp. Теперь осталось только подтвердить свой выбор, выбрав Всегда использовать это приложение для открытия MP3URL файлы и нажав ОК .

Процедура изменения программы по умолчанию в Mac OS

• Щелкните правой кнопкой мыши на файле MP3URL и выберите Информация.
• Найдите опцию Открыть с помощью — щелкните заголовок, если он скрыт
• Выберите подходящее программное обеспечение и сохраните настройки, нажав Изменить все
• Должно появиться окно с сообщением, что это изменение будет применено ко всем файлам с расширением MP3URL
  . Нажимая Вперед, вы подтверждаете свой выбор.

Шаг 4. Проверьте MP3URL на наличие ошибок

Вы внимательно следили за шагами, перечисленными в пунктах 1-3, но проблема все еще присутствует? Вы должны проверить, является ли файл правильным MP3URL файлом. Отсутствие доступа к файлу может быть связано с различными проблемами.

1. MP3URL может быть заражен вредоносным ПО — обязательно проверьте его антивирусом.

Если MP3URL действительно заражен, возможно, вредоносное ПО блокирует его открытие. Сканируйте файл MP3URL и ваш компьютер на наличие вредоносных программ или вирусов. MP3URL файл инфицирован вредоносным ПО? Следуйте инструкциям антивирусного программного обеспечения.

2. Убедитесь, что структура файла MP3URL не повреждена

Если вы получили проблемный файл MP3URL от третьего лица, попросите его предоставить вам еще одну копию. Возможно, файл был ошибочно скопирован, а данные потеряли целостность, что исключает доступ к файлу. Если

файл MP3URL был загружен из Интернета только частично, попробуйте загрузить его заново.

3. Проверьте, есть ли у пользователя, вошедшего в систему, права администратора.

Некоторые файлы требуют повышенных прав доступа для их открытия. Выйдите из своей текущей учетной записи и войдите в учетную запись с достаточными правами доступа. Затем откройте файл MP3 Songs Playlist Format.

4. Убедитесь, что ваше устройство соответствует требованиям для возможности открытия Winamp

Если в системе недостаточно ресурсов для открытия файлов MP3URL, попробуйте закрыть все запущенные в данный момент приложения и повторите попытку.

5. Убедитесь, что у вас установлены последние версии драйверов, системных обновлений и исправлений

Современная система и драйверы не только делают ваш компьютер более безопасным, но также могут решить проблемы с файлом MP3 Songs Playlist Format. Устаревшие драйверы или программное обеспечение могли привести к невозможности использования периферийного устройства, необходимого для обработки файлов MP3URL.

Как открыть файл URLS? Расширение файла .URLS

Что такое файл URLS?

URLS суффикс имени файла в основном используется для GetRight Internet Shortcuts List файлов. Спецификация GetRight Internet Shortcuts List была создана Headlight Software, Inc.. URLS файлы поддерживаются программными приложениями, доступными для устройств под управлением Windows. URLS файл относится к категории Интернет-файлы так же, как #NUMEXTENSIONS # других расширений файлов, перечисленных в нашей базе данных. Самым популярным программным обеспечением, поддерживающим URLS файлы, является GetRight Download Manager. На официальном сайте разработчика Headlight Software, Inc. вы найдете не только подробную информацию о программном обеспечении GetRight Download Manager, но также о URLS и других поддерживаемых форматах файлов.

Программы, которые поддерживают URLS расширение файла

Программы, которые могут обрабатывать URLS файлы, следующие. Файлы с расширением URLS, как и любые другие форматы файлов, можно найти в любой операционной системе. Указанные файлы могут быть переданы на другие устройства, будь то мобильные или стационарные, но не все системы могут быть способны правильно обрабатывать такие файлы.

Как открыть файл URLS?

Проблемы с доступом к URLS могут быть вызваны разными причинами. С другой стороны, наиболее часто встречающиеся проблемы, связанные с файлами GetRight Internet Shortcuts List, не являются сложными. В большинстве случаев они могут быть решены быстро и эффективно без помощи специалиста. Ниже приведен список рекомендаций, которые помогут вам выявить и решить проблемы, связанные с файлами.

Шаг 1. Получить GetRight Download Manager

Основная и наиболее частая причина, препятствующая открытию пользователями файлов URLS, заключается в том, что в системе пользователя не установлена программа, которая может обрабатывать файлы URLS. Решение этой проблемы очень простое. Загрузите GetRight Download Manager и установите его на свое устройство. Выше вы найдете полный список программ, которые поддерживают URLS файлы, классифицированные в соответствии с системными платформами, для которых они доступны. Одним из наиболее безопасных способов загрузки программного обеспечения является использование ссылок официальных дистрибьюторов. Посетите сайт GetRight Download Manager и загрузите установщик.

Шаг 2. Обновите GetRight Download Manager до последней версии

Если у вас уже установлен GetRight Download Manager в ваших системах и файлы URLS по-прежнему не открываются должным образом, проверьте, установлена ли у вас последняя версия программного обеспечения. Может также случиться, что создатели программного обеспечения, обновляя свои приложения, добавляют совместимость с другими, более новыми форматами файлов. Если у вас установлена более старая версия GetRight Download Manager, она может не поддерживать формат URLS. Последняя версия GetRight Download Manager должна поддерживать все форматы файлов, которые совместимы со старыми версиями программного обеспечения.

Шаг 3. Назначьте GetRight Download Manager для URLS файлов

Если проблема не была решена на предыдущем шаге, вам следует связать URLS файлы с последней версией GetRight Download Manager, установленной на вашем устройстве. Следующий шаг не должен создавать проблем. Процедура проста и в значительной степени не зависит от системы

Процедура изменения программы по умолчанию в Windows

• Выберите пункт Открыть с помощью в меню «Файл», к которому можно щелкнуть правой кнопкой мыши файл URLS.
• Выберите Выбрать другое приложение → Еще приложения
• Наконец, выберите Найти другое приложение на этом… , укажите папку, в которой установлен GetRight Download Manager, установите флажок Всегда использовать это приложение для открытия URLS файлы свой выбор, нажав кнопку ОК

Процедура изменения программы по умолчанию в Mac OS

• В раскрывающемся меню, нажав на файл с расширением URLS, выберите Информация
• Перейдите к разделу Открыть с помощью . Если он закрыт, щелкните заголовок, чтобы получить доступ к доступным параметрам.
• Выберите подходящее программное обеспечение и сохраните настройки, нажав Изменить все
• Если вы выполнили предыдущие шаги, должно появиться сообщение: Это изменение будет применено ко всем файлам с расширением URLS. Затем нажмите кнопку Вперед», чтобы завершить процесс.

Шаг 4. Проверьте URLS на наличие ошибок

Если проблема по-прежнему возникает после выполнения шагов 1-3, проверьте, является ли файл URLS действительным. Проблемы с открытием файла могут возникнуть по разным причинам.

1. Проверьте URLS файл на наличие вирусов или вредоносных программ.

Если файл заражен, вредоносная программа, находящаяся в файле URLS, препятствует попыткам открыть его. Рекомендуется как можно скорее сканировать систему на наличие вирусов и вредоносных программ или использовать онлайн-антивирусный сканер. URLS файл инфицирован вредоносным ПО? Следуйте инструкциям антивирусного программного обеспечения.

2. Убедитесь, что файл с расширением URLS завершен и не содержит ошибок

Вы получили URLS файл от другого человека? Попросите его / ее отправить еще раз. Возможно, что файл не был должным образом скопирован в хранилище данных и является неполным и поэтому не может быть открыт. Если файл URLS был загружен из Интернета только частично, попробуйте загрузить его заново.

3. Проверьте, есть ли у пользователя, вошедшего в систему, права администратора.

Иногда для доступа к файлам пользователю необходимы права администратора. Выйдите из своей текущей учетной записи и войдите в учетную запись с достаточными правами доступа. Затем откройте файл GetRight Internet Shortcuts List.

4. Убедитесь, что ваше устройство соответствует требованиям для возможности открытия GetRight Download Manager

Если система перегружена, она может не справиться с программой, которую вы используете для открытия файлов с расширением URLS. В этом случае закройте другие приложения.

5. Проверьте, есть ли у вас последние обновления операционной системы и драйверов

Последние версии программ и драйверов могут помочь вам решить проблемы с файлами GetRight Internet Shortcuts List и обеспечить безопасность вашего устройства и операционной системы. Возможно, файлы URLS работают правильно с обновленным программным обеспечением, которое устраняет некоторые системные ошибки.

URI — сложно о простом (Часть 1) / Хабр

Привет хабр!

Появилось таки некоторое количество времени, и я решил написать сий пост, идея которого возникла уже давно.
Связан он будет будет с такой, казалось бы, простой вещью, как URI, детальному рассмотрению которой в рунете уделяется как-то мало внимания.

«Пфф, ссылки они и в Африке ссылки, чего тут разбираться?» — скажете вы, тогда я задам вопрос:

Что есть что и куда нас приведет?

• http://example.com
• www.example.com
• //www.example.com
• mailto:[email protected]

Если вы не знаете однозначного ответа или вам просто интересно и если вы не боитесь огромного количества трехбуквенных аббревиатур — милости прошу под кат.

Перед тем как начать хотел бы обозначить, что есть пост на схожую тему, в котором все обозначено проще и немного понятнее. Целью же этого поста, я ставлю более глубокое изучение вопроса и сбор информации об URI в одном месте, дабы «не потерять». Ну, почти в одном месте, статья будет разделена на две части
А для удобства бахнем оглавление, которое работает не без особенностей URI, которую мы рассмотрим попозжа, в этой статье.

ОГЛАВЛЕНИЕ

1. URI
   1.1. Синтаксис
   1.2. Компоненты URI
   
2. URL
   2.1. Структура
3. URN
   3.1. Структура

Ознакомление

1. URI

Унифицированный Идентификатор Ресурса, в простонародье — URI
Самое свежее описание того, чем же все-таки являются эти пресловутые URI датируется январем аж 2005-го, а именно RFC3986, написанный самим Тимом Бёнесом-Ли, родоначальника всеми нами любимого тырнета.
Резюмируя п.1.1 можно сформулировать определение:

URI — последовательность символов, идентифицирующая физический или абстрактный ресурс, который не обязательно должен быть доступен через сеть Интернет, причем, тип ресурса, к которому будет получен доступ, определяется контекстом и/или механизмом.
Например:

• перейдя по http://example.com — мы попадем на http-сервер ресурса идентифицируемого как example.com
• в то же время ftp://example.com — приведет наc на ftp-сервер того же самого ресурса
• или например http://localhost/ — URI идентифицирующий саму машину откуда производится доступ

В современном интернете, чаще всего используется две разновидности URI — URL и URN.
Основное различие между ними — в задачах:

• URL — Uniform Resource Locator, помогает найти какой либо ресурс
• URN — Uniform Resource Name, помогает этот ресурс идентифицировать

Упрощая: URL — отвечает на вопрос: «Где и как найти что-то?», URN — отвечает на вопрос: «Как это что-то идентифицировать».
Парочка интересностей про URIМногие из вас замечали, что на разных ресурсах ссылки называют то URL, то URI и, вероятно, становилось интересно — какой же из вариантов правильный?
Дело в том, что URL увидел свет и был документирован в 1990 году, в то время как URI был документирован лишь в 1994 году. И вплоть до 2002 года, до выхода RFC3305, уместными были оба варианта именования, что, порой вносило путаницу.
В п.2 RFC3305 сообщается об устаревании такого термина как URL, применимо к ссылкам, и что отныне верным будет именование URI, с того момента, во всех документах W3C использует термин URI. Исходя из этого, применяя термин URL к соответствующим ссылкам, вы не делаете смысловой ошибки, но делаете ее с точки зрения правильного именования.

Так же примечателен тот момент, что вплоть до выхода RFC2396, в 1997 году, URI расшифровывался как Universal Resource Identifier, что можно увидеть в RFC1630

Обобщая всевозможные варианты, URI имеет следующий вид:

Забегая вперед, стоит отметить, что не все три компоненты являются строго обязательными. Для того чтобы ссылка считалась URI необходимо наличие:

• либо scheme+authority+path,
• либо sheme+path,
• либо только path.

1.1. Синтаксис

Согласно п.2 RFC3986:

URI составлен из ограниченного набора символов, состоящих из цифр, букв и нескольких графических символов, все эти символы вписываются в кодировку US-ASCII (ASCII). Зарезервированное подмножество символов может использоваться, чтобы разграничить компоненты синтаксиса в URI, в то время как остающиеся символы: не зарезервированный набор и включая те зарезервированные символы, которые не действуют как разделители в данной компоненте URI, определяют данные идентификации каждого компонента.

Зарезервированные символы

Зарезервированные символы делятся на два типа:

• gen-delims, они же «главные разделители», т.е. символы, разделяющие URI на крупные компоненты.

   ":", "/", "?", "#", "[", "]", "@"

• sub-delims, они же «под разделители» — символы, которые разделяют текущую крупную компоненту, на более мелкие составляющие, для каждой компоненты они свои, вот список самых распространенных:

   "!", "$", "&", "'", "(", ")", "*", "+", ",", ";", "="

Не зарезервированные символы

Исходя из предыдущего пункта, не зарезервированные символы — символы, не входящие в gen-delims, а так же не значимые для данной компоненты sub-delims. Но в общем случае это:

ALPHA, DIGIT, "-", ".", "_", "~"

Для данного случая, согласно ABNF:
ALPHA — любая буква верхнего и нижнего регистров кодировки ASCII (в regExp [A-Za-z])
DIGIT — любая цифра (в regExp [0-9])
HEXDIG — шестнадцатиричная цифра (в regExp [0-9A-F])

Процентное кодирование

В случае, если используются символы выходящие за пределы кодировки ASCII используется механизм т.н. «Процентного кодирования«. Так же он применяется для передачи зарезервированных символов в составе данных. Зарезервированные символы, по правилам, не участвуют в процентном кодировании.
Процентно-кодированный символ представляет из себя символьный триплет, состоящий из знака «%» и следующих за ним двух шестнадцатиричных чисел:

pct-encoded = "%" HEXDIG HEXDIG

Т.о., %20, например, означает пробел.

1.2. Компоненты URI

Следующий список содержит описания крупных компонент, составляющих URI:

• Scheme (схема)
  Каждый URI начинается с имени схемы, которое относится к спецификации для присвоения идентификаторов в этой схеме. Также, синтаксис URI — объединенная и расширяемая система именования, причем, спецификация каждой схемы может далее ограничить синтаксис и семантику идентификаторов, использующих эту схему.
  Название схемы обязательно начинается с буквы и далее может быть продолжено любым количеством разрешенных символов.
  Разрешенные символы для схемы:
  

  ALPHA, DIGIT, "+", "-", "."

• Authority (честно говоря, не знаю как перевести слово на русский, без потери смысла)
  Компонента authority начинается с двойного слеша(//) и заканчивается следующим слешем(/), знаком вопроса(?) или октоторпом(#)(да-да, «решеточка» зовется именно так=)) или концом URI
  Authority состоит из:
  

  [ userinfo "@" ] host [ ":" port ]

  где в квадратных скобках опциональные компоненты

  Каждую из подкомпонент, отдельно, мы рассмотрим чуть позже, в разделе посвященном URL.
  
• Path (Путь)
  Компонента пути содержит данные, обычно, организованные в иерархической форме, которые, вместе с данными в неиерархическом компоненте запроса (Query), служит, чтобы идентифицировать ресурс в рамках схемы URI и authority (если таковая компонента указана).
  Путь начинается со слеша(/) и заканчивается знаком вопроса(?), октоторпом(#) или концом URI
  Разрешенные символы для пути:
  

  Не зарезервированные, процентно-кодированные, sub-delims, ":", "@"

• Query (Запрос)
  Компонента запроса содержит данные, организованные в неиерархической форме, которые, вместе с данными в иерархическом компоненте пути (Path), служит, чтобы идентифицировать ресурс в рамках схемы URI и authority (если таковая компонента указана).
  Запрос начинается с первого знака вопроса(?) и заканчивается октоторпом(#) или концом URI
  Разрешенные символы для запроса:
  

  Не зарезервированные, процентно-кодированные, sub-delims, ":", "@", "/", "?"

  В запросе чаще всего передаются данные в формате key=value (ключ=значение), значение рекомендуется передавать в процентно-кодированном виде, обусловлено это тем, что в значении может встретиться символ «&», который используется для разделения пар ключ-значение, в результате появления такого артефакта дальнейшая последовательность пар ключ-значение может быть нарушена.
• Fragment (Фрагмент)
  Компонента фрагмент позволяет осуществить косвенную идентификацию вторичного ресурса по отношению к первому.
  Семантика фрагмента никак не ограничена, фрагмент начинается октоторпом(#) и заканчивается концом URI, при этом может состоять из абсолютно любого набора символов.
  Примером применения фрагментов является оглавление данной статьи. Оно состоит из относительных ссылок
  

  <a href="#someanchor"></a>

  а по статье, в определенных местах, раскиданы т.н. «якоря» — теги

  <anchor>someanchor</anchor>

  Переходя по указанной в оглавлении ссылке, браузер производит переход ко вторичному ресурсу относительно данной страницы, т.е. скроллит вниз, до появления нужного

  <anchor>

  на экране.

На этом, пожалуй, знакомство с URI можно закончить и начать углубляться в отдельные подвиды URI, а именно

2. URL

Стандарт URL документирован в RFC1738.
Из п.2:

URL используются, чтобы определить местоположение ресурсов, обеспечивая абстрактную идентификацию расположения ресурса. Определив местоположение ресурса, система может выполнить множество операций на ресурсе, которые могут быть характеризованы такими словами как ‘доступ’, ‘обновление’, ‘замена’, ‘поиск атрибутов’. В целом только метод доступа должен быть определен для любой схемы URL.

Т. о.: URL призван решить широкий ряд задач, начиная с получения и заканчивая изменением данных на ресурсе, а обязательным параметром для получения доступа — является метод, т. е. любой полноценный (абсолютный) URL можно свести к виду:

<scheme>:<часть свойственная этой схеме>

2.1. Структура

В целом, URL имеет схожую структуру, для всех схем, хотя для каждой отдельно взятой схемы, структура может отличаться от общего шаблона.
Графически ее можно выразить в следующем виде:

И вот, примерно на этом моменте, можно рассмотреть различия между абсолютными (absolute) и относительными (relative) URL, данные определения распространяются не только на URL, но и на URI в целом.

• Относительная ссылка использует иерархический синтаксис, чтобы выразить ссылку URI относительно пространства имен другого иерархического URI.
  Относительные ссылки так же делятся на несколько подвидов:
  
  • Ссылка сетевого пути
    Имеет вид:

    //<authority> <path> [<query>] [<fragment>]

    Такой тип ссылок применяется не часто, смысл заключается в переходе по указанной ссылке с применением текущей схемы.
    Т. е.: находясь, например на http://example.com и перейдя по ссылке //domain.com — мы попадем на http://domain.com
    А в случае если перейдем по той же ссылке с ftp://example.com, то попадем на ftp://domain.com
  • Ссылка абсолютного пути
    Имеет вид:

    /<path> [<query>] [<fragment>]

    На этот раз мы останемся в пределах текущего хоста, но попадем по пути path в любом случае, по какому бы пути мы сейчас не находились.
    Т. е.: даже находясь на http://example.com/just/some/long/path и перейдя по ссылке /path, мы попадем на http://example.com/path
  • Ссылка относительного пути
    Имеет вид:

    <path> [<query>] [<fragment>]

    Теперь же, мы будем перемещаться в пределах текущего положения.
    Т. е.: находясь на http://example.com/just/some/long/path и перейдя по ссылке path, мы попадем на http://example.com/just/some/long/path/path
  • Ссылка того же документа
    Фактически это ссылки, состоящие только из фрагментарной части URI, либо же ссылки, у которых все компоненты за исключением фрагментарной совпадают с исходной.
    Т.е. #fragment и http://habrahabr.ru/topic/232385/#fragment являются ссылками того же документа.
    
  
  
• Абсолютная ссылка — ссылка вида
  

  <scheme> <authority> [<path>] [<query>] [<fragment>]

  Применяя абсолютные ссылки, мы будем попадать на нужный нам ресурс вне зависимости от того, откуда мы переходим.
  Т. е.: находись мы на http://example.com/just/some/long/path или же на ftp://example.com, перейдя по http://domain.com/path, мы в любом случае попадем на http://domain.com/path
  

После того, как мы разобрались с тем, что же такое относительные и абсолютные пути — можно отвечать на вопрос заданный в начале поста:

• http://example.com — откроет http://example.com
• www.example.com — по-идее должен открыть http://habrahabr.ru/topic/232385/www.example.com, но хабр сам исправляет ссылку, хотя по стандартам www.example.com — ссылка относительного пути
• //www.example.com — откроет www.example.com со схемой с которой вы просматриваете текущую страницу, т.е. скорее всего будет открыт http://example.com
• mailto:[email protected] — здесь уже вступают в силу настройки браузера, он предложит вам открыть эту ссылку при помощи почтовой программы и отправить электронное письмо адресату [email protected], а так, это абсолютный URL со схемой mailto

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

• Scheme — как говорилось ранее: схема определяет метод доступа к ресурсу. Список актуальных схем можно посмотреть тут.
• Userinfo — под-компонент authority, использующийся для авторизации пользователя на ресурсе. Состоит из username и необязательного password, от остальной части authority отделяется символом «@«. Не смотря на то, что параметр password указан в спецификации, его использование крайне не рекомендуется, т. к. фактически производится передача пароля к учетной записи username, в незашифрованном виде.
  Разрешенные символы:

  Не зарезервированные, процентно-кодированные, sub-delims, ":"

  
  Пример можно привести следующий:
  На локалке есть папка test, на которую стоит доступ по паре логин-пароль. То есть, перейдя по http://localhost/test/, я увижу следующее:
  А если я перейду по ссылке http://admin:admin@localhost/test/, то процедура авторизации произойдет автоматически, с данными указанными в блоке userinfo:
  
• Host — компонент authority, использующийся для определения целевого узла (или ресурса, если угодно, но понятие «узел» будет более точным), который может находиться как в сети интернет, так и вне её, в зависимости от указанной схемы. Данная компонента не чувствительна к регистру.
  Хост может представлять из себя либо IP-адрес, либо регистрационное имя (reg-name) и, опционально, следующий за ними порт(port).
  Предусматривается как поддержка существующих форматов IP-адресов (IPv4, IPv6), так и всевозможных будущих, которые будут описаны впоследствии.
  Регистрационное имя — привычные нам, т. н. доменные имена — последовательность символов, обычно предназначенных для поиска в локально определенном узле или реестре имени службы, хотя специфичная для схемы семантика URI может потребовать, чтобы вместо этого использовался определенный реестр (или фиксированная таблица имен).
  Наиболее распространенный механизм реестра имен — Система Доменных Имен (DNS).
  Доменное имя, используемое для поиска в DNS, состоит из доменных меток, разделенных при помощи «.», каждая доменная метка может содержать следующие символы:

  Не зарезервированные, процентно-кодированные, sub-delims

  Синтаксис регистрационного имени позволяет использование процентно-кодированных символов, для представления не-ASCII символов, в едином порядке, не зависящем от технологии разрешения имен. Символы, не входящие в ASCII, должны быть сначала закодированы в UTF-8, а затем каждый октет UTF-8 последовательности должен быть процентно закодирован.
  В случае, если регистрационное имя с не-ASCII символами представляет собой многоязычное доменное имя, разрешаемое через DNS, оно должно быть преобразовано в кодировку IDNA (RFC3490) до поиска имени и, как следствие, регистраторами доменных имен такие регистрационные имена должны предоставляться в кодировке IDNA.
  Port (Порт) — десятичный номер порта, отделяется от hostname одним двоеточием «:», может состоять только из цифр. Схема может определять порт по-умолчанию, который будет использоваться в случае если порт не указан. Например, для схемы HTTP порт по-умолчанию — 80, что соответствует зарезервированному под неё порту 80/TCP. Тип порта, так же как и назначенный номер порта, определяется схемой.
• Компоненты Запрос и Фрагмент полностью описаны ранее.

3. URN

Стандарт URN документирован в RFC2141.
Из п.1:

Унифицированные имена ресурсов (URN) предназначены, чтобы служить постоянными, независимыми от расположения, идентификаторами ресурсов и разработаны для упрощения отображения других пространств имен (которые совместно используют свойства URN) в URN-пространство. Таким образом, синтаксис URN обеспечивает средство закодировать символьные данные в форме, которая может быть отправлена посредством существующих протоколов, записана при помощи большинства клавиатур, и т.д.

Т. е., в отличие от URL, который ссылается на како-то место, где хранится документ, URN ссылается на сам документ, и при перемещении документа в другое место ссылка не изменится.
В силу того, что URN концептуально отличается от URL, то и система разрешения имен у него другая — DDDS, которая преобразует URN в URL, по которым можно найти ресурс/объект или что бы то ни было, на что ссылается URN.

3.1. Структура

URN имеет следующий вид:

"urn:" <NID> ":" <NSS>

• «urn:» — обязательная, регистронезависимая часть URN
• NID — Namespace Identifier, данная компонента определяет синтаксическую интерпретацию компоненты NSS.
  Минимальная длина — 2 символа, максимальная — 32, разрешенные символы:
  

  латинские буквы, цифры, "-"

  NID должен начинаться только с буквы или цифры.
  Так же, слово «urn» для NID является зарезервированным, дабы избежать неоднозначности при определении URN в целом.
  Список официально зарегистрированных NID можно посмотреть тут
• NSS — Namespace Specific String, эта компонента служит непосредственно для передачи каких-либо данных.
  Разрешенные символы:
  

  латинские буквы, цифры, процентно-кодированные, "(", ")", "+", ",", "-", ".", ":", "=", "@", ";", "$", "_", "!", "*", "'"

  Зарезервированные символы:
  

  "%", "/", "?", "#"

  Запрещенные символы должны быть процентно-кодированы. Если указанный символ встретится в явном виде, его позиция будет считаться концом URN:
  

  октеты 0-32 (0-20 hex), "\", """, "&", "<", ">", "[", "]", "^", "`", "{", "|", "}", "~", октеты 127-255 (7F-FF hex)

Самоидентифицирующийся URN

Такие URN содержат в NID название хэш-функции, а в NSS значение хэша, вычисленного для идентифицируемого объекта. Такие ссылки используются в magnet-ссылках и заголовках p2p-сети Gnutela2.
Например, URN из magnet-ссылки с одного торрент-трекера:
magnet:?xt=urn:btih:c68abc1ba9b8c7c4bc373862cad1a8c01d69e53d...

С теорией все, во второй части рассмотрим, что можно и что нужно делать с URI, если мы их обрабатываем, а именно — нормализация, разбор и т.д.

За сим откланяюсь, спасибо что читали, надеюсь не было скучно, удачи!

Требования к форматированию URL — приложения Win32

• 31.05.2018
• 2 минуты на чтение

В этой статье

Начиная с Windows 7, остаются несоответствия в обработке и анализе URL-адресов.В этом разделе представлено ограниченное руководство по устранению несоответствий в форматах URL-адресов файлов.

Эта тема организована следующим образом:

Используемые форматы URL

Сторонние протоколы несут ответственность за определение своего формата URL и определение запросов в соответствии с их стандартом. Например, Microsoft Outlook поддерживает имена папок с произвольными символами, включая те, которые недопустимы в URL-адресах, например, "?" персонаж. Обработчик протокола MAPI выполняет собственное URL-кодирование своих URL-адресов.Следовательно, индекс хранит «% 3F» вместо «?» , и Outlook должен учитывать это при создании запросов.

Различные форматы перечислены в следующей таблице, и каждому из них присвоен буквенный идентификатор для ссылки на них далее в этом разделе.

ID	URL-адрес локального файла или удаленный	Пример
А	Местный	файл: /// c: \ test \ example \
B	Местный	файл: c: / test / example /
С	Местный	c: \ test \ example \
D	Пульт	файл: /// \\ server \ share \
E	Пульт	файл: // сервер / общий ресурс /
F	Пульт	\ сервер \ доля \

Чувствительность направления косой черты, звезды и обратной косой черты

В Windows Search практически нет чувствительности к направлению косой черты.Если принимается формат c: \ test \ example , то также принимается c: / test / example. Однако, хотя SCOPE обычно нечувствителен к направлению косой черты, он чувствителен к направлению косой черты в случае формата удаленного URL F. Следовательно, Scope = '// server / share' не работает.

Единственный API, который чувствителен к конечным звездам и различает c: \ test \ и c: \ test \ * , — это ISearchCrawlScopeManager . Если существует правило исключения для c: \ test \ * , сам каталог URL c: \ test все равно будет проиндексирован.Но если URL-адрес исключения c: \ test \ , сам каталог URL c: \ test не будет проиндексирован.

Есть два места, где Windows Search чувствителен к завершающим слешам: ItemUrl и Path запросы. Если существует каталог c: \ test , Windows Search обрабатывает c: \ test \ иначе, чем c: \ test для таких предикатов, как path = 'c: \ test' и System.ItemUrl = ' c: \ test '. Например, предикат path = 'file: c: / test' будет соответствовать каталогу c: \ test , но path = 'file: c: / test /' не будет, из-за косой черты в конце ,

Форматы URL-адресов по API и запросу

Форматы URL-адресов локальных файлов, принимаемые выбранными API и запросами, перечислены в следующей таблице. Форматы связаны с буквой (от A до F), значение которой было указано в разделе «Используемые форматы URL-адресов» ранее в этом разделе.

Форматы URL-адресов удаленных файлов, принимаемые выбранными запросами, перечислены в следующей таблице.

Что входит в индекс

Процесс индексирования в Windows Search

Процесс запроса в Windows Search

Процесс уведомлений в поиске Windows

,

Формат URL

Когда вы пытаетесь получить доступ к веб-странице в Интернете, веб-адрес, который вы вводите в браузер, имеет определенный формат. Весь этот веб-адрес (включая часть http: //) называется URL-адресом.

В этом руководстве основное внимание уделяется:

• Определение и построение URL
• Общие протоколы и их использование

Определение и построение URL

URL означает унифицированный указатель ресурсов. Унифицированный указатель ресурсов принимает определенный формат, с помощью которого вы можете создавать соединения и / или получать доступ к информации, используя различные протоколы.URL-адрес — это глобальный адрес документа или ресурса в Интернете.

Синтаксис URL:

протокол: // domainOrIPAddress: порт / путь / имя файла

Пример URL:

http://www.landofcode.com/html/url-format.php

Объяснение частей URL:

• протокол — указывает, какой протокол будет использоваться для доступа к URL-адресу. Некоторые распространенные протоколы включают HTTP (протокол передачи гипертекста) для передачи веб-содержимого и FTP (протокол передачи файлов) для передачи файлов через удаленное соединение.За протоколом следует : //
• домен или IP-адрес — указывает IP-адрес или домен, в котором расположен ресурс, например www.landofcode.com или 10.1.1.1.
• порт — указывает порт, который будет использоваться для подключения. Обычно его опускают, поскольку порты по умолчанию используются для различных протоколов, таких как порт 80 для HTTP.
• путь — указывает подкаталог на сервере, где расположен ресурс. Если путь не указан, то корневой каталог на сервере проверяется на наличие ресурса.
• filename — Фактическое имя ресурса. Если имя файла опущено, то используется имя файла по умолчанию, например index.html для HTTP-соединения.

Общие протоколы и их использование

Протокол	Использование
http	Доступ к файлу в Интернете
https	Доступ к файлу в Интернете через безопасное соединение
файл	Доступ к файлу на локальном компьютере
ftp	Доступ к файлу на FTP-сервере
суслик	Доступ к файлу на сервере Gopher
новости	Доступ к группе новостей Usenet
телнет	Запуск telnet-соединения
mailto	Создать ссылку на сообщение электронной почты с веб-страницы
WAIS	Доступ к файлу на сервере WAIS

HTTP

Тип URL-адреса, к которому привыкло большинство пользователей Интернета.Стандартный URL-адрес доступа к веб-странице HTTP.

Пример доступа к файлу в Интернете:

http://www.landofcode.com/html/html-basics.php

HTTPS

Протокол HTTPS, который используется в интернет-магазинах из соображений безопасности данных, защищает данные при их передаче.

Пример доступа к файлу в Интернете через безопасное соединение:

https://www.amazon.com

FTP

Протокол FTP обычно используется веб-мастерами для доступа к файлам на своих веб-серверах.

Пример доступа к файлу через ftp:

ftp://www.somesite.com/ftp/file.exe

Новости Usenet

Новости Usenet содержат множество дискуссионных групп, на которые вы можете подписаться.

Пример доступа к группе новостей Usenet:

новости: alt.binaries.dvds

Mailto

Mailto предоставляет ссылку на сообщение электронной почты с веб-страницы

Пример создания ссылки на сообщение электронной почты с веб-страницы:

Свяжитесь с нами!

Файл

Фактически вы можете получить доступ к файловому каталогу вашего компьютера через браузер с помощью File.

Пример доступа к файлу на локальном жестком диске:

файл: /// c: /windows/system/file.dll

,

java — Создать URL для файла

Переполнение стека

1. Около
2. Товары
3. Для команд

1. Переполнение стека Общественные вопросы и ответы
2. Переполнение стека для команд Где разработчики и технологи делятся частными знаниями с коллегами
3. работы Программирование и связанные с ним технические возможности карьерного роста
4. Талант Нанимайте технических специалистов и создавайте свой бренд работодателя
5. реклама Обратитесь к разработчикам и технологам со всего мира
6. О компании

Загрузка…

.

URL Decode and Encode — онлайн

О

Meet URL Decode and Encode, простом онлайн-инструменте, который делает именно то, что он говорит; декодирует кодировку URL и кодирует в нее быстро и легко. URL-адрес кодирует ваши данные простым способом или декодирует их в удобочитаемый формат. Кодирование URL-адреса

, также известное как процентное кодирование, представляет собой механизм кодирования информации в унифицированном идентификаторе ресурса (URI) при определенных обстоятельствах. Хотя это называется кодировкой URL-адресов, на самом деле она используется более широко в основном наборе универсальных идентификаторов ресурсов (URI), который включает как универсальный указатель ресурса (URL), так и универсальное имя ресурса (URN).Как таковой он также используется при подготовке данных типа носителя «application / x-www-form-urlencoded», как это часто бывает при отправке данных HTML-формы в HTTP-запросах.

Дополнительные параметры

• Набор символов: В случае текстовых данных схема кодирования не содержит их набор символов, поэтому вы должны указать, какой из них использовался в процессе кодирования. Обычно это UTF-8, но может быть любой другой; если вы не уверены, поиграйте с доступными опциями, включая автоопределение.Эта информация используется для преобразования декодированных данных в набор символов нашего веб-сайта, чтобы все буквы и символы могли отображаться правильно. Обратите внимание, что это не имеет отношения к файлам, поскольку к ним не нужно применять безопасные веб-преобразования.
• Декодировать каждую строку отдельно: Закодированные данные обычно состоят из непрерывного текста, даже новые строки преобразуются в их процентно закодированные формы. Перед декодированием все незашифрованные пробелы удаляются из ввода, чтобы обеспечить его целостность.Эта опция полезна, если вы намеревались декодировать несколько независимых записей данных, разделенных разрывами строки.
• Режим реального времени: Когда вы включаете эту опцию, введенные данные немедленно декодируются с помощью встроенных функций JavaScript вашего браузера — без отправки какой-либо информации на наши серверы. В настоящее время этот режим поддерживает только набор символов UTF-8.

Надежно и надежно

Все коммуникации с нашими серверами осуществляются через безопасные зашифрованные соединения SSL (https).Загруженные файлы удаляются с наших серверов сразу после обработки, а полученный загружаемый файл удаляется сразу после первой попытки загрузки или 15 минут бездействия. Мы никоим образом не храним и не проверяем содержимое введенных данных или загруженных файлов. Прочтите нашу политику конфиденциальности ниже для получения более подробной информации.

Совершенно бесплатно

Наш инструмент можно использовать бесплатно. Теперь вам не нужно загружать какое-либо программное обеспечение для таких задач.

Подробная информация о кодировке URL-адреса

Типы символов URI

Допустимые символы в URI либо зарезервированы, либо не зарезервированы (или символ процента как часть процентного кодирования).Зарезервированные символы — это те символы, которые иногда имеют особое значение. Например, символы косой черты используются для разделения различных частей URL-адреса (или, в более общем смысле, URI). Незарезервированные символы не имеют таких значений. При использовании процентного кодирования зарезервированные символы представляются с помощью специальных последовательностей символов. Наборы зарезервированных и незарезервированных символов, а также обстоятельства, при которых определенные зарезервированные символы имеют особое значение, незначительно менялись с каждой версией спецификаций, управляющих URI и схемами URI.

RFC 3986 раздел 2.2 Зарезервированные символы (январь 2005 г.)
!	*	'	(	)	;	:	@	и	=	+	$	,	/	?	#	[	]

RFC 3986 раздел 2.3 незарезервированных символа (январь 2005 г.)
A	B	C	D	E	F	G	H	I	J	K	L	M	N	O	P	Q	R	S	T	U	V	W	X	Y	Z
a	b	c	d	e	f	г	h	i	j	k	l	m	n	o	p	q	r	s	t	u	v	w	x	y	z
0	1	2	3	4	5	6	7	8	9	-	_	.	~

Другие символы в URI должны быть закодированы в процентах.

Зарезервированные символы с процентным кодированием

Когда символ из зарезервированного набора («зарезервированный символ») имеет особое значение («зарезервированное назначение») в определенном контексте, а схема URI сообщает, что необходимо использовать этот символ для какой-то другой цели, тогда этот символ должен быть закодирован в процентах. Процентное кодирование зарезервированного символа включает преобразование символа в соответствующее ему байтовое значение в ASCII и последующее представление этого значения в виде пары шестнадцатеричных цифр.Цифры, которым предшествует знак процента («%»), затем используются в URI вместо зарезервированного символа. (Для символа, отличного от ASCII, он обычно преобразуется в его последовательность байтов в UTF-8, а затем каждое значение байта представляется, как указано выше.)

Зарезервированный символ «/», например, если он используется в пути « «компонент URI, имеет особое значение как разделитель между сегментами пути. Если в соответствии с данной схемой URI «/» должен находиться в сегменте пути, тогда в этом сегменте необходимо использовать три символа «% 2F» или «% 2f» вместо необработанного «/».

Зарезервированные символы после процентного кодирования
!	#	$	и	'	(	)	*	+	,	/	:	;	=	?	@	[	]
% 21	% 23	% 24	% 26	% 27	% 28	% 29	% 2A	% 2B	% 2C	% 2F	% 3A	% 3B	% 3D	% 3F	% 40	% 5B	% 5D

Зарезервированные символы, которые не имеют зарезервированного назначения в конкретном контексте, также могут быть закодированы в процентах, но не являются семантически отличается от других.

В компоненте «запрос» URI (часть после символа?), Например, «/» по-прежнему считается зарезервированным символом, но обычно он не имеет зарезервированного назначения, если в конкретной схеме URI не указано иное. Символ не нужно кодировать в процентах, если он не имеет зарезервированной цели.

URI, которые различаются только тем, является ли зарезервированный символ закодированным в процентах или отображается буквально, обычно считаются не эквивалентными (обозначающими один и тот же ресурс), если не может быть определено, что рассматриваемые зарезервированные символы не имеют зарезервированной цели.Это определение зависит от правил, установленных для зарезервированных символов отдельными схемами URI.

Процентное кодирование незарезервированных символов

Символы из незарезервированного набора никогда не нуждаются в процентном кодировании.

URI, которые различаются только тем, является ли незарезервированный символ закодированным в процентах или выглядит буквально, эквивалентны по определению, но процессоры URI на практике могут не всегда распознавать эту эквивалентность. Например, потребители URI не должны трактовать «% 41» иначе, чем «A» или «% 7E» иначе, чем «~», но некоторые это делают.Для максимальной совместимости производителям URI не рекомендуется использовать процентное кодирование незарезервированных символов.

Процентное кодирование символа процента

Поскольку символ процента («%») служит индикатором для октетов, закодированных в процентах, он должен быть закодирован в процентах как «% 25», чтобы этот октет использовался в качестве данных внутри URI.

Процентное кодирование произвольных данных

Большинство схем URI включают представление произвольных данных, таких как IP-адрес или путь файловой системы, в качестве компонентов URI.Спецификации схемы URI должны, но часто этого не делать, предоставлять явное сопоставление между символами URI и всеми возможными значениями данных, представленными этими символами.

Двоичные данные

С момента публикации RFC 1738 в 1994 году было указано [1], что схемы, которые обеспечивают представление двоичных данных в URI, должны разделять данные на 8-битные байты и кодировать их в процентах. byte таким же образом, как указано выше. Например, байтовое значение 0F (шестнадцатеричное) должно быть представлено как «% 0F», а байтовое значение 41 (шестнадцатеричное) может быть представлено как «A» или «% 41».Использование незакодированных символов для буквенно-цифровых и других незарезервированных символов обычно является предпочтительным, поскольку это приводит к более коротким URL-адресам.

Символьные данные

Процедура процентного кодирования двоичных данных часто экстраполировалась, иногда неправильно или не полностью, для применения к символьным данным. В годы становления Всемирной паутины при работе с символами данных в репертуаре ASCII и использовании соответствующих им байтов в ASCII в качестве основы для определения последовательностей, закодированных в процентах, эта практика была относительно безвредной; просто предполагалось, что символы и байты отображаются взаимно однозначно и взаимозаменяемы.Однако потребность в представлении символов вне диапазона ASCII быстро росла, и схемы и протоколы URI часто не обеспечивали стандартных правил подготовки символьных данных для включения в URI. В результате веб-приложения начали использовать различные многобайтовые кодировки, кодировки с отслеживанием состояния и другие несовместимые с ASCII кодировки в качестве основы для процентного кодирования, что привело к неоднозначности и трудностям надежной интерпретации URI.

Например, многие схемы и протоколы URI, основанные на RFC 1738 и 2396, предполагают, что символы данных будут преобразованы в байты в соответствии с некоторой неопределенной кодировкой символов, прежде чем они будут представлены в URI незарезервированными символами или байтами с процентной кодировкой.Если схема не позволяет URI предоставлять подсказку относительно того, какая кодировка использовалась, или если кодировка конфликтует с использованием ASCII для процентного кодирования зарезервированных и незарезервированных символов, то URI не может быть надежно интерпретирован. Некоторые схемы вообще не учитывают кодирование и вместо этого просто предлагают, чтобы символы данных отображались непосредственно на символы URI, что оставляет на усмотрение реализации решение о том, следует ли и как кодировать символы данных в процентах, которые не входят ни в зарезервированные, ни в незарезервированные наборы. _ ` { | } ~ % 0A или % 0D или % 0D% 0A % 20 % 22 % 25 % 2D % 2E % 3C % 3E % 5C % 5E % 5F % 60 % 7B % 7C % 7D % 7E
Данные произвольных символов иногда кодируются в процентах и ​​используются в ситуациях, не связанных с URI, например, для программ обфускации паролей или других системные протоколы перевода.,