目录：
增强代码
整理
安全性
小结
关于作者

增强代码

代码中首先要处理的是大小写形式。HTTP 认为以下所有 URL 都相同，因为 URL 不区分大小写。

<img src=http://www.163design.net/n/a/".mfr?assem=ImageServer&image=winxp.gif" />
<img src=http://www.163design.net/n/a/".mfr?assem=ImageServer&image=winxp.gif" />
<img src=http://www.163design.net/n/a/".mfr?assem=ImageServer&image=winxp.gif" />



我们的代码目前有一个问题，由于它不保留原 HTTP 请求不区分大小写的特征，因此必须向 LoadAndReturnImage 函数再添加一些代码。

不区分大小写

我们要做的是从程序集加载图像而不考虑大小写，但由于 Assembly.GetManifestResourceStream 是区分大小写的，因此还得另想办法。Assembly.GetManifestResourceNames() 函数将返回给定程序集内的所有资源列表，因此我们要做的就是调用此列表，与这些资源名称进行不区分大小写的比较，然后使用查找出的名称：

Assembly resourceAssem = Assembly.Load ( assembly ) ;

// 查找缓存的名称
string[] names = HttpContext.Current.Application [ assembly ] as string[] ;

if ( null == names )
{
// 获取程序集内所有资源的名称
names = resourceAssem.GetManifestResourceNames() ;
Array.Sort ( names , CaseInsensitiveComparer.Default ) ;
HttpContext.Current.Application [ assembly ] = names ;
}

// 如果此程序集内存在一些资源，
// 检查所需的资源
if ( names.Length > 0 )
{
// 在名称数组中查找图像
int pos = Array.BinarySearch ( names , image ,
CaseInsensitiveComparer.Default ) ;

if ( pos > -1 )
WriteImage ( resourceAssem , names[pos] , true ) ;
}



这里我加载了包含资源的程序集，然后查找应用程序缓存以查看该程序集内的资源列表是否已被加载和缓存。如果没有，我通过调用 Assembly.GetManifestResourceNames() 来读取资源列表，然后对列表进行排序，并将其存储在应用程序状态中。

然后，我就可以使用 Array.BinarySearch() 方法对名称列表执行二进制搜索。这比按顺序搜索字符串列表要快得多，且在应用程序状态存储资源列表所需的系统开销也较小。

这样就解决了区分大小写的问题，但性能如何呢？目前，每次当图像请求到达时，我们都要调用全部代码 - 除了最小的 Web 站点之外，其余所有的请求都可能会造成严重的性能问题。下一节我们将处理这个问题。

缓存

像普通的图像和一些 ASPX 页面一样，把从程序集返回的图像进行缓存是很有用的 - 因为这些图像驻留在程序集中，一般不会频繁地更改。

如果我们在编写一个简单的 ASPX 页面，则可以添加 OutputCache 指令以缓存页面。但在我们的方案中，我们需要一种方法能够通过编程方式将缓存控件标题添加到响应流中。幸运的是，在 ASP.NET 中这很容易完成。在把图像写入输出流的函数中，只需添加以下几行：

response.Cache.SetExpires ( DateTime.Now.AddMinutes ( 60 ) ) ;
response.Cache.SetCacheability ( HttpCacheability.Public ) ;
response.Cache.VaryByParams["assem"] = true ;
response.Cache.VaryByParams["image"] = true ;
// 将图像写入响应流...



此设置使图像在一小时（这个时间显然可以延长以减少服务器负载）后过期，并定义图像可以在任意位置（客户端、代理服务器、服务器等）进行缓存。它还定义了更改缓存行为的参数。现在，代码几乎已经完成了，但我们需要决定如何处理异常情况。

关于异常的编程

我们的代码中可能会引发很多异常。现在，用户的浏览器可能会断开链接，甚至可能仍然会遇到 ASP.NET 错误页面。我们可以推测出很多种可能发生的情况。如下所示：

·程序集可能不存在。
·程序集存在但不包含任何图像。
·程序集可能不包含所请求的图像。

代码也可能会造成其他错误。当找不到图像时，浏览器默认的响应是返回一个带有红十字的图像以表示一个断开的链接。

您当然希望用自己的默认图像来代替此图像。我已将一个默认的断开链接图像包含在 ImageServer 程序集中，当发生异常时，该图像将返回到浏览器。此行为可以通过在 web.config 文件的 AppConfig 部分添加一个设置来实现。

当发生错误时，如果要覆盖默认行为（返回链上的异常），请将以下内容添加到 web.config 中。

<appSettings>
<add key="MFRShowBrokenLink" value="true" />
</appSettings>



现在，当代码中出现异常时，将向浏览器返回断开链接图像，并在跟踪日志中写入警告。




图4：链接断开时返回的图像


如果查看跟踪日志，您会看到有关图像不存在的项，该项与下面类似。




图5：无效图像请求的示例跟踪日志输出


本文讨论的所有代码都可以通过本页顶部的 MFRImages.exe 下载链接获得。此下载包括本节完成的所有增强工作。还包括一些测试页，通过这些测试页可以查看使用处理程序和 ASPX 方法来呈现图像的结果。

整理

下面要添加一种方法，以返回驻留在程序集内的图像的正确 URL，然后自定义控件编写人员（或是您）可以调用此方法来返回图像。

如果已选择了处理程序方法来提供图像，则您所需的函数如下。

public static string ConstructImageURL ( Assembly assembly, string image )
{
return string.Concat ( ".mfr?assem=" ,
HttpUtility.UrlEncode ( assembly.FullName.ToString ( ) ) ,
"&image=" ,
HttpUtility.UrlEncode ( image ) ) ;
}



对于这段代码，我使用的是 string.Concat()，因为它比 string.Format() 大约快 4 倍。每个小技巧都会有所帮助！ 然后可以用它来设置您在自定义控件中创建的所有图像的 ImageURL 属性。

安全性

到目前为止的讨论中，我们一直基于程序集名称和资源名称提供图像。这没什么不好，但这意味着任何人都可以得到磁盘上的程序集名称，并可以尝试通过将其他程序集名称传递给处理程序来进行攻击。

为了避免这个潜在的问题，最好用