aspnet访问慢

① 请问一个asp,net的问题

我想通过例子你很快就会明白了:

<?xml version="1.0"?>
<!--
注意: 除了手动编辑此文件以外，您还可以使用
Web 管理工具来配置应用程序的设置。可以使用 Visual Studio 中的
“网站”->“Asp.Net 配置”选项。
设置和注释的完整列表在
machine.config.comments 中，该文件通常位于
\Windows\Microsoft.Net\Framework\v2.x\Config 中
-->
<configuration xmlns="http://schemas.microsoft.com/.NetConfiguration/v2.0">
<connectionStrings>
<add name="NorthwindConnectionString" connectionString="Data Source=8G4K5AU68FMJYV2\sqlEXPRESS;Initial Catalog=Northwind;Persist Security Info=True;User ID=sa;Password=123456"
providerName="System.Data.SqlClient" />
</connectionStrings>
<system.web>
<anonymousIdentification enabled="true"/>

</system.web>
</configuration>

这个配置文件的内容很少,但是包括非常重要的一节:configuration ->connectionStrings>.请注意,Web.Config文件是以XML 格式存储的,因此里边的信息采用"树型结构",就那上面来看,<connectionStrings />存储于<configuration />结,因此<connectionStrings />就是<configuration />所要表述的成员之一,也就是说每一个结点都存储应用程序的一些信息,而它们都是用过XML 属性结构归类的.我们要实现ASP.NET的应用程序的灵活性,很大程度上依赖了这些配置文件.举一个简单的例子:当我们在.ASPX文件中连接数据源时,需要先定义连接字符串,但是一套完整的应用程序包括很多数据源,也包括很多连接数据源的代码,因此你必须考虑把这些连接字符串统一的管理,统一的调用,就像定义了一个"全局变量",随时随地,任何时间任何地点(程序集)都可以调用出来,当我们需要更改连接字符的时候,也只需要在"全局变量"中修改即可.呵呵,有没有发现这个ASP.NET中最令人兴奋的技术呢?那么你就试试吧,下面是间单的例子:

class OleDb
{
public static void ConnectionDleDb()
{

using (OleDbConnection conn = new OleDbConnection(GetConnSring()))
{
OleDbCommand command = conn.CreateCommand();
command.CommandText = GetCommandString();
try
{
conn.Open();
OleDbDataReader reader = command.ExecuteReader();
while (reader.Read())
{
Console.Write("/t{0}/t{1}",reader[0],reader[1]);
Console.WriteLine("/n");
}
}
catch (Exception e)
{
Console.WriteLine(e.Message);
throw;
}
}
}
private static string GetConnSring()
{
ConnectionStringSettings settings =
ConfigurationManager.ConnectionStrings["NorthwindConnectionString"];
return (settings.ConnectionString);
}
private static string GetCommandString()
{
return (@"SELECT CategoryID, CategoryName FROM dbo.Categories;");
}
}

在这里,我们正好用到了Web.Config配置文件中的NorthwindConnectionString项,它存储了我们定义的一个连接字符串,在类OleDb中,方法GetConnSring使用ConfigurationManager类将Web.Config配置文件中的值取出,ConfigurationManager类则是.NET公开所的,提供给程序员的Web.Config文件操作类,在.NET类库中包含了很多实现类似功能的类,比如"成员资格提供程序","角色提供程序",它们与Web.Config配置文件配合组成了非常高效的应用程序管理机制.

以下是MSDN的相关文章:

---------------------------------------------------
使用 ASP.NET 配置系统的功能，可以配置整个服务器上的所有 ASP.NET 应用程序、单个 ASP.NET 应用程序、各个页面或应用程序子目录。可以配置各种功能，如身份验证模式、页缓存、编译器选项、自定义错误、调试和跟踪选项等等。

以下各节描述了 ASP.NET 配置系统的功能。

有关配置 .NET Framework 客户端应用程序的信息，请参见配置应用程序。

