ImageSharp.Web自定义URL模式映射除URL重写外的标准实现方法咨询

你当前的场景是要将路径参数式的图片处理URL：

https://{myDomain}/process_resize_{width}x{height}/{folder}/{filename.extension}
映射到ImageSharp.Web原生支持的查询参数式处理逻辑，除了URL重写外，最标准的方案是自定义实现ImageSharp.Web的IImageRequestParser接口，该接口是官方提供的请求解析扩展点，不需要依赖额外的重写组件。

• 第一步：实现自定义请求解析器

using ImageSharp.Web;
using ImageSharp.Web.Commands;
using System.Text.RegularExpressions;

public class CustomImageRequestParser : IImageRequestParser
{
    // 匹配路径中的resize参数段
    private static readonly Regex ResizePattern = new Regex(@"^process_resize_(\d+)x(\d+)$", RegexOptions.Compiled);
    
    public ImageRequest ParseRequest(HttpContext context, string commandPrefix)
    {
        var pathSegments = context.Request.Path.Value.Trim('/').Split('/');
        // 路径段数量不足时走默认处理逻辑
        if (pathSegments.Length < 3)
        {
            return new ImageRequest(context.Request.Path, new CommandCollection());
        }

        var resizeSegment = pathSegments[0];
        var match = ResizePattern.Match(resizeSegment);
        if (!match.Success)
        {
            return new ImageRequest(context.Request.Path, new CommandCollection());
        }

        // 提取宽高参数
        var width = match.Groups[1].Value;
        var height = match.Groups[2].Value;
        
        // 拼接得到实际的图片资源路径
        var imagePath = string.Join("/", pathSegments.Skip(1));
        
        // 构造ImageSharp可识别的处理指令集合
        var commands = new CommandCollection
        {
            { "width", width },
            { "height", height },
            // 可按需添加默认参数，比如图片质量、缩放模式
            { "quality", "80" },
            { "rmode", "max" }
        };

        return new ImageRequest(new PathString($"/{imagePath}"), commands);
    }
}

• 第二步：替换默认的请求解析器
  在服务注册逻辑中，将自定义解析器注册到ImageSharp的配置管道中，示例代码（.NET 6+ 顶层语句）：

builder.Services.AddImageSharp()
    // 替换默认请求解析器
    .SetRequestParser<CustomImageRequestParser>()
    // 其余原有配置保持不变，比如文件提供者、处理器、缓存配置等
    .AddProvider<PhysicalFileSystemProvider>()
    .AddProcessor<ResizeProcessor>();

• 跨环境兼容：不需要依赖Web服务器的重写模块，IIS、Nginx、Kestrel环境下都可以正常运行，不需要单独配置重写规则
• 性能损耗更低：没有URL重写带来的额外请求跳转、路径匹配开销，解析逻辑直接嵌入ImageSharp的处理管道
• 可扩展性强：后续如果需要新增裁剪、旋转、水印等其他图片处理能力，只需要扩展路径匹配规则和解析逻辑即可，不需要修改上层URL规则

• 正则匹配需要做好参数合法性校验，非法的宽高参数可以直接返回400响应，或者跳过自定义逻辑走默认处理流程
• 注意自定义路径规则和现有业务路由的优先级，避免和站点其他路由产生冲突

内容的提问来源于stack exchange，提问作者Amila Fernando