Python的强大永远会带给我们意外的惊喜。最近在使用websocket时遇到了文件对象的传输问题：对于前端页面传来的文件流、字符串需要转为文件对象再传输给api接口。那么首先想到的是将文件流或字符串存入文件再从直接读取以获取文件文件对象，这种方式固然可行，但是弊端是需要额外占用空间来存储文件，当然我们也可以每次调用结束后清理文件，如果没有临时文件模块这也是一种可行的方式。

强大如python，拥有临时文件模块-tempfile，这个模块可以产生临时文件或文件夹，并且支持所有的平台。

这个模块我们常用的方法如下：

tempfile.TemporaryFile([mode='w+b'[, bufsize=-1[, suffix=''[, prefix='tmp'[, dir=None]]]]])

这个方法会返回一个临时存储的文件对象， 这个文件对象将在使用close方法或垃圾回收后被销毁。在使用过程中不应该依赖于使用此函数创建的临时文件，该文件在文件系统中具有或不具有可见名称。这个方法创建的文件对象默认模式是“w+b”，bufsize默认为-1，表示使用操作系统默认值。

返回的对象在POSIX平台上的真实文件对象，在其他平台上，它是一个类文件对象，其file属性是底层的真实文件对象。这个类文件对象可以在with语句中使用，就像普通文件一样。

tempfile.NamedTemporaryFile([mode='w+b'[, bufsize=-1[, suffix=''[, prefix='tmp'[, dir=None[, delete=True]]]]]])

这个方法与TemporaryFile（）基本相同，区别是它可以保证文件在文件系统中具有可见名称。可以从返回的类文件对象的name属性中检索该名称。名称可以用于第二次打开文件， 如果delete为true（默认值），则文件一关闭就会被删除。

>>> f = NamedTemporaryFile(delete=False) 
>>> f <open file '<fdopen>', mode 'w+b' at 0x384698> 
>>> f.name '/var/folders/5q/5qTPn6xq2RaWqk+1Ytw3-U+++TI/-Tmp-/tmpG7V1Y0' 
>>> f.write("Hello World!\n") 
>>> f.close() # 关闭即删除文件 
>>> os.unlink(f.name) 
>>> os.path.exists(f.name) 
False

完整的文件流或字符串、字节串转文件对象的方法：

import tempfile

def string_to_file(string):
    file_like_obj = tempfile.NamedTemporaryFile()
    file_like_obj.write(string)
    # 确保string立即写入文件
    file_like_obj.flush()
    # 将文件读取指针返回到文件开头位置
    file_like_obj.seek(0)
    return file_like_object

对于临时文件夹的创建使用的是：tempfile.tempdir

>>> import tempfile
>>> tempfile.tempdir
# 返回临时文件夹路径
>>> tempfile.gettempdir()   # 对于不同平台临时文件夹创建的路径也不一样
'c:\\users\\hlshang\\appdata\\local\\temp'

对于更多方法及使用可以参考官方文档。

有趣有料有温度，和我一起学技术！

欢迎关注公众号 来思Go，收看更多赖克与甜甜的技术学习日常。

原文地址：http://www.cnblogs.com/5211314jackrose/p/5816013.html
一、7种临时文件
    SQLite中，一个数据库由单个磁盘文件构成，简化了SQLite的使用，因为移动或备份数据库只要拷贝单个文件即可。这也使得SQLite适合用作应用程序文件格式。但是，当在单个文件中存储一个数据库时，SQLite会在处理数据库的过程中使用许多临时文件。
    SQLite目前使用7种不同类型的临时文件：
    * 回滚日志（Rollback journals）
    * 主日志（Master journals）
    * SQL语句日志（Statement journals）
    * 临时数据库（TEMP databases）
    * 视图和子查询的持久化（Materializations of views and subqueries）
    * 临时索引（Transient indices）
    * VACUUM使用的临时数据库（Transient databases used by VACUUM）
    （1）回滚日志
    回滚日志是一个临时文件，用来实现原子提交和回滚功能。回滚日志总是位于与数据库文件相同的目录下，文件名为数据库文件名后加"-journal"。回滚日志通常在一个事务首次开始时创建，在一个事务提交或回滚时删除。如果没有回滚日志，SQLite将不能回滚一个未完成的事务，并且在事务执行的中间某时刻若发生系统崩溃或断电，数据库也会被损坏。回滚日志通常在事务的起点和终点创建和销毁，但也会有一些例外规则。
    如果崩溃或断电发生在事务的中间某时刻，则在硬盘上会留有回滚日志。在下次另外一个应用程序尝试打开数据库文件时，它会通知存在回滚日志(“热日志”)，并使用日志中的信息来把数据库恢复到未完成事务开始之前的状态。这就是SQLite实现原子提交的基本原理。
    如果应用程序使用指令"PRAGMA locking_mode=EXCLUSIVE;"把SQLite置于排斥锁模式下，则SQLite在带排斥锁模式会话的事务开始时创建一个新的回滚日志，在事务结束不会删除回滚日志。回滚日志可能会被缩小，或者它的头部可能会被清零（取决于你使用的SQLite版本），但文件不会被删除，直到排斥访问模式退出时回滚日志才会被删除。
    回滚日志的创建和删除也可以用日志模式PRAGMA指令来更改。默认的日志模式是DELETE，即在每个事务结束时删除回滚日志。PERSIST日志模式则放弃删除日志文件，而是把日志文件的头部清零，以防止其他进程回滚日志，因此这与删除日志文件有同样的效果，虽然实际上并没有从磁盘上删除日志文件。也就是说，日志模式PERSIST展示的行为与EXCLUSIVE锁模式相同。OFF日志模式让SQLite放弃在开始时创建回滚日志，它会禁用SQLite的原子提交和回滚功能，让ROLLBACK命令不可用。如果使用OFF日志模式的事务在中间某时刻发生崩溃或断电，则数据库文件不能恢复，可能会被损坏。
    （2）主日志文件
    主日志文件用于多数据库操作的原子提交过程中，即一个事务修改多个数据库，这些数据库通过ATTACH命令被关联在一个数据库连接上。主日志文件总是位于与主数据库文件(主数据库文件是在调用sqlite3_open()、sqlite3_open16()或sqlite3_open_v2()创建数据库连接时使用的数据库)相同的目录下，后跟一个随机的后缀。主日志文件中包含所有关联的辅助数据库名称。多数据库事务提交时主日志文件就会被删除。
    主日志文件只会在这样的情况下创建：一个数据连接与通过ATTACH关联的两个或多个数据库进行会话，并且一个事务修改多个数据库文件。如果没有主日志文件，多数据库事务对每个单独数据库的提交是原子性的，但对整个多数据库一起则不是原子性的。也就是说，如果提交在中间某时刻因为崩溃或断电而中断，则可能对一个数据库的更改完成，而对另一个数据库的更改被回滚。主日志文件确保所有数据库的所有更改要么一起回滚，要么一起提交。
    （3）SQL语句日志文件
    SQL语句日志文件用于回滚大型事务中一个单独SQL语句的部分结果。例如，假设一条UPDATE语句尝试修改数据库中的100行，但在修改完50行后，因为意外情况而终止。SQL语句日志用来撤消这50行的更改，以便数据库恢复到语句执行前的状态。
    SQL语句日志只会在一条UPDATE或INSERT语句修改数据库的多行，且意外终止或在触发器中抛出异常因而需要撤消部分结果的情况下创建。如果UPDATE或INSERT没有包含在BEGIN...COMMIT中，且在同一数据库连接上没有其他活动的SQL语句，则无需创建语句日志，因为可以使用原来的回滚日志。如果使用了可靠的冲突解决算法，则语句日志也会被忽略，例如：
