文件上传之后

大家经常会利用上传组件上传文件吗？你的空间是否足够大，以至于可以不考虑冗余文件的处理？这里所说的冗余文件，是指用户修改信息或误操作后，不再与信息关联的文件，久而久之，这些文件会占用相当大的空间。
以下情况可能产生冗余文件：
1.用户修改了原信息。
用户可能在修改信息的同时更换了上传文件，而被更换的文件留在了服务器上；
2.用户在发布信息过程中操作失误，系统提示错误，用户返回后，上传了与原文件不同的文件，原文件留在了服务器上；
3.删除信息时未将与其关联的上传文件同时删除。
为了在以上几种情况出现时，都将冗余文件处理掉，我采取了一些可能有些繁琐的办法，但是为了可怜的空间，繁琐就繁琐点吧。以下办法仅限于利用文件上传组件的操作，如果是将文件存在库里，希望也能有所参考。

先从上传说起
上传文件可能采取两种方式：
1.信息入库与文件上传同时操作；
2.先让用户上传文件，然后信息入库；
我以前采用过第一种方法，后来再做此类功能的时候放弃了。它虽然可以将上传文件的相关信息，如文件个数，文件名等与信息同时写入库中，但是缺点也很明显，比如处理中出错的可能性大大增加；允许用户上传多个文件时需加入多个<input type=file>循环处理，一处有错，全部重来；如果用户对不同文件的显示位置有要求，处理较困难等等。
采用第二种办法，可以对每次上传单独控制，但是需要把上传的信息如[upload=***]******.***[/upload]用javascript写回<textarea>，显示的时候用UBB处理。我对js的可靠性不放心，但是鱼与熊掌不可兼得，舍鱼而取熊掌也。
这里插一下对文件上传个数的控制，有些同学把上传个数写入库表，或用session，我感觉都不够灵活，比如用户修改时，如何使上传文件个数相应变化呢？得费些功夫。我的办法是判断<textarea>中[upload]...[/upload]的个数，用户如想修改，从<textarea>删去欲修改的[upload]...[/upload]，可再上传直至允许的个数。
上传时，文件名一般用上传时间加随机数替换，这样做有两个目的，一是保证文件不重名，二是避免文件名中的非法字符造成上传的文件无法正确显示。
但是我把每一篇“文章”中上传的文件，放在单独的一个文件夹中，文件夹的名字也用时间加随机数生成，这样做是为了删除文件时便于操作----只要删掉一个文件夹就OK了，试想从相对较少的文件夹找到要删掉的文件夹，与从一大堆文件中找到要删除的文件相比，还是要省些功夫的。

下面针对可能产生冗余文件的操作，介绍我的做法：
1.删除文件时。
上面说过了，只要删掉与信息关联的文件夹就可以了。
但是这个文件夹要写到库表中的，我是这样做的：在信息发布的表单中设一个<input type=hidden name=filepath>，当上传第一个文件时，生成文件夹名，[upload]写回<textarea>的同时，文件夹名写回filepath，每次上传前判断这个控件中是否有值，如有，就不再生成文件夹名了。这样修改信息时，也可以保证文件上传到原来的文件夹。
2.修改信息时。
在用户修改信息时，前面说过，只要删掉<textarea>中的[upload]，就可上传其它文件，但是原先上传的（也就是用户删掉的[upload]所标识的）那个文件留在了服务器上。这时候，我遍历filepath下的所有文件（这也是建文件夹的目的之一），判断每个文件是否在<textarea>中，如果不在，将其删除。简单的办法是直接查找<textarea>的字串中是否包含从文件夹中取得的文件名，如果嫌不保险，也可以利用正则表达式，取得<textarea>中[upload][/upload]中间的文件名，与文件夹中物理存在的文件名比较。
3.信息发布时。
用户在发布信息时，可能预览后对上传的文件不满意，返回去修改，这时候的操作跟上面一样，也就是说，在发布时也要比对filepath中的文件名与<textarea>中的文件名。这样当然会影响发布的速度，为了节省空间，只好以时间换空间了。
还有一种情况：用户上传了文件后，没有来得及发布，关掉了浏览器，转到了其它页面，或是出现其它意外，这时候会造成站点空间中存在一个与任何信息不关联的文件夹。为了处理这种情况，我加了一个表，在生成文件夹名的同时，将其存入这个表，信息发布的同时，再把它从表中删去。这样，那些“孤立”的文件夹就会留在新加的这个表中，管理员可以每隔一段时间将表中的文件夹删除，清理一下这些“孤立”的文件夹。

采用以上办法，只需要在表中记录下文件夹名，而不用另外记录上传的文件名（文件名存在于信息正文中）。
当然，还存在其它的情况，比如在修改时，用户上传了新文件，然后关闭了浏览器，这时候在上传文件夹中会出现冗余文件。但是我以上的处理，已经使出现冗余文件的可能性大大减小了，如果您觉得有必要，可以进行更细致，同时也是更繁琐的处理:)

原文转自：http://www.ltesting.net