注意
ASP.NET 配置系统的功能仅适用于 ASP.NET 资源。例如，Forms 身份验证仅限制对 ASP.NET 文件的访问，而不限制对静态文件或 ASP（传统型）文件的访问，除非这些资源映射到 ASP.NET 文件扩展名。要配置非 ASP.NET 资源，应使用 Internet 信息服务 (IIS) 的配置功能。有关信息，请参见 Working with the IIS Metabase（使用 IIS 元数据库）和 IIS Metabase Property Reference（IIS 元数据库属性参考）。

配置文件
ASP.NET 配置数据存储在全部命名为 Web.config 的 XML 文本文件中，Web.config 文件可以出现在 ASP.NET 应用程序的多个目录中。使用这些文件，可以在将应用程序部署到服务器上之前、期间或之后方便地编辑配置数据。可以通过使用标准的文本编辑器、ASP.NET MMC 管理单元、网站管理工具或 ASP.NET 配置 API 来创建和编辑 ASP.NET 配置文件。

ASP.NET 配置文件将应用程序配置设置与应用程序代码分开。通过将配置数据与代码分开，可以方便地将设置与应用程序关联，在部署应用程序之后根据需要更改设置，以及扩展配置架构。

有关如何对 ASP.NET 配置文件中的数据进行组织的更多信息，请参见 ASP.NET 配置文件。ASP.NET 配置设置 中描述了可用的配置设置。

配置文件层次结构和继承
每个 Web.config 文件都将配置设置应用于它所在的目录以及它下面的所有子目录。可以选择用子目录中的设置重写或修改父目录中指定的设置。通过在 location 元素中指定一个路径，可以选择将 Web.config 文件中的配置设置应用于个别文件或子目录。

ASP.NET 配置层次结构的根为 systemroot\Microsoft.NET\Framework\versionNumber\CONFIG\Web.config 文件，该文件包括应用于所有运行某一具体版本的 .NET Framework 的 ASP.NET 应用程序的设置。由于每个 ASP.NET 应用程序都从根 Web.config 文件那里继承默认配置设置，因此只需为重写默认设置的设置创建 Web.config 文件。

注意
根 Web.config 文件从 Machine.config 文件那里继承一些基本配置设置，这两个文件位于同一个目录中。其中的某些设置不能在 Web.config 文件中被重写。有关更多信息，请参见 ASP.NET 配置文件层次结构和继承。

运行时，ASP.NET 使用 Web.config 文件按层次结构为传入的每个 URL 请求计算唯一的配置设置集合。这些设置只计算一次，随后将缓存在服务器上。ASP.NET 检测对配置文件进行的任何更改，然后自动将这些更改应用于受影响的应用程序，而且大多数情况下会重新启动应用程序。只要更改层次结构中的配置文件，就会自动计算并再次缓存分层配置设置。除非 processModel 节已更改，否则 IIS 服务器不必重新启动，所做的更改即会生效。

有关 ASP.NET 配置层次结构的工作原理的更多信息，请参见 ASP.NET 配置文件层次结构和继承和 ASP.NET 配置方案。

直接编辑配置文件
可以使用文本编辑器或 XML 编辑器来直接编辑配置文件。有关正确的语法，请参见 ASP.NET 配置设置和 常规配置设置 (ASP.NET) 中有关配置节的参考主题。有关更多信息，请参见编辑 ASP.NET 配置文件。

配置工具
使用 ASP.NET 配置系统所提供的工具来配置应用程序比使用文本编辑器简单，因为这些工具包括错误检测功能。

ASP.NET MMC 管理单元
用于 ASP.NET 的 Microsoft 管理控制台 (MMC) 管理单元提供一种在本地或远程 Web 服务器上的所有级别操作 ASP.NET 配置设置的方便途径。ASP.NET MMC 管理单元使用 ASP.NET 配置 API，但是它通过提供一个图形用户界面 (GUI) 来简化配置设置的编辑过程。另外，该工具还支持多个 ASP.NET 配置 API 功能，这些功能控制 Web 应用程序是否可以继承设置，并管理配置层次结构各级别之间的依赖性。

注意
若要使用 ASP.NET MMC 管理单元，必须使用具有管理权限的帐户登录到计算机。

