4

名前に「 # 」が含まれるファイルを (既存の Flurl-Http エンドポイント [1] を使用して) ダウンロードする必要があります。これはもちろん、uri-fragment 検出と競合しないように %23 にエスケープする必要があります。

しかし、Flurl は常に残りをエスケープしますが、この文字はエスケープしません。その結果、uri-fragment として解析されたため、パスの半分とすべてのクエリ パラメータが欠落している動作しない uri が生成されます。

Url url = "http://server/api";
url.AppendPathSegment("item #123.txt");
Console.WriteLine(url.ToString());

戻り値：http://server/api/item%20#123.txt

これは、http リクエスト (を使用Flurl.Http) が、存在しないリソースのダウンロードのみを試みることを意味しますhttp://server/api/item%20。

セグメントをプリエスケープしても、結果はまったく同じになります。

url.AppendPathSegment("item %23123.txt");
Console.WriteLine(url.ToString());

再び戻ります: http://server/api/item%20#123.txt.

この「魔法」を止める方法はありますか？

[1] これは、入力がFlurl.Url変更する必要のある既存のインスタンスであるデリゲート/インターフェイスがあることを意味します。

4

2 に答える 2

3

バグを発見したようです。Flurlが従う文書化されたエンコーディング ルールは次のとおりです。

  • クエリ文字列の値は完全に URL エンコードされています。
  • パス セグメントの場合、/ や % などの予約文字はエンコードされません。
  • パス セグメントでは、スペースなどの不正な文字がエンコードされます。
  • パス セグメントの場合、? クエリ文字列は特別な扱いを受けるため、文字はエンコードされます。

2番目のポイントによると#、パスでエンコードするべきではないため、処理方法AppendPathSegment("item #123.txt")は正しいです。ただし、#を%23自分自身にエンコードする場合、Flurl は確かにエンコードを解除すべきではありません。しかし、私はそれが起こっていることを確認しました。GitHub で問題を作成していただければ、解決いたします。

当面は、このケースをカバーする独自の拡張メソッドを作成できます。このようなものはうまくいくはずです（そして、事前にエンコードする必要さえありません#）：

public static Url AppendFileName(this Url url, string fileName) {
    url.Path += "/" + WebUtility.UrlEncode(fileName);
    return url;
}
于 2017-07-31T16:59:04.050 に答える