UPDATE OR FAIL ...
UPDATE OR IGNORE ...
UPDATE OR REPLACE ...
INSERT OR FAIL ...
INSERT OR IGNORE ...
INSERT OR REPLACE ...
REPLACE INTO ....
    SQL语句日志文件使用随机的文件名，不一定要在与主数据库相同的目录下，在事务结束时自动删除。SQL语句日志的空间大小只是UPDATE或INSERT语句完成的更改部分的比例大小。
    （4）临时数据库
    使用"CREATE TEMP TABLE"命令创建的表格只在执行这条命令的数据库连接上可见。这些TEMP表格，以及任何关联的索引、触发器和视图，一起存放在一个单独的临时数据库文件中，这个临时数据库在首次遇到"CREATE TEMP TABLE"命令时创建。这个单独的临时数据库文件也有一个关联的回滚日志。用来存储TEMP表格的临时数据库会在使用sqlite3_close()关闭数据库连接时自动删除。
    临时数据数据库文件与通过ATTACH命令添加的辅助数据库文件非常类似，不过带有一些特殊属性。临时数据库文件总是在数据库连接关闭时自动删除。临时数据库总是使用synchronous=OFF和journal_mode=PERSIST这两条PRAGMA指令设置。并且，临时数据库不能使用DETACH，别的进程也不能通过ATTACH关联临时数据库。临时数据库文件和它的回滚日志只有在应用程序使用"CREATE TEMP TABLE"命令时才会被创建。
    （5）视图和子查询的持久化
    包含子查询的查询命令必须在某个时刻单独执行子查询并把结果存储在一个临时表格中，然后使用临时表格中的内容来执行外部查询。我们称之为“持久化”子查询。SQLite的查询优化器会尝试避免持久化，但有时候这是不可避免的。持久化过程创建的每个临时表格存储在它们自己单独的临时文件中，在查询结束时自动删除。这些临时表格的大小取决于子查询实体的数据数量。
    位于IN操作符右边的子查询通常必须被持久化，例如：
SELECT * FROM ex1 WHERE ex1.a IN (SELECT b FROM ex2);
    在上面的查询命令中，子查询"SELECT b FROM ex2"的执行结果被存储在一个临时表格中（实际为一个临时索引），它通过二进制搜索的方式来确定是否存在一个值ex2.b。一旦这个临时表格被创建，就运行外部查询，对每个预期的结果行检查ex1.a是否包含在临时表中，如果为true，则输出这个结果行。
    为了避免创建临时表格，查询可以重写为以下形式：
SELECT * FROM ex1 WHERE EXISTS(SELECT 1 FROM ex2 WHERE ex2.b=ex1.a);
    如果在列ex2.b上有索引，则3.5.4及以后版本的SQLite会自动做这样的重写。
    如果IN操作符的右边部分是值列表，像下面这样：
SELECT * FROM ex1 WHERE a IN (1,2,3);
    位于IN右边的值列表被认为是一个子查询，必须要持久化，也就是说此查询行为相当于下面这样：
SELECT * FROM ex1 WHERE a IN (SELECT 1 UNION ALL
                              SELECT 2 UNION ALL
                              SELECT 3);
    当IN右边是一个值列表时，会用一个临时索引来持有这些值。
    当子查询出现在SELECT命令的FROM子句中时也会进行持久化，例如：
SELECT * FROM ex1 JOIN (SELECT b FROM ex2) AS t ON t.b=ex1.a;
    根据查询，SQLite可能需要持久化"(SELECT b FROM ex2)"子查询到一个临时表格中，然后在ex1和临时表格之间执行连接。查询优化器会尝试“扁平化（flattening）”这个查询来避免子查询的持久化。在这个例子中，查询可以被扁平化，SQLite将自动把这个查询转换成:
