#c# #url #uri #standards-compliance
#c# #url #uri #соответствие стандартам
Вопрос:
Это https://msdn.microsoft.com/en-us/library/system.uri.query.aspx и это https://ietf.org/rfc/rfc1738.txt предполагают, что .Класс Net Uri не распознает точку с запятой как приемлемый символ для представления запроса в URL.
Для обхода этого требуется всего одна строка или около того, но мне нравится, когда мой код чистый. Если есть решение, которое позволяет мне не выполнять синтаксический анализ строки самостоятельно вне .Я бы предпочел чистый набор классов Uri. Существует ли какой-либо существующий .Сетевой код, который обрабатывает точки с запятой для распознавания их как части запроса в URL?
Ответ №1:
RFC 3986 согласуется с RFC 1738 (который он обновляет) в определении запроса как части, следующей за вопросительным знаком ( ? ), и в утверждении, что точка с запятой может использоваться для разделения пар параметр-значение, «применимых к этому сегменту».
В URI prospero (единственный случай, приведенный в RFC 1738, где используется точка с запятой) точки с запятой указывают параметр и значение параметра в пути к URI, а не запрос.
В запросах HTTP URI действительно используются точки с запятой, но только после ? , например http://example.net/search?q=something;page=2 . К сожалению, фактическое использование никогда полностью не заменяло amp; символ для этой функции, и он плохо поддерживается серверным кодом (включая ASP.NET ) что ограничивает способность клиентского кода использовать его (практически ни один браузер этого не делает).
Тем не менее, в таких случаях .Объект NET Uri корректно идентифицирует в качестве запроса только ту часть, которая следует за ? , включая точки с запятой, если таковые имеются. Его поведение правильное.
Комментарии:
1. О, спасибо. Я неправильно истолковал стандарт. Я думал, что точка с запятой может префиксить любые другие специальные символы, а не просто заменять амперсанд. Спасибо.
2. С 1738 это было не совсем понятно, хотя «запрос» используется только в контексте HTTP URI, который на тот момент мог иметь только amp; в качестве разделителя в запросе, в то время как в URI propsero было что-то, что по сути выполняло ту же работу, что и запрос, и застряло в конце. Итак, в этот момент было неясно, можете ли вы считать эту часть URI propsero запросом или нет. В RFC 1808 более подробно описано определение относительных URI, и …
3. RFC 2396 продолжил это до полных URI (обновив оба 1738 и 1808). На этом этапе значение «запроса» в URI в целом, а не только в случае HTTP, стало более понятным, и было указано, что оно означает часть после вопросительного знака. Эти RFC, в свою очередь, устарели в RFC 3986 / STD 66, который является самым актуальным RFC в URI.
4. Между тем, идея использования ; в качестве разделителя в URI в HTTP URI исходит не из этих RFC (в которых говорится, что они могут использоваться в качестве разделителей параметров в любом сегменте URI, но не говорится, что другие символы не могут), а из HTML4.01 (рекомендация в одном из приложений). Стандарт HTTP URI не зависит от того, как содержимое кодируется в запросе, если он выдает допустимый URI, и его спецификация для application /x-www-form-urlencoded, которая дает нам это (определено в спецификациях HTML и никогда не регистрировалось в IANA). При всем этом нелегко проверить, какой стандарт что говорит.