ASP.NET MMC 管理单元在虚拟目录的属性页上显示为“ASP.NET”选项卡。

有关更多信息，请参见 ASP.NET MMC 管理单元。

网站管理工具
对网站具有管理权限的任何人都可以使用网站管理工具来管理该网站的配置设置。网站管理工具旨在为各个网站中最常用的配置设置提供一个用户友好的图形编辑工具。由于网站管理工具使用基于浏览器的界面，因此它允许您远程更改网站设置，这对于管理已经部署到成品 Web 服务器的站点（如承载的网站）非常有用。

网站管理工具与 ASP.NET MMC 管理单元在若干方面存在不同。例如，ASP.NET MMC 管理单元最适于管理员级别的配置，因为它提供对 Web 服务器上的整个配置文件层次结构的访问，而不是提供对单个网站的配置设置的访问。此外，您还必须是管理员才能使用 ASP.NET MMC 管理单元，而网站管理工具只允许各个网站所有者在他们具有管理权限的站点的根目录中配置 Web.config 文件。最后，您不能使用 ASP.NET MMC 管理单元来远程管理 IIS，但是，网站管理工具的浏览器界面允许远程配置 IIS 6.0 和更高版本的 IIS。

网站管理工具包括一个选项卡式界面，该界面在下列选项卡上对相关的配置设置进行分组：

“安全”选项卡，其中包含有助于保护 Web 应用程序资源并管理用户帐户和角色的设置。

“配置文件”选项卡，其中包含用来管理网站如何收集访问者信息的设置。

“应用程序”选项卡，其中包含用来管理影响 ASP.NET 应用程序的配置元素的设置。

“提供程序”选项卡，其中包含用来添加、编辑、删除、测试或分配应用程序提供程序的设置。

网站管理工具是随 .NET Framework 2.0 版自动安装的。有关该工具如何工作的信息，请参见 ASP.NET 网站管理工具。

命令行工具
.NET Framework 包括几个执行特定配置操作的命令行工具。例如，使用 Aspnet_regiis.exe 工具，可以指定将哪个版本的 .NET Framework 应用于 ASP.NET 应用程序。有关更多信息，请参见 .NET Framework 工具。

ASP.NET 配置 API
ASP.NET 配置系统提供一个完整的托管接口，使用该接口，可以通过编程方式配置 ASP.NET 应用程序，而不必直接编辑 XML 配置文件。另外，ASP.NET 配置 API 还执行下列任务：

通过为配置层次结构中所有级别的数据提供一个集成视图来简化管理任务。

支持部署任务，包括创建配置和用一个脚本配置多台计算机。

为构建 ASP.NET 应用程序、控制台应用程序和脚本、基于 Web 的管理工具和 MMC 管理单元的开发人员提供单一的编程接口。

防止开发人员和管理员进行无效的配置设置。

允许您扩展配置架构。您可以定义新配置参数并编写配置节处理程序以对它们进行处理。

提供从当前正在运行的应用程序获取配置信息的静态方法，以及从单独的应用程序获取配置信息的非静态方法。使用静态方法可以提高应用程序的运行速度，但是这些方法只能从您要获取其配置数据的应用程序内部使用。

有关更多信息，请参见 ASP.NET 配置 API。

配置安全性
ASP.NET 配置系统有助于防止未经授权的用户访问配置文件。ASP.NET 将 IIS 配置为拒绝任何浏览器访问 Machine.config 或 Web.config 文件。对于试图直接请求配置文件的任何浏览器，都返回 HTTP 访问错误 403（禁止）。

另外，将禁止一个 ASP.NET 应用程序中的配置文件访问其他 ASP.NET 应用程序中的配置设置，除非您的配置应用程序在完全信任模式下以对其他应用程序中的配置文件具有读取权限的帐户运行。

有关更多信息，请参见保证 ASP.NET 配置的安全和使用受保护的配置加密配置信息。

② c#如何使用缓存提高程序效率