SELECT ex1.*, ex2.b FROM ex1 JOIN ex2 ON ex2.b=ex1.a;
    更复杂的查询可能会，也可能不会进行扁平化处理以避免临时表格。是否扁平化处理取决于子查询或外部查询是否包含聚合函数、ORDER BY子句、GROUP BY子句或LIMIT子句等等。
    （6）临时索引
    SQLite使用临时索引来实现很多SQL语言特性，包括：
    * ORDER BY或GROUP BY子句
    * 聚合查询中的DISTINCT关键字
    * 复合式SELECT语句，即有UNION, EXCEPT或INTERSECT等连接子句
    每个临时索引存放在它自己的临时文件中，在SQL语句执行结束时被自动删除。
    SQLite会尝试使用已存在的索引来实现ORDER BY子句。如果在指定的字段上已存在索引，SQLite将遍历该索引（而不是创建临时索引）来提取需要的信息，并且以指定的排序输出结果行。如果SQLite没有找到合适的索引，则执行查询并把每行存储在一个临时索引中，索引的关键字为ORDER BY指定的字段。然后SQLite返回并从头到尾遍历临时索引，以指定的排序输出每行。
    对于GROUP BY子句，SQLite根据指定字段对输出行进行排序。每个输出行与先前行进行比较，看它是否属于新的组。GROUP BY字段的排序与ORDER BY字段的排序是相同的。如果有存在的索引就使用它，如果没有已存在的索引，则创建临时索引。
    聚合查询上的DISTINCT关键字会在一个临时文件中创建临时索引，并把每行结果存储到索引中。对新的结果行，如果在临时索引中已存在，则忽略它。
    复合查询的UNION运算符会在一个临时文件创建临时索引，并把左边和右边子查询结果存储到索引中，忽略重复的行。当两个子查询执行完后，从头到尾遍历临时索引来产生最后的输出。
    复合查询的EXCEPT运算符会在一个临时文件创建临时索引，并把左边子查询结果存储到临时索引中，然后从索引中移除右边子查询的结果，最后从头到尾遍历临时索引以得到最后的输出。
    复合查询的EXCEPT运算符会创建两个独立的临时索引，它们位于两个独立的临时文件中。左边和右边子查询被执行并存放到各自的临时索引中。然后一起遍历两个索引，输出同时存在于两个索引中的结果。
    注意复合查询的UNION ALL运算符自己并不使用临时索引，当然UNION ALL左边和右边的子查询可能会单独使用临时索引，这取决于它们是怎么复合的。
    （7）VACUUM命令使用的临时数据库
    VACUUM命令会先创建一个临时文件，然后重建整个数据库并写入到该临时文件中。之后将临时文件中的内容拷贝回原有的数据库文件中，最后删除该临时文件。VACUUM命令创建的临时文件不会比原有数据库文件大。

二、SQLITE_TEMP_STORE编译时参数和PRAGMA指令
    回滚日志、主日志和SQL语句日志文件总是会被写入磁盘，但其它类型的临时文件可能存放在内存中而不会写入磁盘（这样可以减少大量的IO操作），是写入磁盘还是存放于内存中取决于SQLITE_TEMP_STORE编译时参数，temp_store pragma运行时指令，以及临时文件的大小。对于SQLite来说，回滚日志、主数据库日志和SQL语句日志文件在需要的时候SQLite都会将它们写入磁盘文件，但是对于其它类型的临时文件，SQLite是可以将它们存放在内存中以取代磁盘文件的，这样在执行的过程中就可以减少大量的IO操作了。要完成该优化主要依赖于以下三个因素：
    1. 编译时参数SQLITE_TEMP_STORE
    SQLITE_TEMP_STORE编译时参数是源代码中的宏定义（#define），其取值范围是0到3（缺省值为1），如下：
    * 等于0时，临时文件总是存储在磁盘上，而不会考虑temp_store pragma指令的设置。
    * 等于1时，临时文件缺省存储在磁盘上，但是该值可以被temp_store pragma指令覆盖。
    * 等于2时，临时文件缺省存储在内存中，但是该值可以被temp_store pragma指令覆盖。
    * 等于3时，临时文件总是存储在内存中，而不会考虑temp_store pragma指令的设置。
　 2. 运行时指令temp_store pragma
    temp_store pragma指令的取值范围是0到2（缺省值为0），在程序运行时该指令可以被动态的设置，如下：
    * 等于0时，临时文件的存储行为完全由SQLITE_TEMP_STORE编译期参数确定。
    * 等于1时，如果编译期参数SQLITE_TEMP_STORE指定使用内存存储临时文件，那么该指令将覆盖这一行为，使用磁盘存储。否则直接使用SQLITE_TEMP_STORE的行为。
    * 等于2时，如果编译期参数SQLITE_TEMP_STORE指定使用磁盘存储临时文件，那么该指令将覆盖这一行为，使用内存存储。否则直接使用SQLITE_TEMP_STORE的行为。
    重申一下，SQLITE_TEMP_STORE编译时参数temp_store pragma指令只影响除回滚日志和主日志之外的其它临时文件的存储策略。换句话说，回滚日志和主数据库日志将总是将数据写入磁盘，而不会关注以上两个参数的值。
　 3. 临时文件的大小
    对于以上两个参数，都有参数值表示缺省情况是存储在内存中的，只有当临时文件的大小超过一定的阈值后才会根据一定的算法，将部分数据写入到磁盘中，以免临时文件占用过多的内存而影响其它程序的执行效率。

