日期:2013-07-21  浏览次数:20858 次

大家经常会利用上传组件上传文件吗?你的空间是否足够大,以至于可以不考虑冗余文件的处理?这里所说的冗余文件,是指用户修改信息或误操作后,不再与信息关联的文件,久而久之,这些文件会占用相当大的空间。
以下情况可能产生冗余文件:
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>中的文件名。这样当然会影响发布的速度,为了节省空间,只好以时间换空间了。
还有一种情况:用户上传了文件后,没有来得及发布,关掉了浏览器,转到了其它页面,或是出现其它意外,这时候会造成站点空间中存在一个与任何信息不关联的文件夹。为了处理这种情况,我加了一个表,在生成文件夹名的同时,将其存入这个表,信息发布的同时,再把它从表中删去。这样,那些“孤立”的文件夹就会留在新加的这个表中,管理员可以每隔一段时间将表中的文件夹删除,清理一下这些“孤立”的文件夹。

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