Схемы uri - uwp applications

Введение

Некоторые приложения в Интернете требуют обнаружения информации о источнике (иногда называемой «метаданными всего сайта») перед выполнением запроса. Например, протокол исключения роботов (http://www.robotstxt.org) определяет способ для автоматизированных процессов получить разрешение на доступ к ресурсам; Точно так же Платформа настроек конфиденциальности сообщает пользовательским агентам, как найти политику конфиденциальности перед взаимодействием с исходным сервером.

Хотя существует несколько способов доступа к метаданным для каждого ресурса (например, поля заголовка HTTP, PROPFIND в Web Distributed Authoring and Versioning (WebDAV) ), воспринимаемые издержки (либо с точки зрения задержки, воспринимаемой клиентом, и / или трудностей развертывания) связанные с ними часто исключают их использование в этих сценариях.

В то же время стало более популярным использование HTTP в качестве субстрата для не-веб-протоколов. Иногда такие протоколы нуждаются в способе найти один или несколько ресурсов на данном хосте.

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

Для решения этих задач в этом меморандуме резервируется префикс пути в URI HTTP, HTTPS, WebSocket (WS) и Secure WebSocket (WSS) для этих «общеизвестных расположений», «/.well-known/». Будущие спецификации, которым необходимо определить ресурс для таких метаданных, могут зарегистрировать их использование, чтобы избежать коллизий и минимизировать воздействие на пространство URI источника.

Хорошо известные URI могут также использоваться с другими схемами URI, но только когда определения этих схем явно разрешают это.

Синтаксис Унифицированных Идентификаторов Ресурсов (URI)

это пример протокола (схемы). Тут описывается какой протокол браузер должен использовать. Обычно это HTTP протокол или его безопасная версия — HTTPS. Интернет требует один из этих двух, но браузеры также знают как работать с некоторыми другими, например (чтобы открыть почтовый клиент) или для работы с передачей файлов. Популярные схемы:

Схема	Описание
data	Data URIs
file	Доступ к файлам на локальном компьютере
ftp	File Transfer Protocol (протокол передачи файлов)
http/https	Hyper text transfer protocol (Secure)
mailto	Адрес электронной почты
ssh	Протокол Secure shell для работы с серверами
tel	Телефон
urn	Uniform Resource Names
view-source	Исходный код ресурса
ws/wss	(Зашифрованные) соединения WebSocket

— это доменное имя, идентификатор ответственного за это пространство имён. Идентифицирует, какой именно Веб-сервер получает запрос. Альтернативно, можно просто использовать IP address, но поскольку это не так удобно, то этот способ используется не часто.

— это порт сервера. Он идентифицирует технические «ворота», которые нужны для доступа к ресурсу на сервере. Обычно порт не указывается, т.к. существуют общепринятые нормы о стандартных портах для HTTP (80 для HTTP и 443 для HTTPS). В других случаях обязательно нужно указывать.

— это путь к ресурсу на Веб-сервере. Изначально путь типа этого указывал на физическое место файла на сервере, но сейчас всё чаще это псевдоним или описание некоторого абстрактного ресурса.

— это дополнительные параметры, предоставляемые Веб-серверу. Это список пар «ключ=значение», разделённых символом . Веб-сервер может использовать эти параметры как дополнительные инструкции, что именно сделать с ресурсом перед отправкой его пользователю. Каждый Веб-сервер имеет свои правила насчёт параметров, и единственный надёжный способ узнать как конкретный Веб-сервер обрабатывает эти параметры — это спросить того, кто контролирует Веб-сервер.

— это «якорь» на другую часть ресурса. Якорь представляет собой что-то вроде «закладки» внутри ресурса, давая браузеру указание показать содержимое с определённого места. В HTML-документе, к примеру, браузер будет скроллить к точке где якорь определён, а на аудио/видео-документе браузер попытается перейти на время, указанное в якоре

Важно что часть, начинающаяся с # — никогда не пересылается серверу в запросе.

Компоненты WWW¶

Функционирование сервиса обеспечивается четырьмя составляющими:

Адресация веб-ресурсов. URL, URN, URI

URL (RFC 1738) — унифицированный локатор (указатель) ресурсов, стандартизированный способ записи адреса ресурса в www и сети Интернет. Адрес URL имеет гибкую и расширяемую структуру для максимально естественного указания местонахождения ресурсов в сети. Для записи адреса используется ограниченный набор символов ASCII. Общий вид адреса можно представить так:

<схема>://<логин>:<пароль>@<хост>:<порт>/<полный-путь-к-ресурсу>

Где:

схема

схема обращения к ресурсу: http, ftp, gopher, mailto, news, telnet, file, man, info, whatis, ldap, wais и т.п.

логин:пароль

имя пользователя и его пароль, используемые для доступа к ресурсу

хост

доменное имя хоста или его IP-адрес.

порт

порт хоста для подключения

полный-путь-к-ресурсу

уточняющая информация о месте нахождения ресурса (зависит от протокола).

Примеры URL:

http://example.com #запрос стартовой страницы по умолчанию

http://www.example.com/site/map.html #запрос страницы в указанном каталоге

http://example.com:81/script.php #подключение на нестандартный порт

http://example.org/script.php?key=value #передача параметров скрипту

ftp://user:pass@ftp.example.org #авторизация на ftp-сервере

http://192.168.0.1/example/www #подключение по ip-адресу

file:///srv/www/htdocs/index.html #открытие локального файла

gopher://example.com/1 #подключение к серверу gopher

mailto://user@example.org #ссылка на адрес эл.почты

В августе 2002 года RFC 3305 анонсировал устаревание URL в пользу URI (Uniform Resource Identifier), еще более гибкого способа адресации, вобравшего возможности как URL, так и URN (Uniform Resource Name, унифицированное имя ресурса). URI позволяет не только указавать местонахождение ресурса (как URL), но и идентифицировать его в заданном пространстве имен (как URN). Если в URI не указывать местонахождение, то с его помощью можно описывать ресурсы, которые не могут быть получены непосредственно из Интернета (автомобили, персоны и т.п.). Текущая структура и синтаксис URI регулируется стандартом RFC 3986, вышедшим в январе 2005 года.

Язык гипертекстовой разметки HTML

HTML () — стандартный язык разметки документов во Всемирной паутине. Большинство веб-страниц созданы при помощи языка HTML. Язык HTML интерпретируется браузером и отображается в виде документа, в удобной для человека форме. HTML является приложением SGML (стандартного обобщённого языка разметки) и соответствует международному стандарту ISO 8879.

HTML создавался как язык для обмена научной и технической документацией, пригодный для использования людьми, не являющимися специалистами в области вёрстки. Для этого он представляет небольшой (сравнительно) набор структурных и семантических элементов — тегов. С помощью HTML можно легко создать относительно простой, но красиво оформленный документ. Изначально язык HTML был задуман и создан как средство структурирования и форматирования документов без их привязки к средствам воспроизведения (отображения). В идеале, текст с разметкой HTML должен единообразно воспроизводиться на различном оборудовании (монитор ПК, экран органайзера, ограниченный по размерам экран мобильного телефона, медиа-проектор). Однако современное применение HTML очень далеко от его изначальной задачи. Со временем основная идея платформонезависимости языка HTML стала жертвой коммерциализации www и потребностей в мультимедийном и графическом оформлении.

Протокол HTTP

HTTP () — протокол передачи гипертекста, текущая версия HTTP/1.1 (RFC 2616). Этот протокол изначально был предназначен для обмена гипертекстовыми документами, сейчас его возможности существенно расширены в сторону передачи двоичной информации.

HTTP — типичный клиент-серверный протокол, обмен сообщениями идёт по схеме «запрос-ответ» в виде ASCII-команд. Особенностью протокола HTTP является возможность указать в запросе и ответе способ представления одного и того же ресурса по различным параметрам: формату, кодировке, языку и т. д. Именно благодаря возможности указания способа кодирования сообщения клиент и сервер могут обмениваться двоичными данными, хотя данный протокол является символьно-ориентированным.

HTTP — протокол прикладного уровня, но используется также в качестве «транспорта» для других прикладных протоколов, в первую очередь, основанных на языке XML (SOAP, XML-RPC, SiteMap, RSS и проч.).

ПРИЛОЖЕНИЕ Б. ШАБЛОН РЕГИСТРАЦИИ СХЕМЫ URI ДЛЯ СХЕМЫ MS-POWERPOINT

Б-3. Синтаксис схемы URI

Схема PowerPoint = «ms-powerpoint:» open-for-edit-cmd | open-for-view-cmd | new-from-template-cmd
open-for-edit-cmd = «ofe|u|» document-uri
open-for-view-cmd = «ofv|u|» document-uri
new-from-template-cmd = «nft|u|» template-uri
document-uri = URI документа, который требуется открыть
template-uri = URI файла шаблона, на котором будет основан новый файл
save-location* = URI папки, в которой будет создан документ
*save-location это необязательный параметр

B-4. Семантика схемы URI

Схема ms-powerpoint определяет синтаксис URI для открытия или создания презентации. В ней определены три команды, которые указывают, что необходимо сделать с указанным документом. Это команды: 1) open-for-edit-cmd (ofe), которая приводит к открытию презентации по указанному URI в приложении для редактирования; 2) open-for-view-cmd (ofv), которая приводит к открытию презентации по указанному URI в приложении в режиме только для чтения; 3) new-from-template-cmd (nft), которая приводит к созданию презентации в приложении на основе шаблона по указанному в template-uri идентификатору URI и сохранению документа в расположении, указанном в необязательном аргументе save-location или, при его отсутствии, в библиотеке документов по умолчанию.