三、其他临时文件优化策略
    SQLite对当前读写的数据库页面采用了Page Cache的缓冲优化机制，因此即便临时文件被指定存储在磁盘上，也只有当该文件的大小增长到一定的尺寸后（导致页面缓存填满）才有可能被SQLite刷新到磁盘文件上，在此之前它们仍将驻留在内存中。这就意味着对于大多数场景，如果临时表和临时索引的数据量相对较少（页面缓存足够存放它们），那么它们是不会被写到磁盘中的，当然也就不会有磁盘IO发生。只有当它们增长到内存不能容纳的时候才会被刷新到磁盘文件中的。
    每个临时表格和索引都有自己的页缓存，它们能存放最大多少个数据库页面由SQLITE_DEFAULT_TEMP_CACHE_SIZE编译期参数来确定，这个参数指定了临时表和索引在占用多少Page Cache时才需要被刷新到磁盘文件，该参数的缺省值为500页。这个参数值不能在运行时修改。

四、内存数据库
    在SQLite中，数据库通常存储在磁盘文件中。然而在有些情况下，我们可以让数据库始终驻留在内存中。最常用的一种方式是在调用sqlite3_open()、sqlite3_open16()或sqlite3_open_v2()时，数据库文件名参数指定为":memory:"，如：
rc = sqlite3_open(":memory:", &db);
    在调用完以上函数后，不会有任何磁盘文件被生成，取而代之的是，一个新的数据库在纯内存中被成功创建了。由于没有持久化，该数据库在当前数据库连接被关闭后就会立刻消失。需要注意的是，每个:memory:数据库是不同的数据库，也就是说，用文件名":memory:"打开两个数据库连接将创建两个独立的内存数据库。
    文件名":memory:"可以用在任何允许使用数据库文件名的地方。例如，它可以用于ATTACH命令中，让内存数据库像其他普通数据库一样，附加到当前的连接中，如：
ATTACH DATABASE ':memory:' AS aux1;
    注意在创建内存数据库时，只能用文件名":memory:"，不能包含其他文本，例如"./:memory:"，这样会创建一个基于磁盘文件的数据库。在使用URI格式的文件名时，也可以使用":memory:"，例如：
rc = sqlite3_open("file::memory:", &db);
    或者
ATTACH DATABASE 'file::memory:' AS aux1;
    如果内存数据库使用URI文件名打开，则它可以使用共享缓存。如果通过未修饰的":memory"名来指定内存数据库，则这个数据库总是有一个私有的对其他连接不可见的缓存。如果使用URI文件名，则同样的内存数据库可以被两个或多个数据库连接打开，例如：
rc = sqlite3_open("file::memory:?cache=shared", &db);
    或者 
ATTACH DATABASE 'file::memory:?cache=shared' AS aux1;
    这使得多个数据库连接可以共享同一个内存数据库。当然，共享一个内存数据库的这些连接需要在同一个进程中。当最后一个数据库连接关闭时，内存数据库自动被删除。
    如果需要在一个进程中使用多个不同的但可共享的内存数据库，可以在URI文件名中附加mode=memory查询参数来创建一个命名的内存数据库：
rc = sqlite3_open("file:memdb1?mode=memory&cache=shared", &db);
    或者  
ATTACH DATABASE 'file:memdb1?mode=memory&cache=shared' AS aux1;
    以这种方式命名的内存数据库，只会与名字精确相同的另一个连接共享它的缓存。

五、(空文件名对应的)临时数据库
    在调用sqlite3_open()函数或执行ATTACH命令时，如果数据库文件参数传的是空字符串，那么一个新的临时文件将被创建以作为临时数据库的存储文件，如：
rc = sqlite3_open("", &db);
    或者
ATTACH DATABASE '' AS aux2;
    每次都会创建不同的临时文件，和内存数据库非常相似，两个连接创建的临时数据库也是各自独立的，在连接关闭后临时数据库将自动消失，其存储文件也将被自动删除。
    尽管磁盘文件被创建用于存储临时数据库中的数据信息，但是实际上临时数据库也会和内存数据库一样，通常驻留在内存中，唯一不同的是，当临时数据库中数据量过大时，SQLite为了保证有更多的内存可用于其它操作，因此会将临时数据库中的部分数据写到磁盘文件中，而内存数据库则始终会将数据存放在内存中

IIS上部署的ASP.NET站点都会在一个.Net Framework的特定目录下生成临时编译文件增加ASP.NET站点的访问性能，有时候需要手动去删除这些临时编译文件，特别是发布新版本代码到IIS后，如果发现新发布的代码在IIS上没有生效，那么很有可能是.Net Framework下生成的临时编译文件没有被自动更新。所以需要去手动删除这些临时编译文件，强制IIS通过新发布的代码生成新的临时编译文件。这里找到了一篇文章介绍了IIS、Asp.net 编译时的临时文件，记录下来作为参考！

ASP.NET 会定期在应用程序发生改变、需要重新编译时清理编译文件夹并删除陈旧的资源，但 Temporary ASP.NET Files 目录下的子树的大小可能会显著地增加，在测试计算机上更是如此。 作为管理员，您应密切关注 Temporary ASP.NET Files 下的目录，并确保所有目录都是与当前活动的应用程序有关的。如果您无意间删除了一个处于活动状态的应用程序的子树，不必惊慌。您将丢失所有预编译的页面和资源并会将应用程序重置到其最初的编译状态；但下一个请求将触发对每个页面或一批页面（具体取决于配置）执行新的编译过程，因此最终不会丢失任何信息或页面，只不过用户在处理下一个请求时将感觉到首次命中延迟。 

今天同事反映服务器的空间不够用了，结果发现Temporary ASP.NET Files特别大，才明白，这个是.net的编译文件，每次更新版本，都会重新编译到该目录下。删掉后，以后第一次访问的时候速度会慢一些。 

正在使用被IIS进程使用的文件删除不掉。 

路径：



C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Files

当前标识没有对“C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Files”的写访问 

