stringtranslate.com

Унифицированный идентификатор ресурса

Унифицированный идентификатор ресурса ( URI ), ранее универсальный идентификатор ресурса , представляет собой уникальную последовательность символов, которая идентифицирует абстрактный или физический ресурс, [1] такой как ресурсы на веб-странице, почтовый адрес, номер телефона, [2] книги, объекты реального мира, такие как люди и места, концепции. [3] URI используются для идентификации чего-либо, описанного с использованием структуры описания ресурсов (RDF), например, концепции, которые являются частью онтологии, определенной с использованием языка веб-онтологии (OWL), и люди, которые описаны с использованием словаря «друг друга», будут иметь каждый индивидуальный URI.

URI, которые предоставляют средства для поиска и извлечения информационных ресурсов в сети (в Интернете или в другой частной сети, такой как файловая система компьютера или Интранет ), являются унифицированными указателями ресурсов ( URL ). Таким образом, URL являются подмножеством URI, т. е. каждый URL является URI (и не обязательно наоборот). [2] Другие URI предоставляют только уникальное имя, без средств поиска или извлечения ресурса или информации о нем; это унифицированные имена ресурсов (URN). Веб-технологии, которые используют URI, не ограничиваются веб-браузерами .

История

Зачатие

URI и URL имеют общую историю. В 1990 году предложения Тима Бернерса-Ли по гипертексту неявно ввели идею URL как короткой строки, представляющей ресурс, являющийся целью гиперссылки . [ 4] В то время люди называли его «гипертекстовым именем» [5] или «именем документа».

В течение следующих трех с половиной лет, по мере развития основных технологий Всемирной паутины HTML , HTTP и веб-браузеров , возникла необходимость различать строку, которая предоставляла адрес ресурса, от строки, которая просто называла ресурс. Хотя формально это еще не было определено, термин Uniform Resource Locator стал представлять первое, а более спорный Uniform Resource Name стал представлять второе. В июле 1992 года в отчете Бернерса-Ли о рабочей группе по инжинирингу Интернета (IETF) «UDI (Universal Document Identifiers) BOF » упоминаются URL (как Uniform Resource Locators), URN (первоначально как Unique Resource Numbers) и необходимость создания новой рабочей группы. [6] В ноябре 1992 года рабочая группа IETF «URI» собралась впервые. [7]

В ходе дебатов по поводу определения URL и URN стало очевидно, что концепции, воплощенные в этих двух терминах, были всего лишь аспектами фундаментального, всеобъемлющего понятия идентификации ресурсов . В июне 1994 года IETF опубликовала первый Запрос на комментарии Бернерса-Ли , в котором признавалось существование URL и URN. Что наиболее важно, он определил формальный синтаксис для универсальных идентификаторов ресурсов (т. е. строк, подобных URL, точный синтаксис и семантика которых зависели от их схем). Кроме того, RFC  1630 попытался обобщить синтаксисы схем URL, используемых в то время. Он признавал — но не стандартизировал — существование относительных URL и идентификаторов фрагментов. [8]

Уточнение

В декабре 1994 года RFC  1738 формально определил относительные и абсолютные URL-адреса, уточнил общий синтаксис URL-адресов, определил, как преобразовывать относительные URL-адреса в абсолютную форму, и лучше перечислил используемые в то время схемы URL-адресов. [9] Согласованное определение и синтаксис URN пришлось ждать до публикации IETF RFC  2141 [10] в мае 1997 года.

Публикация IETF RFC  2396 [11] в августе 1998 года привела к тому, что синтаксис URI стал отдельной спецификацией [11] , и большинство частей RFC 1630 и 1738, касающихся URI и URL в целом, были пересмотрены и расширены IETF. Новый RFC изменил значение U в URI с «универсального» на «единообразный».

В декабре 1999 года RFC  2732 [12] предоставил небольшое обновление RFC 2396, позволив URI вмещать адреса IPv6 . Ряд недостатков, обнаруженных в двух спецификациях, привели к усилиям сообщества, координируемым соавтором RFC 2396 Роем Филдингом , которые завершились публикацией IETF RFC  3986 [13] в январе 2005 года. Хотя предыдущий стандарт и стал устаревшим, он не сделал устаревшими детали существующих схем URL; RFC 1738 продолжает регулировать такие схемы, за исключением случаев, когда он был заменен. Например, IETF RFC  2616 [14] уточняет схему. Одновременно IETF опубликовала содержание RFC 3986 как полный стандарт STD 66, отражающий установление общего синтаксиса URI в качестве официального интернет-протокола.http