Б-5. Приложения и протоколы, использующие схему URI ms-powerpoint

Схема URI ms-powerpoint используется Microsoft Office 2013 для вызова Microsoft PowerPoint 2013 или Microsoft PowerPoint 2010 с пакетом обновлений 2 (SP2). Microsoft SharePoint 2013 использует URI ms-powerpoint как ссылки на презентации, хранящиеся в библиотеках документов SharePoint.

Б-6. Вопросы взаимодействия

Обратите внимание, что вертикальная черта, используемая как разделитель в этой спецификации, не входит в число символов, определенных в разделе 2.2 документа RFC 3986 как зарезервированные для возможного использования в качестве разделителей. Это сделано специально, чтобы расширить число символов, поддерживаемых аргументами команд URI без их кодирования с использованием символа процента

В сегментах < command-argument > зарезервированные RFC 3986 символы «:» и «/» входят в данные аргумента, а не представляют разделители, поэтому их можно добавлять без экранирования.

ms-appx и ms-appx-web

Используйте схему URI или для ссылки на файл, который поступает из пакета приложения (см. раздел ). Файлы в пакете приложения обычно содержат статические изображения, данные, код и макеты. Схема обращается к тем же файлам, что и , но в разделе web. Примеры и дополнительные сведения см. в разделе .

