.NET 3.5 を使用しているため、この方法では無効なパス文字と見なされるという2.0
System.Web
欠陥があるアセンブリを使用しています。これは、バージョン固有の MSDN ページ?
のコミュニティ コメントに記載されています。
internal
逆アセンブルすると、呼び出しが ( )で終わることがわかりますVirtualPath.Create
。
else if (VirtualPath.ContainsIllegalVirtualPathChars(virtualPath))
{
throw new HttpException(System.Web.SR.GetString("Invalid_vpath", new object[1]
{
(object) virtualPath
}));
}
どの参照
private static char[] s_illegalVirtualPathChars = new char[4]
{
':',
'?',
'*',
char.MinValue
};
これらのいくつかは、パスの悪い文字と合理的に見なすことができますが、?
実際には拒否されるべきではありません。
より目利きになるように書き直された4.0
System.Web
ショーの分解。VirtualPath.Create
この web.archive キャプチャは、現在は機能していない blogs.msdn の投稿をキャプチャしたもので、この問題に関する最も初期の言及の 1 つを示しています。MS の従業員は次のように答えます。
2006 年 2 月 26 日 日曜日 午後 11 時 49 分 DmitryR により 例外~/path?qs
はバグであり、修正する必要があります...
ResolveAppRelativeLinkToUrl
最も簡単な修正は、への呼び出しの前後に
クエリ文字列を保存/復元する
ことVirtualPathUtility.ToAbsolute
です。
回避策は、「~/...」の代わりに完全修飾 UTL を使用することです。
ありがとう、
ドミトリー
whereResolveAppRelativeLinkToUrl
はレポーターのコードのメソッド名を指します。
別の回避策は、 へ?
の呼び出しの前に安全なトークンにVirtualPathUtility.ToAbsolute
置き換え、後で置き換えを元に戻すことです。
public static string SafeToAbsolute(string path)
{
var madeSafe = path.Replace("?", "UNLIKELY_TOKEN");
var absolute = VirtualPathUtility.ToAbsolute(madeSafe);
var restored = absolute.Replace("UNLIKELY_TOKEN", "?");
return restored;
}
アプリケーションに適した可能性が低いトークンを選択します。