почему делает двоеточие “:” в Uri, переданном Uri. MakeRelativeUri вызывают исключение?
Следующая строка кода дает исключение. Действительно ли это - ошибка в платформе? Если не, какой подход я мог проявить вместо этого?
Это, кажется, ":" (двоеточие), которое вызывает в проблеме, однако я действительно вижу, что такой 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) относительную строку от аргумента HREF HTML [например, было бы "/xx:yy" в этом случае] и возвращает допустимый URI, который мог использоваться для обращения к тому ресурсу?
Другими словами, как я подражаю поведению браузера, который переводит HREF и страницу URI для создания URI, который это использует для движения в тот ресурс при нажатии на него.
3 ответа
Я считаю это ошибкой.
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 - это нормально).
Если найден толстой кишки, она пытается проанализировать значение, которое следует за дюминкой в качестве номера порта, и он не удастся, если Вы не предоставляете действительный номер порта. См. здесь Для примера аналогичной проблемы и ссылка MSDN для деталей Urishatexception .
Двоеточия играют особую роль в URL - например, обозначают порт и являются 'зарезервированными' (см. здесь).
URL-адреса используют некоторые символы для специальных использовать при определении синтаксиса. Когда эти символы не используются в их особая роль внутри URL, им нужна чтобы быть закодированным
Так что, двоеточие должно быть освобождено.