Центр сертификации (ms-appx и ms-appx-web)

Центр сертификации — имя идентификатора пакета, которое определено в манифесте пакета. Таким образом, компонент центра сертификации в URI и в IRI (международный идентификатор ресурсов) ограничен набором символов, разрешенных в имени идентификатора пакета. Имя пакета должно соответствовать имени одного из пакетов графа зависимостей пакета выполняемого приложения.

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

Сведения о пользователе и порт (ms-appx и ms-appx-web)

Схема , в отличие от других популярных схем, не определяет компоненты сведений о пользователе и компоненты порта. Поскольку «@» и «:» не допускаются в качестве допустимых значений полномочий, поиск завершится ошибкой, если они включены. Поиск завершится неудачно в любом из следующих примеров.

Путь (ms-appx и ms-appx-web)

Компонент пути соответствует стандартному синтаксису RFC 3986 и поддерживает наличие в IRI символов, отличных от ASCII. Компонент пути определяет логический или физический путь к файлу. Этот файл находится в папке, сопоставленной с расположением установки пакета приложения. Приложение определяется компонентом центра сертификации.

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

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

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

Компонент пути схемы , как и стандартные URI, учитывает регистр. Однако если файловая система, с помощью которой выполняется доступ к ресурсу, не учитывает регистр (например, NTFS), извлечение ресурса выполняется без учета регистра.

Нормализованная форма URI поддерживает регистр и декодирует (используя символ «%», за которым следуют двузначный шестнадцатеричный символ) незарезервированные символы RFC 3986. Символы «?», «#», «/», «*» и «» «(символ двойной кавычки) должны быть закодированы в виде процента, представляющего такие данные, как имена файлов или папок. Все закодированные символы перед получением декодируются. Поэтому для получения файла с именем Hello#World.html используйте этот URI.