我发现只要删除C:\WINDOWS\Microsoft.net\Framework\v2.0.50727\Temporary ASP.net Files 里面的文件就可以了，删除以后一切恢复正常，也就是说.net在运行的过程中会不断的往这个临时文件夹写入一些数据，因为某种原因，这些数据写不进去了，所以提示没有写入权限，这种情况发生的几率其实很小，经常会出现在服务器在有很多用户访问的时候重启了服务器，这时有可能会出现这种错误。

但是我发现清空了里面的问题，暂时是好了，但是只要时间一长又会重新出现这个错误，百思不得其解，查看系统的应用程序日志，找到了原因。在出现这个错误之前，系统有一条错误日志，说的是磁盘空间不足，奇怪，我的服务器每个盘都还有好几十个G的空间，怎么会报磁盘空间不足，突然想起来原来是我在服务器上做了磁盘配额，每个用户只分配了10G可用空间，检查networkService用户，它的磁盘空间已经用户，所以才报没有写入权限的错误。扩大其磁盘配额，一切恢复正常。

如果大家出现这个问题，建议大家检查一下磁盘空间是否真的不足，是否加了磁盘配额，另外查看一下 C:\windows\temp文件夹，因为.net 运行时需要network Service用户访问这个文件夹，看看这个文件夹内的文件是否太大，定时清空一下。

一切OK！

Temporary ASP.NET Files 文件夹中保存的是什么内容

作为一名 ASP.NET 开发人员，您可能非常清楚 ASP.net 如何处理 .aspx 资源中的代码，如何对标记进行分析并将其动态转换成 Visual Basic® 或 C# 类，等等。但是接下来呢？ASP.Net 生成的文件保存在哪里？如何利用它们满足页面请求？从上个月起，我开始关注这一过程。在本月的内容中，我将对服务器上所发生的操作进行分析，以便您能够避免某些常见的问题隐患。 我将讨论 ASP.NET 临时文件的存储以及动态生成的用于为页面响应提供服务的类的源代码。此外，我还将构建一个可以与任何 ASP.NET 2.0 或 ASP.NET AJAX（原代号为“Atlas”）应用程序一同使用的资源管理器工具，以查看和调试您的页面执行的实际代码。但在此之前，您需要了解几个事项。（和上月专栏一样，本部分内容主要以那些没有文档记录的 ASP.NET 工作原理细节为基础来展开。这些实施细节在未来的 Microsoft® .NET Framework 版本中可能会发生变化。）

Temporary ASP.NET Files 文件夹中保存的是什么内容？

ASP.NET 页面请求的处理过程需要使用一些临时文件。当您在 Web 服务器上安装 ASP.NET 2.0 时，所创建的文件夹层次结构如下：



%WINDOWS%\Microsoft.NET\Framework\v2.0.50727

这里的版本号指的是 ASP.NET 2.0 的零售版。ASP.NET 的每个发布版本（包括每个过渡性的内部版本）都有一个唯一的版本号，并且会创建不同的文件夹树，以便支持不同版本的并行执行。因此，您务必要指定您的应用程序所适用的 ASP.NET 版本，这一点极为重要。在 ASP.NET 1.x 和 ASP.NET 2.0 下运行的应用程序基于物理形式上独立的文件夹。在 Microsoft.NET\Framework 文件夹下，您会找到与已安装的 ASP.NET 版本数相同数量的 vX.X.XXXX 子文件夹（请参见图 1）。



图 1 ASP.NET 1.0、1.1、2.0 和 3.0 运行库文件 

在已安装版本的根文件夹下，您会看到许多子目录。CONFIG 文件夹包含计算机配置文件，其中包括 machine.config 和用于所有站点的基本 web.config 文件。名为 ASP.NETWebAdminFiles 的文件夹包含构成网站管理工具的源文件，您可从 Visual Studio® 2005 内部运行该工具。最后，Temporary ASP.NET Files 文件夹包含为页面和资源提供服务而创建的所有临时文件和程序集。要找到为您的 Web 页面动态创建的文件，您需要查看此文件夹子树。请注意，Temporary ASP.NET Files 目录是存放动态创建的文件的默认位置，但可以使用 web.config 文件中的  部分按应用程序对其进行配置：



当应用程序第一次在计算机上执行时，在临时文件目录下就会创建一个新的子文件夹。编译子文件夹的名称与应用程序的 IIS 虚拟目录的名称相同。如果您只是使用 Visual Studio 2005 内嵌的 Web 服务器测试应用程序，那么子文件夹会采用该 Web 应用程序的根文件夹的名称。如果您从 Web 服务器的根文件夹调用页面，您将在根子文件夹下找到它们的临时文件（请参见图 2）。 


图 2 Web 测试服务器上的 WebApp

在应用程序的编译子文件夹下，有一组使用散列名称的目录。此处显示了通常可以找到临时文件的路径。（最后两个目录包含的是假名称，但实际显示的就是这样的名称。）



\v2.0.50727\Temporary ASP.NET Files\MyWebApp\3678b103\e60405c7

您可以使用以下语句，以编程的方式检索指定应用程序的临时文件所在的子文件夹的路径：



Dim tempFilesFolder As String = HttpRuntime.CodegenDir

ASP.NET 会定期在应用程序发生改变、需要重新编译时清理编译文件夹并删除陈旧的资源，但 Temporary ASP.NET Files 目录下的子树的大小可能会显著地增加，在测试计算机上更是如此。 作为管理员，您应密切关注 Temporary ASP.NET Files 下的目录，并确保所有目录都是与当前活动的应用程序有关的。如果您无意间删除了一个处于活动状态的应用程序的子树，不必惊慌。您将丢失所有预编译的页面和资源并会将应用程序重置到其最初的编译状态；但下一个请求将触发对每个页面或一批页面（具体取决于配置）执行新的编译过程，因此最终不会丢失任何信息或页面，只不过用户在处理下一个请求时将感觉到首次命中延迟。现在，我们来看某一应用程序的编译文件夹的内容。 