В 2001 году Группа технической архитектуры (TAG) Консорциума Всемирной паутины (W3C) опубликовала руководство по передовому опыту и каноническим URI для публикации нескольких версий одного ресурса. [15] Например, контент может отличаться по языку или размеру, чтобы адаптироваться к емкости или настройкам устройства, используемого для доступа к этому контенту.

В августе 2002 года в документе IETF RFC  3305 [16] было отмечено, что термин «URL», несмотря на широкое публичное использование, практически устарел и служит лишь напоминанием о том, что некоторые URI действуют как адреса, имея схемы, подразумевающие доступность сети, независимо от любого такого фактического использования. Как показывают стандарты на основе URI, такие как Resource Description Framework , идентификация ресурсов не обязательно должна предполагать извлечение представлений ресурсов через Интернет, и они вообще не должны подразумевать сетевые ресурсы.

Семантическая паутина использует схему HTTP URI для идентификации как документов, так и концепций для практического использования, различие, которое вызвало путаницу относительно того, как различать эти два понятия. В 2005 году TAG опубликовал электронное письмо с решением проблемы, которое стало известно как резолюция httpRange-14 . [17] Впоследствии W3C опубликовал заметку группы по интересам под названием Cool URIs for the Semantic Web , в которой более подробно объяснялось использование согласования контента и кода ответа HTTP 303 для перенаправлений. [18]

Дизайн

URL-адреса и URN-номера

Унифицированное имя ресурса (URN) — это URI, который идентифицирует ресурс по имени в определенном пространстве имен. URN может использоваться для описания ресурса без указания его местоположения или способа доступа к нему. Например, в системе международных стандартных книжных номеров (ISBN) ISBN 0-486-27557-4 идентифицирует конкретное издание пьесы Уильяма Шекспира «Ромео и Джульетта» . URN для этого издания будет urn:isbn:0-486-27557-4 . Однако он не дает никакой информации о том, где найти копию этой книги.

Единый указатель ресурса (URL) — это URI, который указывает средства действия или получения представления ресурса, т. е. указывает как его основной механизм доступа, так и сетевое местоположение. Например, URL http://example.org/wiki/Uniform_Resource_Identifiers/Main_Pageссылается на ресурс, идентифицированный как /wiki/Uniform_Resource_Identifiers/Main_Page, представление которого можно получить через протокол передачи гипертекста ( http: ) с сетевого хоста, доменное имя которого example.org. (В этом случае HTTP обычно подразумевает, что это будет в форме HTML и связанного кода. На практике это не обязательно так, поскольку HTTP позволяет указывать произвольные форматы в своем заголовке.)

URN аналогичен имени человека, а URL аналогичен его адресу. Другими словами, URN идентифицирует элемент, а URL предоставляет метод его поиска.

Технические публикации, особенно стандарты, разработанные IETF и W3C, обычно отражают точку зрения, изложенную в Рекомендации W3C от 30 июля 2001 года, которая признает приоритет термина URI, а не одобряет какое-либо формальное подразделение на URL и URN.

URL — полезная, но неформальная концепция: URL — это тип URI, который идентифицирует ресурс посредством представления его основного механизма доступа (например, его сетевого «местоположения»), а не посредством некоторых других атрибутов, которые он может иметь. [19]

Таким образом, URL — это просто URI, который указывает на ресурс в сети. [a] [16] Однако в нетехнических контекстах и ​​в программном обеспечении для Всемирной паутины термин «URL» по-прежнему широко используется. Кроме того, термин «веб-адрес» (не имеющий формального определения) часто встречается в нетехнических публикациях как синоним URI, который использует схемы http или https . Такие предположения могут привести к путанице, например, в случае пространств имен XML, которые имеют визуальное сходство с разрешимыми URI.

Спецификации, разработанные WHATWG, отдают предпочтение URL, а не URI , и поэтому новые API HTML5 используют URL, а не URI . [20]

Стандартизируйте термин URL. URI и IRI [Internationalized Resource Identifier] просто сбивают с толку. На практике для обоих используется один алгоритм, поэтому сохранение их различий никому не помогает. URL также легко выигрывает конкурс популярности результатов поиска. [21]