Запрос (ms-appx и ms-appx-web)

Параметры запроса игнорируются во время получения ресурсов. Нормализованная форма параметров запроса учитывает регистр. Параметры запроса не игнорируются во время сравнения.

Общие компоненты схем URI

Все схемы, описанные в этом разделе, соответствуют стандартам схем URI по нормализации и извлечению ресурсов. В разделе RFC 3986 приводится универсальный синтаксис URI.

Все схемы URI определяют иерархическую часть в соответствии с RFC 3986 как компоненты полномочий и пути URI.

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

Компонент фрагмента игнорируется при обработке URI для данной схемы, рассматриваемых в этом разделе. Во время получения и сравнения компонент фрагмента не учитывается. Однако определенные реализации, находящиеся в слое выше, могут интерпретировать фрагмент, чтобы получить вторичный ресурс.

Сравнение производится байт за байтом после нормализации всех компонентов IRI.

Соображения IANA

5.1. Известный реестр URI

Эта спецификация обновляет процедуры регистрации для реестра «Хорошо известный URI», впервые определенного в ; см. раздел 3.1.

Известные URI регистрируются по рекомендации одного или нескольких экспертов с необходимой спецификацией (с использованием терминологии из ).

Основными соображениями экспертов при оценке заявок на регистрацию являются:

Соответствие требованиям
Наличие и стабильность уточняющего документа
Соображения, изложенные в

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

Согласно этому документу IANA имеет:

Обновлена процедура регистрации до Требуемой спецификации.
Добавлен столбец «Статус» (Status) в реестр и помечены все существующие регистрации как «постоянные» (permanent).

5.2. Реестр схем универсального идентификатора ресурса (URI)

Эта спецификация добавляет поле в шаблон регистрации реестра «Схемы универсального идентификатора ресурса (URI)» с именем «Поддержка общеизвестных URI» и значением по умолчанию «-».

Если схема URI была явно указана для использования хорошо известных URI согласно Разделу 3, значение изменяется на ссылку на эту спецификацию. Начальные значения, не равные «-», приведены в таблице 1.

Схема URI	Хорошо известная поддержка URI
coap
coap+tcp
coap+ws
coaps
coaps+tcp
coaps+ws
http
https
ws
wss

Таблица 1: строки в реестре схемы URI с непустым новым столбцом

Ссылки

6.1. Нормативные ссылки

Bradner, S., «Key words for use in RFCs to Indicate Requirement Levels», BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.

Berners-Lee, T., Fielding, R., and L. Masinter, «Uniform Resource Identifier (URI): Generic Syntax», STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005, <https://www.rfc-editor.org/info/rfc3986>.

Barth, A., «The Web Origin Concept», RFC 6454, DOI 10.17487/RFC6454, December 2011, <https://www.rfc-editor.org/info/rfc6454>.

Fielding, R., Ed. and J. Reschke, Ed., «Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing», RFC 7230, DOI 10.17487/RFC7230, June 2014, <https://www.rfc-editor.org/info/rfc7230>.

Cotton, M., Leiba, B., and T. Narten, «Guidelines for Writing an IANA Considerations Section in RFCs», BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/info/rfc8126>.

Leiba, B., «Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words», BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.

6.2. Информационные ссылки

West, M., «Content Security Policy Level 3», World Wide Web Consortium WD WD-CSP3-20160913, September 2016, <https://www.w3.org/TR/2016/WD-CSP3-20160913>.

WHATWG, «Fetch — Living Standard», <https://fetch.spec.whatwg.org>.

WHATWG, «HTML — Living Standard», <https://html.spec.whatwg.org>.

Marchiori, M., «The Platform for Privacy Preferences 1.0 (P3P1.0) Specification», World Wide Web Consortium Recommendation REC-P3P-20020416, April 2002, <http://www.w3.org/TR/2002/REC-P3P-20020416>.

Eisinger, J. and E. Stark, «Referrer Policy», World Wide Web Consortium CR CR-referrer-policy-20170126, January 2017, <https://www.w3.org/TR/2017/CR-referrer-policy-20170126>.

Bradner, S., «The Internet Standards Process — Revision 3», BCP 9, RFC 2026, DOI 10.17487/RFC2026, October 1996, <https://www.rfc-editor.org/info/rfc2026>.

