.NET Framework 4.8中URI类在不同应用中的异常表现问询

这种差异是由**.NET Framework中Uri类的解析逻辑受运行环境和URI内容的双重影响**导致的，具体原因如下：

1. 非ASCII字符触发解析逻辑切换 #

当URI路径中包含非ASCII字符（如案例中的土耳其语字母Ç）时，.NET Framework的Uri类会切换到特殊解析分支：为处理非ASCII字符的编码转换（转为UTF-8格式的百分号编码），框架会对路径执行一次「解码-重新编码」流程。在此流程中，部分URI保留字符（如!对应的%21）会被自动解码——框架认为这类字符在包含非ASCII内容的路径中属于可显示的普通字符。

而当路径为纯ASCII（比如将Ç替换为英文C）时，Uri类会使用严格的URI解析规则，保留%21这类保留字符的编码状态，不会进行解码。

2. 宿主环境默认配置差异 #

控制台应用和IIS（ASP.NET）环境下，Uri类的默认解析行为存在差异：

• 控制台应用：默认使用严格的URI解析模式，即使存在非ASCII字符，也会保留%21这类保留字符的编码，不会主动解码。
• IIS/ASP.NET环境：受ASP.NET请求管道预处理逻辑或Web环境下Uri类的宽松默认配置影响，当遇到包含非ASCII字符的URI时，会触发保留字符的解码操作，因此%21会被转换为!。

统一行为的可选方案 #

如果需要在两种环境下获得一致输出，可以通过显式配置实现：

• 若要保留所有编码（对齐控制台行为），可使用UriBuilder或指定解析选项：

var uriBuilder = new UriBuilder("https://myhost.net/Publications/te%21st%C3%87.pdf");
var test = uriBuilder.Uri;

// 或使用指定UriKind的构造函数重载
var test = new Uri("https://myhost.net/Publications/te%21st%C3%87.pdf", UriKind.Absolute);

• 若要强制解码保留字符（对齐IIS行为），可手动解码路径后再构造Uri：

var rawPath = "/Publications/te%21st%C3%87.pdf";
var decodedPath = Uri.UnescapeDataString(rawPath);
var test = new Uri($"https://myhost.net{decodedPath}");

内容的提问来源于stack exchange，提问作者Denis Kaminsky