Хотя большинство схем URI изначально были разработаны для использования с определенным протоколом и часто имеют одинаковое имя, они семантически отличаются от протоколов. Например, схема http обычно используется для взаимодействия с веб-ресурсами с использованием HTTP, но файл схемы не имеет протокола.

Синтаксис

URI имеет схему, которая ссылается на спецификацию для назначения идентификаторов в рамках этой схемы. Таким образом, синтаксис URI является федеративной и расширяемой системой именования, в которой спецификация каждой схемы может дополнительно ограничивать синтаксис и семантику идентификаторов, использующих эту схему. Общий синтаксис URI является надмножеством синтаксиса всех схем URI. Впервые он был определен в RFC  2396, опубликованном в августе 1998 года, [11] и окончательно оформлен в RFC  3986, опубликованном в январе 2005 года. [22]

URI состоит из разрешенного набора символов ASCII , состоящего из зарезервированных символов (общие разделители: :, /, ?, #, [, ], и @; подразделители: !, $, &, ', (, ), *, , +, ,, ;, и =), [23] незарезервированных символов ( заглавные и строчные буквы , десятичные цифры , -, ., _, и ~), [23] и символа %. [24] Компоненты и подкомпоненты синтаксиса отделяются разделителями от зарезервированных символов (только от общих зарезервированных символов для компонентов) и определяют идентификационные данные, представленные как незарезервированные символы, зарезервированные символы, которые не действуют как разделители в компоненте и подкомпоненте соответственно, [13] : §2  и процентные кодировки , когда соответствующий символ находится за пределами разрешенного набора или используется в качестве разделителя компонента или внутри него. Процентное кодирование идентифицирующего октета данных представляет собой последовательность из трех символов, состоящую из символа, %за которым следуют две шестнадцатеричные цифры, представляющие числовое значение этого октета. [13] : §2.1 

Общий синтаксис URI состоит из пяти компонентов, организованных иерархически в порядке убывания значимости слева направо: [13] : §3 

URI = схема ":" ["//" полномочия] путь ["?" запрос] ["#" фрагмент]

Компонент не определен , если он имеет связанный разделитель и разделитель не отображается в URI; компоненты схемы и пути всегда определены. [13] : §5.2.1  Компонент пуст, если он не имеет символов; компонент схемы всегда непустой. [13] : §3 

Компонент полномочий состоит из подкомпонентов :

полномочия = [userinfo "@"] хост [":" порт]

На синтаксической диаграмме это представлено следующим образом:

Диаграмма синтаксиса URI

URI включает в себя:

По соглашению, в http и https URI последняя часть пути называетсяpathinfo и он необязателен. Он состоит из нуля или более сегментов пути, которые не ссылаются на существующее имя физического ресурса (например, файл, внутренняя модульная программа или исполняемая программа), а на логическую часть (например, команда или часть квалификатора), которая должна быть передана отдельно в первую часть пути, которая идентифицирует исполняемый модуль или программу, управляемую веб-сервером;это часто используется для выбора динамического содержимого (документа и т. д.) или для его адаптации в соответствии с запросом (см. также:CGIи PATH_INFO и т. д.).
Пример:
URI-адрес:"http://www.example.com/questions/3456/my-document"
где: "/questions"— первая часть пути ( исполняемый модуль или программа), а "/3456/my-document"— вторая часть пути с именем pathinfo , которая передается исполняемому модулю или программе с именем "/questions"для выбора запрошенного документа.
URI http или https, содержащий часть pathinfo без части запроса, также может называться « чистым URL », последняя часть которого может быть « слагом ».

Зарезервированный символ, специфичный для схемы или реализации, +может использоваться в схеме, информации о пользователе, хосте, пути, запросе и фрагменте, а зарезервированные символы, специфичные для схемы или реализации !, $, &, ', (, ), *, ,, ;, , и =могут использоваться в информации о пользователе, хосте, пути, запросе и фрагменте. Кроме того, общий зарезервированный символ :может использоваться в информации о пользователе, пути, запросе и фрагменте, общие зарезервированные символы @и /могут использоваться в пути, запросе и фрагменте, а общий зарезервированный символ ?может использоваться в запросе и фрагменте. [13] : §A 

Примеры URI

На следующем рисунке показаны примеры URI и их составные части.

 информация о пользователе  хост порт ┌──┴───┐ ┌────────┴─────┐ ┌┴─┐     https://[email protected]:1234/forum/questions/?tag=networking&order=newest#top └─┬─┘  └────────────┬─────────────┘ └───────┬─────── ┘ └────────────┬────────────┘ └┬┘ схема полномочия путь запрос фрагмент userinfo хост порт ┌──┴────┐ ┌────────────┐ ┌┴─┐              https://[email protected]:1234/forum/questions/?tag=networking&order=newest#:~:text=whatever └─┬─┘  └────────────┬─────────────┘ └───────┬─────── ┘ └────────────┬────────────┘ └───────┬───────┘ фрагмент запроса пути полномочий схемы        ldap://[2001:db8::7]/c=GB?objectClass?one └┬─┘  └──────┬─────┘ └─┬─┘ └───────┬──────┘ запрос пути к схеме полномочий      mailto:[email protected] └─┬──┘  └────┬──────────────┘ схема пути   новости:comp.infosystems.www.servers.unix └┬─┘  └────────────────┬──────────────────┘ схема пути   тел:+1-816-555-1212 └┬┘  └───────┬──────┘ схема пути   телнет://192.0.2.16:80/ └─┬──┘  └─────┬─────┘ │ схема путь полномочий    urn:oasis:names:specification:docbook:dtd:xml:4.1.2 └┬┘  └────────────────────────────┬────────────────────────┘ схема пути

DOI ( цифровые идентификаторы объектов ) вписываются в систему дескрипторов и в систему URI, чему способствует соответствующий синтаксис .

Ссылки URI

Ссылка URI является либо URI, либо относительной ссылкой , если она не начинается с компонента схемы, за которым следует двоеточие ( :). [13] : §4.1  Сегмент пути, содержащий символ двоеточия (например, foo:bar), не может использоваться в качестве первого сегмента пути относительной ссылки, если его компонент пути не начинается с косой черты ( /), поскольку он будет ошибочно принят за компонент схемы. Такому сегменту пути должен предшествовать сегмент пути с точкой (например, ./foo:bar). [13] : §4.2 

Языки разметки веб-документов часто используют ссылки URI для указания на другие ресурсы, такие как внешние документы или определенные части того же логического документа: [13] : §4.4 

https://example.com/path/resource.txt#fragment//example.com/path/resource.txt/путь/ресурс.txtпуть/ресурс.txt../ресурс.txt./ресурс.txtресурс.txt#фрагмент

Разрешение

Разрешение ссылки URI по базовому URI приводит к целевому URI . Это подразумевает, что базовый URI существует и является абсолютным URI (URI без фрагментного компонента). Базовый URI можно получить, в порядке приоритета, из: [13] : §5.1 

В представлении с четко определенным базовым URI

http://a/b/c/d;p?q

относительная ссылка разрешается в ее целевой URI следующим образом: [13] : §5.4 

"г:ч" -> "г:ч""г" -> "http://a/b/c/g""./g" -> "http://a/b/c/g""г/" -> "http://a/b/c/g/""/g" -> "http://a/g""//г" -> "http://г""?y" -> "http://a/b/c/d;p?y""г?у" -> "http://a/b/c/g?у""#s" -> "http://a/b/c/d;p?q#s""г#с" -> "http://a/b/c/g#s""г?y#s" -> "http://a/b/c/g?y#s"";x" -> "http://a/b/c/;x""г;х" -> "http://a/b/c/г;х""g;x?y#s" -> "http://a/b/c/g;x?y#s""" -> "http://a/b/c/d;p?q""." -> "http://a/b/c/""./" -> "http://a/b/c/"".." -> "http://a/b/""../" -> "http://a/b/""../g" -> "http://a/b/g""../.." -> "http://a/""../../" -> "http://a/""../../g" -> "http://a/g"

URL-адрес искажения

URL munging — это метод, при котором команда добавляется к URL, обычно в конце, после токена "?" . Он обычно используется в WebDAV как механизм добавления функциональности к HTTP . В системе управления версиями, например, для добавления команды "checkout" к URL, она записывается как http://editing.com/resource/file.php?command=checkout. Он имеет то преимущество, что он прост для парсеров CGI , а также действует как посредник между HTTP и базовым ресурсом, в данном случае. [28]

Связь с пространствами имен XML

В XML пространство имен — это абстрактный домен, которому может быть назначена коллекция имен элементов и атрибутов. Имя пространства имен — это строка символов, которая должна соответствовать общему синтаксису URI. [29] Однако имя обычно не считается URI, [30] поскольку спецификация URI основывает решение не только на лексических компонентах, но и на их предполагаемом использовании. Имя пространства имен не обязательно подразумевает какую-либо семантику схем URI; например, имя пространства имен, начинающееся с http:, может не иметь никакого отношения к использованию HTTP .

Первоначально имя пространства имен могло соответствовать синтаксису любой непустой ссылки URI, но использование относительных ссылок URI было признано устаревшим W3C. [31] Отдельная спецификация W3C для пространств имен в XML 1.1 позволяет ссылкам на интернационализированные идентификаторы ресурсов (IRI) служить основой для имен пространств имен в дополнение к ссылкам URI. [32]

Смотрите также

Примечания

  1. ^ Отчет, опубликованный в 2002 году совместной рабочей группой W3C/IETF, был направлен на нормализацию расхождений во взглядах, существующих в IETF и W3C относительно взаимосвязи между различными терминами и стандартами 'UR*'. Хотя он не был опубликован как полный стандарт ни одной из организаций, он стал основой для вышеуказанного общего понимания и с тех пор повлиял на многие стандарты.
  2. ^ Процедуры регистрации новых схем URI были первоначально определены в 1999 году в RFC  2717, а теперь определены в RFC 7595, опубликованном в июне 2015 года. [25]
  3. ^ Для URI, относящихся к ресурсам Всемирной паутины, некоторые веб-браузеры позволяют .0опускать части точечно-десятичной записи или использовать необработанные целочисленные IP-адреса. [26]
  4. ^ Исторический RFC  1866 (устаревший с появлением RFC 2854) призывает авторов CGI поддерживать «;» в дополнение к «&». [27] : §8.2.1 

Ссылки

  1. ^ Бернерс-Ли, Тим; Филдинг, Рой Т.; Масинтер, Ларри 2005, стр. 1, «Аннотация»
  2. ^ ab Бернерс-Ли, Тим; Филдинг, Рой Т.; Масинтер, Ларри 2005, стр. 7; "1.1.2. Примеры", "1.1.3. URI, URL и URN"
  3. ^ Бернерс-Ли, Тим; Филдинг, Рой Т.; Масинтер, Ларри 2005, стр. 5, «Ресурс: термин «ресурс» используется в общем смысле для всего, что может быть идентифицировано с помощью URI»
  4. ^ Палмер, Шон. «Ранняя история HTML». infomesh.net . Получено 06.12.2020 .
  5. ^ "Схемы именования W3". www.w3.org . 1992 . Получено 2020-12-06 .
  6. ^ "Труды двадцать четвертой целевой группы по инжинирингу Интернета" (PDF) . стр. 193 . Получено 27.07.2021 .
  7. ^ "Труды Двадцать пятой целевой группы по инжинирингу Интернета" (PDF) . стр. 501 . Получено 27.07.2021 .
  8. ^ Бернерс-Ли, Тим (июнь 1994 г.). Универсальные идентификаторы ресурсов в WWW: унифицированный синтаксис для выражения имен и адресов объектов в сети, используемых во Всемирной паутине. Сетевая рабочая группа. doi : 10.17487/RFC1630 . RFC 1630. Информационный.
  9. ^ T. Berners-Lee ; L. Masinter ; M. McCahill (декабрь 1994 г.). Единые указатели ресурсов (URL). Сетевая рабочая группа. doi : 10.17487/RFC1738 . RFC 1738. Устарело. Устарело согласно RFC 4248 и 4266. Обновлено согласно RFC 1808, 2368, 2396, 3986, 6196, 6270 и 8089.
  10. ^ Р. Моутс (май 1997 г.). Синтаксис URN. Сетевая рабочая группа. doi : 10.17487/RFC2141 . RFC 2141. Предложенный стандарт. Устаревший из-за RFC 8141.
  11. ^ abcd T. Berners-Lee ; R. Fielding ; L. Masinter (август 1998 г.). Единые идентификаторы ресурсов (URI): общий синтаксис. Сетевая рабочая группа. doi : 10.17487/RFC2396 . RFC 2396. Устарело. Устарело по RFC 3986. Обновлено по RFC 2732. Обновления RFC 1808 и 1738.
  12. ^ Р. Хинден; Б. Карпентер; Л. Масинтер (декабрь 1999 г.). Формат буквальных адресов IPv6 в URL. Сетевая рабочая группа. doi : 10.17487/RFC2732 . RFC 2732. Устарело. Устарело согласно RFC 3986.
  13. ^ abcdefghijklm T. Berners-Lee ; R. Fielding ; L. Masinter (январь 2005 г.). Унифицированный идентификатор ресурса (URI): универсальный синтаксис. Сетевая рабочая группа. doi : 10.17487/RFC3986 . STD 66. RFC 3986. Стандарт Интернета 66. Отменяет RFC 2732, 2396 и 1808. Обновлен RFC 6874, 7320 и 8820. Обновляет RFC 1738.
  14. ^ R. Fielding ; J. Gettys; J. Mogul; H. Frystyk ; L. Masinter ; P. Leach; T. Berners-Lee (август 1999 г.). Протокол передачи гипертекста — HTTP/1.1. Сетевая рабочая группа. doi : 10.17487/RFC2616 . RFC 2616. Устарело. Устарело в соответствии с RFC 7230, 7231, 7232, 7233, 7234 и 7235. Устаревший RFC 2068. Обновлено в соответствии с RFC 2817, 5785, 6266 и 6585.
  15. ^ Раман, ТВ (2006-11-01). «О связывании альтернативных представлений для обеспечения обнаружения и публикации». www.w3.org . Получено 2020-12-06 .
  16. ^ ab Mealling, Michael H.; Denenberg, Ray (август 2002 г.). Отчет Объединенной группы W3C/IETF по планированию URI: Единые идентификаторы ресурсов (URI), URL-адреса и Единые имена ресурсов (URN): разъяснения и рекомендации. Сетевая рабочая группа. doi : 10.17487/RFC3305 . RFC 3305. Информационный.
  17. ^ Филдинг, Рой (2005-06-18). "[httpRange-14] Решено". lists.w3.org . Получено 2020-12-06 .
  18. ^ Sauermann, Leo (декабрь 2008 г.). «Cool URIs for the Semantic Web». www.w3.org . Получено 06.12.2020 .
  19. ^ Группа по планированию URI, W3C/IETF (сентябрь 2001 г.). «URI, URL и URN: разъяснения и рекомендации 1.0». www.w3.org . W3C/IETF . Получено 08.12.2020 .
  20. ^ «Стандарт URL: 6.3. URL API в других местах».
  21. ^ «Стандарт URL: Цели».
  22. ^ Бернерс-Ли, Тим; Филдинг, Рой Т.; Масинтер, Ларри 2005, стр. 46; "9. Благодарности"
  23. ^ ab Бернерс-Ли, Тим; Филдинг, Рой Т.; Масинтер, Ларри 2005, стр. 13–14; «2.2. Зарезервированные символы», «2.3. Незарезервированные символы»
  24. ^ Бернерс-Ли, Тим; Филдинг, Рой Т.; Масинтер, Ларри 2005, стр. 12; "2.1. Процентное кодирование"
  25. ^ Хансен, Тони; Харди, Тед (июнь 2015 г.). Талер, Дэйв (ред.). Руководящие принципы и процедуры регистрации для схем URI. Internet Engineering Task Force . doi : 10.17487/RFC7595 . ISSN  2070-1721. BCP 35. RFC 7595. Лучшая текущая практика. Обновлено RFC 8615. Отменяет RFC 4395.
  26. ^ Лоуренс (2014).
  27. ^ Бернерс-Ли, Тим ; Коннолли, Дэниел В. (ноябрь 1995 г.). Язык разметки гипертекста - 2.0. Сетевая рабочая группа. doi : 10.17487/RFC1866 . RFC 1866. Историческое. Устарело согласно RFC 2854.
  28. ↑ Уайтхед 1998, стр. 38.
  29. ^ Моррисон (2006).
  30. ^ Гарольд (2004).
  31. ^ W3C (2009).
  32. ^ W3C (2006).

Цитируемые работы

Дальнейшее чтение

Внешние ссылки