缓存的技术应用应该是非广泛的。而它的作用也是为了提高系统或者网站的执行效率。下面是四种常见的缓存技术：
一.OutputCaching
由于IIS的一些特性，默认情况下OutputCache是打开的，但是要对某些请求进行缓存，还需要开发者进行定制，而且默认情况下，Output Cache 会被缓存到硬盘上，我们可以通过修改DiskCacheable的属性来设置其是否缓存，还可以通过Web config里配置缓存文件的大小。

<%@ OutputCacheDuration="3600" VaryByParam="state" DiskCacheable="true" %>
一般用硬盘缓存是考虑到页面送显的数据比较大，相对内存缓存来说，它的容量大，但是访问速度慢点，如果把周期设太短，使用硬盘缓存的效率就不大好。对于Output Cache的定制，有两种方法，一种是基于底层的API技术，一种是基于高层的@OutputCaching：

1.基于高层的@OutputCaching

A.由参数改变缓存内容：有些时候我们需要根据用户的请求来生成页面，但是用户的请求只有有限的几种组合，这个时候就可以根据用户请求来生成几种缓存页面，来进行缓存。

<%@ OutputCache Duration ="60" VaryByParam = "state" %>
<asp:SqlDataSourceID="SqlDataSource1" runat="server">
<SelectParameters>
<asp:QueryStringParameter Name="state"QueryStringField="state" DefaultValue="CA" />
</SelectParameters>
</asp:SqlDataSource>
B.回调缓存：可以针对每个请求在页面中插入动态的部分，以弥补单独使用静态缓存的不足：
动态的部分用Substitution控件，Substitution控件是一个容器

<asp:SubstitutionID="Substitution1" runat="server" MethodName =""/>
MethodName 里面放入要调用的方法内容。
2. 使用API定制缓存：
通过设置System.Web.HttpCachePolicy属性来进行配置

<%@ OutputCache Duration="60"VaryByParam="none" %>
就可以写成

Response.Cache.SetExpires(DateTime.Now.AddSeconds(60));
Response.Cache.SetCacheability(HttpCacheability.Public);

二.FragmentCaching
作为Output的缓存的附加功能，还提供一种缓存技术，专门用于缓存用户控件。在用户控件中设置：

<%@ OutputCache Duration="60"VaryByParam="none" %>

但在引用用户控件的页面不设置缓存。这样的话，页面中除了用户控件是静态的，其他都是动态的。
缓存用户空间同样还可以使用控件作为参数来源。通过指定控件作为缓存控件的数据来源，可以达到缓存控件数据的目的，和上面一样。

三.DataCaching
Asp.net提供了一种非常快捷的方法进行数据库缓存，用户可以非常简单方便的对页面变量进行缓存。并以此提高程序效率。一个页面变量的缓存生命周期与应用程序的缓存生命周期相同
实现是把数据放在Cache中，如：

source = new DataView(ds);
Cache("MyCache") = source;

MyCache这个变量其实就是一个XML文件。

四.SQL Caching
通过配置数据库连接池，只有当数据库数据被改变的时候，缓存才会改变。
开个DOS窗口：
C:\>dir aspnet_regsql.exe/s ——这个文件是专门注册SQL连接池的，它对SQLSever 7.0以上都有专门的支持，我们通过写一些专门的语句来配置这个注册连接池，可以把连接池和本地的应用程序（Asp.net服务器，即IIS）做一个连接。连接池只能监视有限的几个库，不然连接池的负载太大。使用SQL Caching：
先注册，如： aspnet_regsql.exe-S".\SQLExpress"-E-d"pubs"-ed
aspnet_regsql.exe-S".\SQLExpress"-E-d"pubs"-et-t"authors"
其中：- S".\SQLExpress" 表示要使用的SQL Server实例为".\SQLExpress"。-E 表示使用当前windows凭证进行身份验证。-d"pubs"表示用于应用程序服务的数据库名称叫"pubs"。-ed表示为SQL 缓存依赖项启用数据库。-et 表示为SQL 缓存依赖项启用表。-t"authors"表的名称为"authors"。
然后页面上：
<%@ OutputCacheDuration="99999999" VaryByParam="none"SqlDependency="Pubs.Authors" %>
就OK了。