Rescorla, E. and B. Korver, «Guidelines for Writing RFC Text on Security Considerations», BCP 72, RFC 3552, DOI 10.17487/RFC3552, July 2003, <https://www.rfc-editor.org/info/rfc3552>.

Dusseault, L., Ed., «HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV)», RFC 4918, DOI 10.17487/RFC4918, June 2007, <https://www.rfc-editor.org/info/rfc4918>.

Nottingham, M. and E. Hammer-Lahav, «Defining Well-Known Uniform Resource Identifiers (URIs)», RFC 5785, DOI 10.17487/RFC5785, April 2010, <https://www.rfc-editor.org/info/rfc5785>.

Barth, A., «HTTP State Management Mechanism», RFC 6265, DOI 10.17487/RFC6265, April 2011, <https://www.rfc-editor.org/info/rfc6265>.

Fielding, R., Ed. and J. Reschke, Ed., «Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content», RFC 7231, DOI 10.17487/RFC7231, June 2014, <https://www.rfc-editor.org/info/rfc7231>.

Shelby, Z., Hartke, K., and C. Bormann, «The Constrained Application Protocol (CoAP)», RFC 7252, DOI 10.17487/RFC7252, June 2014, <https://www.rfc-editor.org/info/rfc7252>.

Nottingham, M., «URI Design and Ownership», BCP 190, RFC 7320, DOI 10.17487/RFC7320, July 2014, <https://www.rfc-editor.org/info/rfc7320>.

Bormann, C., «Well-Known URIs for the WebSocket Protocol», RFC 8307, DOI 10.17487/RFC8307, January 2018, <https://www.rfc-editor.org/info/rfc8307>.

Bormann, C., Lemay, S., Tschofenig, H., Hartke, K., Silverajan, B., and B. Raymor, Ed., «CoAP (Constrained Application Protocol) over TCP, TLS, and WebSockets», RFC 8323, DOI 10.17487/RFC8323, February 2018, <https://www.rfc-editor.org/info/rfc8323>.

Hickson, I., «Web Storage (Second Edition)», World Wide Web Consortium Recommendation REC-webstorage-20160419,
April 2016, <http://www.w3.org/TR/2016/REC-webstorage-20160419>.

1.3 СХЕМА URI

Полная схема

< scheme-name >:< command-name >»|»< command-argument-descriptor > «|»< command-argument >

Согласно данному документу URI может содержать один или несколько аргументов команды, каждый из которых должен содержать элементы < command-argument-descriptor > и < command-argument >, разделенные символом вертикальной черты («|»). Если в URI несколько аргументов команд, они должны быть разделены вертикальной чертой («|»).

Эти схемы не содержат компонент центра, как определено в разделе 3.2 документа RFC 3986. Вызов команд, указанных в этом документе, происходит в контексте системы, вызывающей команду. Например, если URI «ms-excel:ofv|u|https://contoso/Q4/budget.xls» вызывается с личного компьютера под управлением Microsoft Windows с установленным Microsoft Office 2013, ожидаемым результатом будет запуск локальной установки Microsoft Excel, которой передаются аргументы для открытия файла https://contoso/Q4/budget.xls в режиме только для чтения

Синтаксис содержит следующие элементы:

. Это тип вызываемого приложения. Например, имя схемы ms-word: зарегистрировано Microsoft Word.

Разделитель «:»

. Этот элемент описывает действия, которые должно выполнить приложение, например открыть документ для просмотра. Список имен команд описан в разделе 1.5.

Разделитель «|» (вертикальная черта)

. Этот элемент предоставляет дополнительные сведения об аргументе команды.

Разделитель «|» (вертикальная черта)

. Аргументы зависят от команды. Общий аргумент это URI документа, обычно использующий схему http или https

Обратите внимание, что в сегментах зарезервированные RFC 3986 символы «:» и «/» входят в данные аргумента, а не представляют разделители, поэтому их можно добавлять без экранирования.

Сокращенная схема

Сокращенная форма схем офисных URI позволяет использовать более компактные запросы для запуска указанного приложения Office для открытия ресурса, расположенного по указанному URI. Эта сокращенная форма предполагает, что использует элемент < command-name > «ofv» и элемент < command-argument-descriptor > «u». Другие команды и аргументы команд для этой схемы не разрешены.