Back to top



保留文件

对于应用程序中的每个页面，页面编译进程会生成一个下述名称的文件：



[page].aspx.[folder-hash].compiled

[page] 占位符代表 .aspx 资源的名称。 

[folder-hash] 占位符是一个散列值，它使文件名保持唯一，避免与原本属于其他文件夹的同名文件混淆。这种文件称为保留文件，因为它们包含有重要的信息，这些信息可帮助 ASP.NET 运行库快速检索程序集以及检索将用于为页面请求提供服务的 HTTP 处理程序的类型名称。此外，保留文件还包含一个文件散列值，用于检测自从上次访问后文件的内容是否发生了改变。

构成某一应用程序的所有 .aspx 页面在同一个临时文件夹中进行编译，即使它们名称相同且位于不同的文件夹中也是如此处理。这一点如何实现？假设您的应用程序包含两个名为 test.aspx 的页面，位于不同的文件夹 － Folder1 和 Folder2 中。两个页面将在同一临时文件夹中进行编译，但可以通过它们的散列值对其进行区分，由于散列值是根据路径信息而不只是文件名计算出来的，因此它们的散列值是不同的。因而最终，两个 test.aspx 页面的保留文件名只在文件夹散列值部分有所不同：



Test.aspx.cdcab7d2.compiled
Test.aspx.9d86a5d7.compiled

散列值的内部存储缓存使 ASP.NET 运行库可以识别任何指定页面 URL 的散列值并快速找到相应的保留文件。如果没有找到保留文件，ASP.NET 会动态编译页面。当您部署没有预编译的应用程序时就会发生这种情况。另一方面，当您对一个站点进行预编译时，每个组成页面的保留文件被创建并放置在 Bin 文件夹中。

保留文件为纯 XML 文件。图 3 显示了一个示例保留文件的内容。

图 4 具体列出了文件的属性。<fileDeps> 部分列出了当前页面所依赖的文件。对任何依存关系所做的任何改动都将导致页面重新编译。FileHash 值代表依存关系状态的快照，而 Hash 代表当前页面文件状态的快照。值得注意的是，当您停止或重新启动 Web 应用程序时，完全基于文件更改通知来检测文件动态更改的机制会失败。按照散列值保存页面和依存关系的状态，使您可以随时检测到更改。

类型 (Type) 属性设置动态创建的类（将用于为请求提供服务）的名称。默认情况下，类型名称是 ASP.[page]_aspx，其中 [page] 代表页面文件的名称。但是请注意，您可以通过设置您的 .aspx 文件的 @Page 指令中的 ClassName 属性来更改此名称。根命名空间不会更改，因此类型名称可以是 ASP.[ClassName]。

程序集 (Assembly) 属性指示动态创建的程序集的名称，该程序集包含用于为请求提供服务的页面类。此类程序集的名称和内容取决于 web.config 文件的  部分中的设置。

默认情况下，应用程序页面以批处理模式编译，这意味着 ASP.NET 会尝试在一个程序集中容纳尽可能多的未编译页面。使用 maxBatchSize 和 maxBatchGeneratedFileSize 属性可以限制一个程序集中封装的页面数量以及程序集的总大小。默认情况下，每个批处理编译将拥有不超过 1000 个页面，并且所有程序集都不大于 1MB。一般来说，当第一次编译大量页面时，您不应让用户等待太长时间。同时，您不应该在内存中加载大型程序集而只是为一个小页面来提供服务，或者为每个页面启动编译。 maxBatchSize 和 maxBatchGeneratedFileSize 属性可帮助您在首次命中延迟和内存使用之间找到良好的平衡。 如果您选择站点预编译（请参阅本杂志 2006 年 1 月 Fritz Onion 的 Extreme ASP.NET 专栏），那么您不必担心首次命中延迟，但您仍应考虑最佳的批处理参数，以避免 Web 服务器的内存过载。

当批处理开启时，应用程序中的前 1000 个页面（实际数量取决于 maxBatchSize）被编译为名为 App_Web_[random] 的程序集，其中 [random] 是由八个字符组成的随机序列。 如果关闭批处理，则每个页面将产生各自的程序集。程序集的名称如下：



App_Web_[page].aspx.[folder-hash].[random].dll

要关闭批处理，可向 web.config 文件添加以下内容：



<compilation batch="false" />

如果您对一个示例应用程序的编译文件夹进行查看，您会找到名称中包含 CBMResult 的附带保留文件，还有一个具有相同名称的 .ccu 文件，如下所示：



test.aspx.cdcab7d2.compiled
test.aspx.cdcab7d2_CBMResult.ccu
test.aspx.cdcab7d2_CBMResult.compiled

列表中的第一个文件是保留文件。那么其他两个作何用途？ CCU 代表代码编译单元 (Code Compile Unit)，是指用于生成动态页面类的源代码而创建的 CodeDOM 树。 CCU 文件是二进制文件，包含经序列化的页面 CodeDOM 树。CBMResult 文件是保留文件，用于检查 CCU 是否最新、其所在的位置以及它基于哪些文件。

CBMResult 文件由与 ClientBuildManager 类通信的模块（例如，Visual Studio 2005 设计器和 IntelliSense®）来使用。这些模块查询页面的结构来获取语句结束信息。CCU 文件会保留准备为这些请求提供服务的页面的最新 CodeDOM 结构副本。 

Back to top



页面类动态源代码

正如上面提到的，.aspx 资源被解析为 Visual Basic 或 C# 类。该类继承自 System.Web.UI.Page，或者很可能继承自某个从 System.Web.UI.Page 继承而来的类。事实上，在大多数常见情形下，动态页面类具有以下原型：



