这几天的工作主要围绕着文件（主要是图片）上载，并可以在线和HTML编辑器集成，操作简便与目前引用网上图片相似。我是有点小看了这件事情，不过也不无道理：一来以前使用servlet完成过，其中的核心DoUpLoadBean也的确是可以工作；其次集成到编辑器则在使用php的本人的私人博客上做过，看不出有什么特别难的地方。但实际上在展开后就发现，简单实现上载是容易的，但要合理地安排上载的策略，就不得不小心翼翼。因为允许上载本身是非常需要危险的，这实际上是开了一个口子；允许客户对服务器进行事实上的操作，上载攻击从来就不是一件困难，更不是一件罕见的事情；可以想见一旦系统开通，这类攻击必然就会发生。 另一方面，在允许用户上载本地文件同时就必须考虑后期的管理，因为，即使是在用户本地，最大的硬盘也会过不多久就会给说不清是什么东西的垃圾占满；何况现在是允许许多人同时使用的服务器，如果没有精确的策略，花不了多长时间，客户的上载文件就会把系统撑爆。就在上一个星期，一位朋友向我求助，说是他们的数据库达到30G，把硬盘吃光了，结果死了机；对此，本人只能是爱莫能助，因为，可以肯定里面绝大部分是垃圾，却搞不清什么是垃圾，什么是必须的。因为，他们缺乏一个策略。而且，就算用户不是恶意的，大部分情况下，在开通开载的时侯，很快硬盘也会撑满，如果这是系统盘，通常就意味着崩溃，可见，必须使用连接把上载限制到另一个专用的分区，以确保安全。通常铁quota在这里是派不上用场的，因为那需要把WEB帐号与操作系统帐号结合，既复杂又危险，更加没有这个必要。同时，上载的文件如果不是给每个用户分配目录，也应该是在每个用户的名称前增加一个前缀，以供识别；这样，万一需要清理，配合文件日期，可以使用find/grep/rm组合脚本进行备份或清除，至少是有可能的。
还有其他因素，导致上载文件实际操作比简单接爱一个文件上载的程序量要大得多；其中主要包括权限控制，（考虑到可以用上载进行攻击，这条不得不小心点），文件管理，以及修改属性，包括大小，类型限制，可以方便修改存储的方式等等，事实上，就完成情况下，上载部分只花了五行程序，而管理则不小于50行。
今天已经不必再自已写输入流了，就算自已没有积累，还是可以从网上找到开源的代码，象jakarta commons upload就是一个。这个东西没有什么例子，所找到的例子大部分是跑不动的，倒不是怪程序员自已，而是这个东西不但没有什么文档，还把方法和类也改了：例子说的UpLoad实际上是DiskUpload,而当前的Upload有什么区别，为什么可以省去设置内存耗量的等部分，我找不到任何的解释。虽然对自已的代码有所偏爱，但由于我的代码不能处理多个file上载,虽然，这种情况实际上也很少，我却一直弄不明白有什么办法可以识别不止一个上载请求，这意味着我对RFC1864仍是欠了解的，既然有更可靠的东东，就不要太偏心自已的东西了，结果把用了几年的DoUploadBean彻底地埋葬了。
在选择是使用jsp还是servlet处理上载时，显然两者中servlet更规范一点，但在权限控制上颇为不便，因为，所以识别变量必须通过 request获取，这也意味着存在客户端伪造变量直接提交上载的可能性，确保正确识别意味着大量的代码。我最终决定采用自已发明的使用jsp标签取代 servlet的办法，（参看《可以使用多个jsp标签达到类似servlet效果》一文）。结果表明，这的确是兼有 jsp/servlet/javabean优点的好办法，特别是修改非常容易，我改个主意要以用户名称开目录，只是改了标签一个定义属性就搞妥了，这才真是易用性的体现。
最终的使用方法很简单：
<command:saveupload byform="false" noredirect="true" filename="theimg" roles="SECTION" dir="${filepath}" max="20000000"/>
这样，saveupload标签就会自动检测权限，并按科室中定义的管理组允许其中的成员上载，上载到科室下的upload目录中的用户名称建立的专用目录中，而存盘的文件名使用theimg名称供客户端嵌进正在编辑的文本中。
这样，上载就真正成为一个可以自由方便地使用的组件了。