< scheme-name >:< command-argument >

< scheme-name >: Тип вызываемого приложения. Например, ms-word: для Microsoft Word.
< command-argument >. URI ресурса, который должно открыть приложение. В текущий момент поддерживаются только URI на основе схемы http или https.

Методы

	Является устаревшей. Является устаревшей. Является устаревшей. Преобразует сохраненный во внутреннем хранилище универсальный код ресурса в каноническую форму.
	Определяет, является ли указанное имя узла допустимым DNS-именем.
	Определяет, является ли допустимым указанное имя схемы.
	Является устаревшей. Является устаревшей. Является устаревшей. Вызов этого метода ни на что не влияет.
	Сравнивает указанные части двух универсальных кодов ресурса, используя заданные правила сравнения.
	Создает объект, который содержит всю необходимую информацию для создания прокси-сервера, используемого для взаимодействия с удаленным объектом. (Унаследовано от MarshalByRefObject)
	Сравнивает два экземпляра Uri на предмет их равенства.
	Является устаревшей. Является устаревшей. Является устаревшей. Преобразует все небезопасные или зарезервированные символы в компонент пути, используя шестнадцатеричное представление.
	Преобразует строку в ее escape-представление.
	Является устаревшей. Является устаревшей. Является устаревшей. Преобразует строку в ее escape-представление.
	Является устаревшей. Преобразует строку универсального кода ресурса в ее escape-представление.
	Получает десятичное значение шестнадцатеричной цифры.
	Получает заданные компоненты текущего экземпляра, используя указанное для специальных знаков escape-преобразование.
	Получает хэш-код для универсального кода ресурса.
	Возвращает заданную часть экземпляра Uri.
	Является устаревшей. Извлекает объект обслуживания во время существования, который управляет политикой времени существования данного экземпляра. (Унаследовано от MarshalByRefObject)
	Возвращает данные, необходимые для сериализации текущего экземпляра.
	Возвращает объект Type для текущего экземпляра. (Унаследовано от Object)
	Преобразует заданный символ в эквивалентное ему шестнадцатеричное число.
	Преобразует шестнадцатеричное представление символа в сам символ.
	Является устаревшей. Получает объект службы времени существования для управления политикой времени существования для этого экземпляра. (Унаследовано от MarshalByRefObject)
	Является устаревшей. Является устаревшей. Является устаревшей. Указывает, является ли символ недопустимым в имени файловой системы.
	Определяет, является ли текущий экземпляр Uri основой указанного экземпляра Uri.
	Является устаревшей. Является устаревшей. Является устаревшей. Определяет, следует ли экранировать указанный символ.
	Определяет, является ли указанный символ допустимой шестнадцатеричной цифрой.
	Определяет, является ли кодировка символа шестнадцатеричной.
	Является устаревшей. Является устаревшей. Является устаревшей. Определяет, является ли указанный символ зарезервированным.
	Указывает, является ли строка, используемая для создания этого Uri, правильно сформированной и не требующей дальнейшего экранирования.
	Указывает, является ли правильным формат данной строки, пытаясь создать на ее основе универсальный код ресурса и проверяя, не требуется ли для нее дополнительное преобразование в escape-последовательность.
	Является устаревшей. Является устаревшей. Является устаревшей. Определяет разницу между двумя экземплярами класса Uri.
	Определяет разницу между двумя экземплярами класса Uri.
	Создает неполную копию текущего объекта Object. (Унаследовано от Object)
	Создает неполную копию текущего объекта MarshalByRefObject. (Унаследовано от MarshalByRefObject)
	Является устаревшей. Является устаревшей. Является устаревшей. Анализирует универсальный код ресурса текущего экземпляра и проверяет, действительно ли этот код содержит все обязательные части допустимого универсального кода ресурса.
	Возвращает каноническое строковое представление заданного экземпляра Uri.
	Создает новый Uri, используя заданный экземпляр String и UriKind.
	Создает новый Uri, используя заданные экземпляры базового и относительного String.
	Создает новый Uri, используя заданные экземпляры базового и относительного Uri.
	Является устаревшей. Является устаревшей. Является устаревшей. Преобразует указанную строку, заменив все escape-последовательности их представлениями, к которым не было применено escape-преобразование.
	Отменяет преобразование строки в escape-представление.