Namespace ASP
Public Class test_aspx
Inherits Test : Implements System.Web.IHttpHandler
...
End Class
End Namespace

在此例中，Test 类在页面的代码文件类中定义，它包括您在页面的附带类文件中写入的任何事件处理程序和帮助器例程。在您使用 Visual Studio 2005 时可能已经注意到，此代码文件类缺少页面成员的定义。对于您在 .aspx 源文件中找到的每个 runat=server 标记，在代码文件中应定义有相应类型的成员。ASP.NET 运行库系统会生成 Test 分部类，包含所有这些成员以及两个额外的属性 － Profile 和 ApplicationInstance。图 5 显示了参与为某一 .aspx 资源的请求提供服务的类集。

图 5 中的类跨两个不同的源文件。第一个包含分部类，用于完善代码文件中的类和由此派生出的用于为请求提供服务的实际页面类。第二个文件是您在项目中创建的代码文件的副本。这些文件根据程序集名称而命名。名称的结构如下：[assembly].X.vb。（如果您使用 C#，则为 .cs）X 为从 0 开始的递增索引值，可确保文件名唯一。

如果您查看示例 test.aspx 页面的编译文件夹的内容，您会发现创建了第三个文件，如下例中所示：



Namespace __ASP
Friend Class FastObjectFactory_app_web_test_aspx_cdcab7d2_xg83msu0
Private Sub New()
MyBase.New
End Sub
Shared Function Create_ASP_test_aspx() As Object
Return New ASP.test_aspx
End Function
End Class
End Namespace

类名称是以字符串 FastObjectFactory 为前缀的页面程序集的名称。该类具有一个名为 Create_XXX 的共享函数（如果以 C# 编写则为静态函数），其中的 XXX 是要实例化的页面类的名称。顾名思义，这是一个帮助器类，ASP.NET 运行库利用其来加速页面实例的创建 － 这是一个非常常见的操作。与编译一个页面相比，创建这种类所花费的时间非常短。另一方面，使用工厂类比使用 Activator.CreateInstance 间接创建对象要快得多。

根据批处理编译设置，工厂类的内容会有所变化。在默认情况下，当批处理开启时，工厂类包含与批处理页面相同数量的 Create_XXX 函数。工厂类的名称与批处理程序集的名称相同：



' Used to serve test.aspx
Shared Function Create_ASP_test_aspx() As Object
Return New ASP.test_aspx
End Function
' Used to serve default.aspx
Shared Function Create_ASP_default_aspx() As Object
Return New ASP.default_aspx
End Function

如果批处理关闭，则工厂类与单个页面程序集的名称相同，并且只包含一个共享函数 － 具体页面的 facotry。在这种情况下，应用程序中的每个页面将有自己的工厂类。 

Back to top



运行库公共 API

借助上面讨论的信息，探究编译文件夹的内容就不是非常困难了。但通过一个工具来帮助您快速找到您所需的信息还是非常方便。 我待会儿将设计一个用来导航动态生成的 ASP.NET 应用程序源代码的资源管理器工具，但首先我们来看一看 .NET Framework 2.0 中的一些运行库 API。特别是，以下两个类可能是您更希望了解的：HttpRuntime 和 ClientBuildManager。

HttpRuntime 类具有大量共享属性，可返回关于包括当前应用程序的 Bin 文件夹、ASP.NET 安装路径、编译文件夹和当前 AppDomain ID 在内的各种系统路径的信息。您还可以使用以下代码轻松获取当前 AppDomain 中加载的程序集列表：



Dim listOfAssemblies() As Assembly
listOfAssemblies = AppDomain.CurrentDomain.GetAssemblies()

此代码并非特定于 ASP.NET，但当从 ASP.NET 应用程序内部调用时，它将返回包含 AppDomain 中的程序集的数组，其中包括为您的页面生成的所有程序集。

ClientBuildManager 类没有多少信息一类的属性，CodeGenDir 属性除外，该属性返回与 HttpRuntime 的 CodeGenDir 属性相同的信息。但 ClientBuildManager 具有许多读取配置信息（如支持的浏览器）的方法和预编译应用程序的方法。Get 是该类中的一个方法，它返回一列应用程序的目录（在这些目录中监视那些会引发关闭 AppDomain 应用程序的重要更改）。这些目录是：App_Browsers、App_Code、App_GlobalResources、App_WebReferences 和 Bin。 

Back to top



构建资源管理器工具

对于调试，能够快速访问正在运行的页面的源代码和其他运行时信息往往非常有用。任何提供这种功能的工具都必须与所有 ASP.NET 应用程序兼容，并且只要求进行有限的配置或根本无需配置。Nikhil Kothari 出色的 Web Development Helper 工具如果能够提供 ASP.NET 运行库信息，那就非常完美了。该工具作为浏览器帮助对象 (BHO) 来实现，BHO 是一种用于 Microsoft Internet Explorer® 用户界面的基于 COM 的插件。BHO 对于我在本专栏中构建的监视工具将是非常好的宿主环境，但可惜我偷了些懒，并没有这样做。因此我将我的工具编写为位于页面和浏览器之间的一个 HTTP 模块，它可查找查询字符串，如果是显式调用就可发挥作用。在 ASP.NET 应用程序中安装 HTTP 模块只需在 web.config 中增加一行语句，而且可以非常容易地开启和关闭安装：



<httpModules>
<add name="AspExplorerModule" type="Samples.AspExplorerModule" />
</httpModules>

图 6 显示了 Explorer HTTP 模块的大部分代码。该模块注册使用 PostMapRequestHandler 应用程序事件并与页面类挂接。PostMapRequestHandler 事件会在 ASP.NET 运行库确定了为请求提供服务所需的 HTTP 处理程序对象时触发。如果请求的查询字符串中包含 source=true 参数，并且处理程序是从 System.Web.UI.Page 继承的一个类，那么模块将开始工作。