③ 如何在服务器上部署asp.net网站

对于许多新手来说，如何在服务器上部署网站并不了解，这个教程希望对新手有帮助。

1、IIS服务器

2、.Net Framework3.5 (方便起见，我们这里Framework说的都是指的这个版本)

这两个软件都需要我们自己手动操作安装到服务器里面。那到底是先装哪一个呢，为了方便起见，一般我们都先安装IIS服务器，然后再安装Framework。

当然偶也遇到过几次部署人员先安装了Framework再安装IIS服务器的，这样的操作步骤就会导致Framework不会被注册进IIS服务器里面。就是说在网站属性的ASP.NET选项卡上面不会出现下面这样的版本选择框

然后一直下一步就可以完成IIS的安装了。

安装Framework没有什么好说的，双击安装文件一直下一步就可以了。

等两个软件都安装完成后，就可以通过

右击我的电脑-->管理 打开计算机管理窗口

可以看到里面有一项应用程序服务器的选项，不错，就是刚才安装的那个东西。

点开它，会看到一个 Internet 信息服务(IIS)管理器，就是要在这个东西里面操作，其他的不用去管。

打开，会发现有三个子菜单：

1、应用程序池

2、网站

3、Web服务扩展

什么是应用程序池？太专业了，不去管他，为了保险起见，偶每建立一个网站都要创建一个应用程序池来管理，至于这个池的配置，一切默认啦，微软都已经帮做好了。

来创建一个应用程序池：

右键应用程序池-->

然后展开这个应用程序池的菜单，就可以看到刚才新建的Test的应用程序池了。

接下来左键单击 Web服务扩展 菜单打开.net2.0的扩展

接下来就可以新建一个网站了，右键 网站

直接单击下一步

输入网站的名字 Test ，下一步

选择端口，如果需要绑定IP和主机头，需要在这里绑定，没有需要，就不做了（打个比方，网站的访问路径是http://192.168.1.150:2000，这里的2000就是需要的端口号）

接下来要选定网站的物理路径，就是这个网站的文件到底放在了电脑的那个地方，C盘？D盘？还是哪，反正就是网站所在的文件夹的路径

选定文件夹后再点击下一步

接下来要配合网站的访问权限，由于网站需要些文件操作的功能，所以一般都把写入权限加上

单击下一步后，网站就算是创建成功了.

④ 用DRMER WEAVER做的网页,已做完,也有上传工具,请问到底如何上传到INTRNET上,这里面前奏和具体步骤怎么做

网站上传方法汇总，制作好网页后，如何把网页上传到申请的空间呢？为初学者做一个汇总。

上传的定义

上传就是将信息从个人计算机（本地计算机）传递到中央计算机（远程计算机）系统上，让网络上的人都能看到。将制作好的网页、文字、图片等发布到互联网上去，以便让其他人浏览、欣赏。这一过程称为上传。

上传的来源

上传一词来自英文（upload），拆开来“up”为“上”，“load”为“载”，故上传也叫上载，与下载（download）是逆过程。 网页教学网

上传的分类 Webjx.Com

上传分为Web上传和Ftp上传，前者直接通过点击网页上的链接即可操作，后者需要专用的FTP工具。

上传小知识
网页教学网

在上传主页之前，让我们先来认识Internet上一个基本的概念———FTP。它是英文“File Transfer Protocol”(文件传输协议)的缩写，不过我们今天已经把它看成了一个动词，意思是说在计算机和计算机之间传输文件。把自己制作好的主页上传到服务器上，就要用到FTP。

有许多种方法可以把主页文件上传到Internet服务器上，下面是常见的五种方法。

1、使用FTP软件上传主页文件

这是最常用、最方便也是功能最为强大的主页上传方法。现在网上这类软件很多，像CuteFtp、WS-Ftp已经广受网友欢迎。这类软件除了可以完成文件传输的功能以外，还可以通过它们完成站点管理、远程编辑服务器文件等工作，一些常用的FTP软件还有断点续传、任务管理、状态监控等功能，可以让你的上传工作变得非常轻松。

