почему двоеточие ":" в Uri, переданном в Uri.MakeRelativeUri, вызывает исключение?

Question

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

Кажется, это ":" (двоеточие), которое вызывает проблему, однако я вижу, что такой URI работает на рабочих сайтах нормально (то есть, кажется, действительный URI в реальном мире)

Uri relativeUri = new Uri("http://test.com/asdf").MakeRelativeUri(new Uri("http://test.com/xx:yy"));
// gives => System.UriFormatException: A relative URI cannot be created because the 
// 'uriString' parameter represents an absolute URI

Uri relativeUri = new Uri("http://test.com/asdf").MakeRelativeUri(new Uri("http://test.com/xxyy"));
// this works - removed the colon between the xx and yy

PS. В частности, могу ли я спросить, учитывая вышеизложенный случай, какой класс / метод .NET можно использовать (учитывая, что я анализирую HTML-страницу из Интернета), чтобы взять (a) URI страницы и (b) относительную строку из HTML Аргумент HREF [например, было бы "/ xx: yy" в этом случае] и вернул бы действительный URI, который можно использовать для адресации этого ресурса?

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

Answer 1

Я считаю это ошибкой.

RFC1738 говорит, что : (среди других символов) может быть зарезервировано для специального значения в схеме. Однако схема http не резервирует ее в части пути

Within the <path> and <searchpart> components, "/", ";", "?" are reserved.

(не :.)

hsegment       = *[ uchar | ";" | ":" | "@" | "&" | "=" ]

Итак, http://test.com/xx:yy является действительным URI. Более новый RFC3968 соглашается:

pchar         = unreserved / pct-encoded / sub-delims / ":" / "@"

Однако, разумеется, при релятивизации по http://test.com/asdf результирующий xx:yy будет абсолютным URI, а не действительным относительным URI:

path-noscheme = segment-nz-nc *( "/" segment )
segment-nz-nc = 1*( unreserved / pct-encoded / sub-delims / "@" )
                ; non-zero-length segment without any colon ":"

Так что MakeRelativeUri является своего рода правом сообщить о наличии проблемы, но на самом деле это должно исправить это автоматически, кодируя :, действительный в абсолютном URI, в %3A, допустимо в первом сегменте относительного URI.

Как правило, я бы старался избегать MakeRelativeUri в пользу корневых URI, которые проще извлечь и у которых нет этой проблемы (/xx:yy в порядке).

Answer 2

Двоеточие играет особую роль в URL-адресах - например, для обозначения порта и для него «зарезервировано» ( см. Здесь ).

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

Итак, двоеточие должно быть убрано.

Answer 3

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