ASP Explorer 模块会与页面类挂接，并为 PreRenderComplete 事件注册其自己的处理程序。这样的设计使得 HTTP 模块不会改变请求的运行时处理，也不会干预页面的编译。当查询字符串指定了 source 参数并将其设置为 true 时，模块就会发挥作用。如图 6 中所示，模块所要做的就是使用不太常见的“页面”类方法 SetRenderMethodDelegate 为页面注册呈现委派 (rendering delegate)。当为页面指定了呈现委派时，所封装的方法会替代标准呈现处理。换言之，一旦安装了该模块，如果使用 test.aspx 进行调用，您将看到页面的标准输出；如果您使用 test.aspx?source=true 进行调用，您将看到模块可收集的所有与页面有关的运行时信息。

ASP Explorer 源代码定义了一个类，以映射当前页的保留文件的内容。它会读取保留文件，并复制图 7 所示的类中的所有信息。SourceFiles 属性是设计用于包含页面使用的所有源文件的一个集合。此集合包含从编译文件夹获得的保留文件中所没有的信息。特别是其中包括与某个页面相关的 .vb 或 .cs 格式的所有源文件，这些文件名以动态页面程序集的名称开头。GetWebPageInfo 方法（请参见图 6）捕获所有信息并为 source 模式的请求构建输出内容。页面输出包括运行时信息和动态页面类的源代码。图 8 显示了实际运行中的 ASP Explorer。 


图 8 实际运行中的 ASP Explorer 模块



示例页面分析

既然有了可使用的工具，那么让我们简要查看一下 ASP.NET 为每个 .aspx 文件生成的代码的结构。值得注意的是，如果没有 ASP.NET 运行库提供的分析和编译工具，您就必须亲自编写代码来运行 ASP.NET 页面！

动态页面类（图 5 中的 test_aspx 类）改写了 System.Web.UI.Page 类中的几个方法：FrameworkInitialize、ProcessRequest 和 GetTypeHashCode。ProcessRequest 没有什么变化，它只是调用它的基类方法。GetTypeHashCode 返回页面的散列代码，该代码可唯一标识页面的控件层次结构。当对页面进行编译时，会动态计算散列值，并将其作为常量插入到源文件。

最值得关注的是对 FrameworkInitialize 的改写。该方法控制页面的控件树的创建，并调入一个名为 __BuildControlTree 的私有方法。此方法使用与 .aspx 源文件中的 runat=server 标记相对应的控件的新实例来填充页面类的 Control 集合。__BuildControlTree 会分析所有服务器端标记并为每个标记构建一个对象。



<asp:textbox runat="server" id="TextBox1" text="Type here" />

以下是为上述标记获取的典型代码：



Private Function __BuildControlTextBox1() As TextBox
Dim __ctrl As New TextBox()
Me.TextBox1 = __ctrl
__ctrl.ApplyStyleSheetSkin(Me)
__ctrl.ID = "TextBox1"
__ctrl.Text = "Type here"
Return __ctrl
End Function

如果控件有事件处理程序或数据绑定表达式，会怎样？让我们首先来考虑带“单击”事件处理程序的按钮。您需要增加一行语句：



__ AddHandler __ctrl.Click, AddressOf Me.Button1_Click

对于数据绑定表达式 <%# … %>，除了使用了 DataBinding 事件，生成的代码与之类似：



AddHandler __ctrl.DataBinding, AddressOf Me.DataBindingMsg

与处理程序相关的代码取决于绑定的控件的属性和要绑定的代码。对于 Label 控件的 Text 属性，代码类似于：



Public Sub DataBindingMsg(ByVal sender As Object, ByVal e As EventArgs)
Dim target As Label = DirectCast(sender, Label)
target.Text = Convert.ToString(..., _
CultureInfo.CurrentCulture);
End Sub

传递给 Convert.ToString 的表达式就是 <%# … %> 表达式中的代码。强制类型转换还取决于所涉及的类型。

如果存在母版页和主题，那么源文件的数量和依存关系列表就会增大，但借助 ASP Explorer 工具，您可以随意对其进行跟踪。



总结

ASP.NET 对其拥有的资源类型执行按需动态代码编译。此功能大大促进了 Web 应用程序的快速迭代开发，但需要 ASP.NET 才能将文件写到磁盘。编译文件夹是一个重要的文件夹，ASP.NET 的许多神奇之处都在此体现。您可以只是出于兴趣对此文件夹研究一番，有时却可以利用它来诊断和调试棘手的问题。当然，这里讨论的大部分功能是 ASP.NET 内部的功能，因此来说，这些功能在未来版本中可能会未经提醒即进行更改。 但截至目前为止，ASP.NET 2.0 的工作原理就是如本文所述的这样。顺便提一下，可以将 ASP Explorer 工具与 ASP.NET AJAX 应用程序一起使用，这一点也请放心。 该工具的运行效果非常好。

一，异常信息：

 

java.io.IOException: The temporary upload location 
[C:\Users\Administrator\AppData\Local\Temp\tomcat.1668302398522753093.8383\work\Tomcat\loca
lhost\ROOT] is not valid

二，原因：

文件上传临时上传文件夹失效了，可能是系统清除了临时目录。

三：解决方法：

1：重启服务，不建议在生产环境使用。

2：增加服务配置，自定义baseDir。

server.tomcat.basedir=/tmp/tomcat



3：注入bean，手动配置临时目录，建议有项目组统一配置，便于管理和错误定位。

@Bean
  MultipartConfigElement multipartConfigElement() {
    MultipartConfigFactory factory = new MultipartConfigFactory();
    factory.setLocation("/tmp/tomcat");
    return factory.createMultipartConfig();
  }