2、使用“兼职”的FTP软件上传主页文件

所谓兼职的 FTP软件，是指软件本身并不是专门用来完成FTP功能的，主页上传只是其编外任务。例如我们常用的FrontPage、Dreamweaver、东方主页王Ⅱ等都有主页上传、发布的功能。使用这类软件的好处是可以在编辑主页的同时就上传到服务器上查看主页效果，省去了启动软件、登录、设置等诸多麻烦。但是，这种方法往往上传速度较慢，且难以对服务器上的文件进行管理。

3、使用Web页面上传主页文件

和前面两种方法相比，这种方法不但没有什么明显的优点，而且速度缓慢、操作麻烦、不支持断点续传。但是，如果你恰恰申请了一个这样的不支持FTP的免费主页空间，那么就只能使用这种笨拙的方法了！

4、通过命令上传主页文件

在很久很久以前，Unix系统上的FTP程序是基于命令行的，现在的Window95／98／NT／2000／Me仍然有基于命令行的FTP程序(进入 DOS模式，输入FTP就可以了)。使用这种方法首先要掌握几十条命令不说，而且屏幕上通常只能显示25或50行文字，很不方便。图形界面的FTP软件流行之后，这种方法已经被大多数网友抛弃了，只供少数骨灰级的网虫练习他们的指法。

5、通过E-mail上传

这种方法要求你把主页文件通过E-mail发给系统管理员，然后再由系统管理员把它们放到服务器上。这是最简单也是最复杂的方法，随着网络条件的提高，这种方法已逐渐销声匿迹了。

大文件上传
Webjx.Com

以前也做过文件上传，但都是些小文件，不超过2M。 这次要求上传100M以上的东西。没办法找来资料研究了一下。基于WEB的文件上传可以使用FTP和HTTP两种协议，用FTP的话虽然传输稳定，但安全性是个严重的问题，而且FTP服务器读用户库获取权限，这样对于用户使用来说还是不太方便。剩下只有HTTP。在HTTP中有3种方式，PUT、WEBDAV、RFC1867，前2种方法不适合大文件上传，目前我们使用的web上传都是基于 RFC1867标准的HTML中基于表单的文件上传。

一、先简要介绍一下RFC1867（Form-based File Upload in HTML）标准：

1．带有文件提交功能的HTML表单

现有的HTML规范为INPUT元素的TYPE属性定义了八种可能的值，分别是：CHECKBOX， HIDDEN，MAGE，PASSWORD，RADIO，RESET，SUBMIT，TEXT。另外，当表单采用POST方式的时候，表单默认的具有“application/x-www-form-urlencoded”的ENCTYPE属性。

RFC1867标准对HTML做出了两处修改：

（1）为INPUT元素的TYPE属性增加了一个FILE选项。

（2）INPUT标记可以具有ACCEPT属性，该属性能够指定可被上传的文件类型或文件格式列表。

另外，本标准还定义了一种新的MIME类型：multipart/form-data，以及当处理一个带有ENCTYPE="multipart /form-data" 并且/或含有<INPUT type="file">的标记的表单时所应该采取的行为。

举例来说，当HTML表单作者想让用户能够上传一个或更多的文件时，他可以这么写：

<FORM ENCTYPE="multipart/form-data" ACTION="_URL_" METHOD=POST>

File to process:
<INPUT NAME="userfile1" TYPE="file">

<INPUT TYPE="submit" VALUE="Send File">

</FORM>

HTML DTD里所需要做出的改动是为InputType实体增加一个选项。此外，我们也建议用一系列用逗号分隔的文件类型来作为INPUT标记的ACCEPT属性。

... (其他元素) ...

<!ENTITY % InputType "(TEXT | PASSWORD | CHECKBOX |

RADIO | SUBMIT | RESET |

网页教学网

IMAGE | HIDDEN | FILE )">

<!ELEMENT INPUT - 0 EMPTY>

<!ATTLIST INPUT

