如何在路径段中包含数字（哈希）字符＃？
如何在路径段中包含数字（哈希）字符＃？
我需要下载一个文件（使用现有的Flurl-Http端点[1]），文件名中包含一个"#"，为了不与uri-fragment检测发生冲突，当然必须转义为%23。
但是Flurl总是转义剩余的部分，而不是这个字符，导致uri无法工作，因为路径的一半和所有查询参数都丢失了，因为它们被解析为uri-fragment：
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实例，我必须修改它。
在路径段中包含数字（哈希）字符#的方法是什么？这个问题的出现是因为建议使用WebUtility.UrlEncode时，它会将空格替换为+，而我不想要这样的替换。解决方法是使用Uri.EscapeDataString(foo)。
文章内容如下：
在处理URL路径时，有时候我们需要在路径段中包含特殊字符，例如数字（哈希）字符#。然而，在某些情况下，我们可能会遇到一些问题，导致我们无法将#字符直接包含在路径段中。下面将介绍一个解决方法。
在寻找解决方法时，我尝试了使用WebUtility.UrlEncode的建议。这个方法可以将特殊字符进行转义，以便在URL中使用。然而，我发现WebUtility.UrlEncode会将空格替换为+，而这并不是我想要的结果。
最终，我找到了一个解决方法，即使用Uri.EscapeDataString(foo)。这个方法可以将特殊字符进行转义，但不会将空格替换为+。通过使用这个方法，我成功地将数字（哈希）字符#包含在了路径段中。
下面是一个示例代码，展示了如何使用Uri.EscapeDataString来包含数字（哈希）字符#在路径段中：
string foo = "example#path"; string escapedPath = Uri.EscapeDataString(foo); string url = "https://www.example.com/" + escapedPath;
在上面的示例中，我们首先定义了一个包含数字（哈希）字符#的路径段foo。然后，我们使用Uri.EscapeDataString对路径段进行转义，将其赋值给escapedPath变量。最后，我们将转义后的路径段与基础URL拼接，形成完整的URL。
通过使用Uri.EscapeDataString方法，我们可以成功地在路径段中包含数字（哈希）字符#，而不会受到WebUtility.UrlEncode替换空格为+的问题的影响。这为我们处理URL路径中包含特殊字符的需求提供了一个有效的解决方法。
问题出现的原因是Flurl在处理路径段时，对于保留字符如/和%，不进行编码，对于非法字符如空格进行编码，而对于问号?字符进行了编码，因为查询字符串有特殊处理。根据第二点，它不应该对路径中的#进行编码，所以处理"item #123.txt"这样的路径是正确的。然而，当你手动将#编码为%23时，Flurl肯定不应该对其进行解码，但我确认它正在发生。我邀请你在GitHub上创建一个问题，这个问题将会得到解决。
同时，你可以编写自己的扩展方法来处理这种情况。下面这样的方法应该可以工作（甚至不需要预先编码#）：
public static Url AppendFileName(this Url url, string fileName) {
url.Path += "/" + WebUtility.UrlEncode(fileName);
return url;
}
从项目维护者那里得到反馈真是太好了 🙂 我在Url.EncodeIllegalCharacters方法中发现了一段代码，它首先调用Uri.UnescapeDataString，然后使用Uri.EscapeUriString对结果进行编码。但根据stackoverflow.com/a/34189188/442376的回答，从来没有一个合理的理由使用EscapeUriString。
我再次鼓励你在GitHub上记录这个问题，以便我记得去看一下。我肯定在那个方法中有两个调用的原因，但我一时想不起来了。无论如何，你已经证明它是不正确的，需要修复。