В запросе класса .NET Uri отсутствует зарезервированный символ точки с запятой, простые обходные пути?

Это https://msdn.microsoft.com/en-us/library/system.uri.query.aspx и этот https://ietf.org/rfc/rfc1738.txt предполагает, что класс .Net Uri не распознает точку с запятой как допустимый символ для представления запроса в URL-адресе.

Для обходного пути требуется всего одна строка или около того, но мне нравится, когда мой код чист. Если есть решение, которое позволяет мне не выполнять синтаксический анализ строк за пределами набора классов Uri .Net, я бы предпочел это. Существует ли какой-либо существующий код .Net, который обрабатывает точки с запятой для распознавания их как части запроса в URL-адресе?


url uri c# standards-compliance
person Brad Sherard    schedule 01.12.2010    source источник

Ответы (1)


arrow_upward
1
arrow_downward

RFC 3986 согласуется с RFC 1738 (который он обновляет) в определении запроса как части, следующей за вопросительным знаком (?), и в заявлении, что точка с запятой может использоваться для разделения пар параметр-значение, «применимых к этому сегменту».

В prospero URI (единственный случай, приведенный в RFC 1738, где используется точка с запятой) точка с запятой указывает на параметр и значение параметра в пути URI, а не на запрос.

HTTP URI используют точки с запятой в своих запросах, но только после ?, например. http://example.net/search?q=something;page=2. К сожалению, фактическое использование никогда полностью не заменяло символ & для этой функции, и он плохо поддерживается кодом на стороне сервера (включая ASP.NET), что ограничивает способность кода на стороне клиента использовать его (почти ни один браузер не делает этого).

Тем не менее, в таких случаях объект .NET Uri правильно идентифицирует только ту часть, которая следует за ? как запрос, включая точки с запятой, если они есть. Его поведение правильное.

person Jon Hanna    schedule 01.12.2010
comment
О, спасибо. Я неправильно прочитал стандарт. Я думал, что точка с запятой может префикс любых других специальных символов, а не только заменить амперсанд. Спасибо. - person Brad Sherard; 01.12.2010
comment
С 1738 это было не очень ясно, хотя запрос используется только в контексте HTTP URI, который на тот момент мог иметь только & в качестве разделителя внутри запроса, в то время как у propsero URI было что-то, что, по сути, выполняло ту же работу, что и запрос и застрял в конце. Так что в тот момент было неясно, можно ли считать эту часть URI propsero запросом или нет. RFC 1808 дал более подробную информацию об определении относительных URI и... - person Jon Hanna; 01.12.2010
comment
RFC 2396 продолжил это до полных URI (обновление как 1738, так и 1808). На этом этапе значение запроса в URI в целом, а не только в случае HTTP, стало более ясным, и было указано, что это означает часть после вопросительного знака. Эти RFC, в свою очередь, устарели из-за RFC 3986/STD 66, который является самым последним RFC по URI. - person Jon Hanna; 01.12.2010
comment
Между тем, идея ; в качестве разделителя в URI в HTTP URI происходит не из этих RFC (в которых говорится, что они могут использоваться в качестве разделителей параметров в любом сегменте URI, но не говорится, что другие символы не могут), а из HTML4.01 (рекомендация в одно из приложений). Стандарт HTTP URI не зависит от того, как контент кодируется в запросе, пока он создает действительный URI, и его спецификация для application/x-www-form-urlencoded дает нам это (определено в спецификациях HTML и никогда не используется). зарегистрирован в IANA). Со всем этим не так-то просто проверить, что именно говорит стандарт. - person Jon Hanna; 01.12.2010