TYPE %InputType TEXT

NAME CDATA #IMPLIED -- required for all but submit and reset

VALUE CDATA #IMPLIED

SRC %URI #IMPLIED -- for image inputs --

CHECKED (CHECKED) #IMPLIED

SIZE CDATA #IMPLIED --like NUMBERS,

but delimited with comma, not space

MAXLENGTH NUMBER #IMPLIED Webjx.Com

ALIGN (top|middle|bottom) #IMPLIED

ACCEPT CDATA #IMPLIED --list of content types

>

... (其他元素) ...

2.文件传输延迟

在某些情况下，在确实准备接受数据前，服务器先对表单数据中的某些元素（比如说用户名，账号等）进行验证是推荐的做法。但是，经过一定的考虑后，我们认为如果服务器想这样做的话，最好是采用一系列的表单，并将前面所验证过的数据元素作为“隐藏”字段传回给客户端，或者是通过安排表单使那些需要验证的元素先显示出来。这样的话，那些需要做复杂的应用的服务器可以自己维持事务处理的状态，而那些简单的应用的则可以实现得简单些。

HTTP协议可能需要知道整个事务处理中的内容总长度。即使没有明确要求，HTTP客户端也应该提供上传的所有文件的内容总长度，这样一个繁忙的服务器就能够判断文件的内容是否是过大以至于将不能完整地处理，从而返回一个错误代码并关闭该连接，而不用等到接受了所有的数据才进行判断。目前一些现有的 CGI应用对所有的POST事务都需要知道内容总长度。

如果INPUT标记含有一个MAXLENGTH属性，客户端可以将这个属性值看作是服务器端所能够接受的传送文件的最大字节数。在这种情况下，服务器能够在上传开始前，提示客户端在服务器上有多少空间可以用来进行文件上传。但是应该引起注意的是，这仅仅是一个提示，在表单被创建后和文件上传前，服务器的实际需求可能会发生改变。

在任何情况下，如果接受的文件过大的话，任何一个HTTP服务器都有可能在文件传输的过程中中断传输。

3.传输二进制数据的其他解决办法

有些人曾经建议使用一种新的MIME类型"aggregate"，比如说aggregate/mixed 或是content-transfer-encoding "包"来描述那些不确定长度的二进制数据，而不是靠分解为多个部分来表示。虽然我们并不反对这么做，但这需要增加额外的设计和标准化工作来让大家接受并理解"aggregate"。从另一方面来说，"分解为多部分"的机制工作得很好，能够非常简单的在客户发送端和服务器接受端加以实现，而且能像其他一些综合处理二进制数据的方式一样高效率地工作。

4.例子
Webjx.Com

假设服务器段提供的是如下的HTML：

<FORM ACTION="http://server.dom/cgi/handle"

ENCTYPE="multipart/form-data"

METHOD=POST>

What is your name? <INPUT TYPE=TEXT NAME=submitter>

What files are you sending? <INPUT TYPE=FILE NAME=pics>

</FORM>

用户在“姓名”字段里面填写"Joe Blow"，对问题'What files are you sending?'，用户选择

了一个文本文件"file1.txt"。

客户段可能发送回如下的数据：

Content-type: multipart/form-data, boundary=AaB03x

--AaB03x

content-disposition: form-data; name="field1" 网页教学网

Joe Blow

--AaB03x

content-disposition: form-data; name="pics"; filename="file1.txt"

Content-Type: text/plain

... file1.txt 的内容...

--AaB03x--

如果用户同时还选择了另一个图片文件"file2.gif"，那么客户端可能发送的数据将是：

Content-type: multipart/form-data, boundary=AaB03x

--AaB03x

content-disposition: form-data; name="field1"

Joe Blow

--AaB03x

content-disposition: form-data; name="pics"

Content-type: multipart/mixed, boundary=BbC04y

--BbC04y

Content-disposition: attachment; filename="file1.txt"

Content-Type: text/plain

... file1.txt 的内容...

--BbC04y

Content-disposition: attachment; filename="file2.gif"

Content-type: image/gif

Content-Transfer-Encoding: binary

... file2.gif的内容...

--BbC04y--

--AaB03x--

二、利用RFC1867标准处理文件上传的两种方式：

Webjx.Com

1．一次性得到上传的数据，然后分析处理。

看了N多代码之后发现，目前无组件程序和一些COM组件都是使用Request.BinaryRead方法。一次性得到上传的数据，然后分析处理。这就是为什么上传大文件很慢的原因了，IIS超时不说，就算几百M文件上去了，分析处理也得一阵子。

2．一边接收文件，一边写硬盘。

了解了一下国外的商业组件，比较流行的有Power- Web，AspUpload,ActiveFile,ABCUpload,aspSmartUpload,SA-FileUp。其中比较优秀的是 ASPUPLOAD和SA-FILE，他们号称可以处理2G的文件(SA-FILE EE版甚至没有文件大小的限制)，而且效率也是非常棒，难道编程语言的效率差这么多?查了一些资料,觉得他们都是直接操作文件流。这样就不受文件大小的制约。但老外的东西也不是绝对完美，ASPUPLOAD处理大文件后,内存占用情况惊人。1G左右都是稀松平常。至于SA-FILE虽然是好东西但是破解难寻。然后发现2款.NET上传组件，Lion.Web.UpLoadMole和AspnetUpload也是操作文件流。但是上传速度和CPU占用率都不如老外的商业组件。

做了个测试，LAN内传1G的文件。ASPUPLOAD上传速度平均是4.4M/s，CPU占用10-15，内存占用700M。SA-FILE也差不多这样。而AspnetUpload最快也只有1.5M/s，平均是700K/s，CPU占用15-39，测试环境: PIII800,256M内存,100M LAN。我想AspnetUpload速度慢是可能因为一边接收文件，一边写硬盘。资源占用低的代价就是降低传输速度。但也不得不佩服老外的程序，CPU 占用如此之低.....。

三、ASP.NET上传文件遇到的问题

我们在用ASP.NET上传大文件时都遇到过这样或那样的问题。设置很大的maxRequestLength值并不能完全解决问题，因为ASP.NET 会block直到把整个文件载入内存后，再加以处理。实际上，如果文件很大的话，我们经常会见到Internet Explorer显示 "The page cannot be displayed - Cannot find server or DNS Error"，好像是怎么也catch不了这个错误。为什么？因为这是个client side错误，server side端的Application_Error是处理不到的。

四、ASP.NET大文件上传解决方案

解决的方法是利用隐含的HttpWorkerRequest，用它的GetPreloadedEntityBody 和 ReadEntityBody方法从IIS为ASP.NET建立的pipe里分块读取数据。Chris Hynes为我们提供了这样的一个方案(用HttpMole)，该方案除了允许你上传大文件外，还能实时显示上传进度。

Lion.Web.UpLoadMole和AspnetUpload 两个.NET组件都是利用的这个方案。

方案原理：
Webjx.Com

利用HttpHandler实现了类似于ISAPI Extention的功能，处理请求(Request)的信息和发送响应(Response)。

方案要点：

1． httpHandler or HttpMole
a.在asp.net进程处理request请求之前截获request对象
b.分块读取和写入数据
c.实时跟踪上传进度更新meta信息

2． 利用隐含的HttpWorkerRequest用它的GetPreloadedEntityBody 和 ReadEntityBody方法处理文件流
IServiceProvider provider = (IServiceProvider) HttpContext.Current;
HttpWorkerRequest wr = (HttpWorkerRequest) provider.GetService(typeof(HttpWorkerRequest));
byte[] bs = wr.GetPreloadedEntityBody();
....
if (!wr.IsEntireEntityBodyIsPreloaded())
{
int n = 1024;
byte[] bs2 = new byte[n];
while (wr.ReadEntityBody(bs2,n) >0)
{ 网页教学网
.....
}
}

3． 自定义Multipart MIME 解析器。
自动截获MIME分割符。
将文件分块写如临时文件。
实时更新Appliaction 状态（ReceivingData, Error, Complete） 。