這幾天的工作主要圍繞著文件（主要是圖片）上載，並可以在線和HTML編輯器集成，操作簡便與目前引用網上圖片相似。我是有點小看了這件事情，不過也不無道理：一來以前使用servlet完成過，其中的核心DoUpLoadBean也的確是可以工作；其次集成到編輯器則在使用php的本人的私人博客上做過，看不出有什麼特別難的地方。但實際上在展開後就發現，簡單實現上載是容易的，但要合理地安排上載的策略，就不得不小心翼翼。因為允許上載本身是非常需要危險的，這實際上是開了一個口子；允許客戶對服務器進行事實上的操作，上載攻擊從來就不是一件困難，更不是一件罕見的事情；可以想見一旦系統開通，這類攻擊必然就會發生。
另一方面，在允許用戶上載本地文件同時就必須考慮後期的管理，因為，即使是在用戶本地，最大的硬盤也會過不多久就會給說不清是什麼東西的垃圾占滿；何況現在是允許許多人同時使用的服務器，如果沒有精確的策略，花不了多長時間，客戶的上載文件就會把系統撐爆。就在上一個星期，一位朋友向我求助，說是他們的數據庫達到30G，把硬盤吃光了，結果死了機；對此，本人只能是愛莫能助，因為，可以肯定裡面絕大部分是垃圾，卻搞不清什麼是垃圾，什麼是必須的。因為，他們缺乏一個策略。而且，就算用戶不是惡意的，大部分情況下，在開通開載的時侯，很快硬盤也會撐滿，如果這是系統盤，通常就意味著崩潰，可見，必須使用連接把上載限制到另一個專用的分區，以確保安全。通常鐵quota在這裡是派不上用場的，因為那需要把WEB帳號與操作系統帳號結合，既復雜又危險，更加沒有這個必要。同時，上載的文件如果不是給每個用戶分配目錄，也應該是在每個用戶的名稱前增加一個前綴，以供識別；這樣，萬一需要清理，配合文件日期，可以使用find/grep/rm組合腳本進行備份或清除，至少是有可能的。
還有其他因素，導致上載文件實際操作比簡單接愛一個文件上載的程序量要大得多；其中主要包括權限控制，（考慮到可以用上載進行攻擊，這條不得不小心點），文件管理，以及修改屬性，包括大小，類型限制，可以方便修改存儲的方式等等，事實上，就完成情況下，上載部分只花了五行程序，而管理則不小於50行。
今天已經不必再自已寫輸入流了，就算自已沒有積累，還是可以從網上找到開源的代碼，象jakarta commons upload就是一個。這個東西沒有什麼例子，所找到的例子大部分是跑不動的，倒不是怪程序員自已，而是這個東西不但沒有什麼文檔，還把方法和類也改了：例子說的UpLoad實際上是DiskUpload,而當前的Upload有什麼區別，為什麼可以省去設置內存耗量的等部分，我找不到任何的解釋。雖然對自已的代碼有所偏愛，但由於我的代碼不能處理多個file上載,雖然，這種情況實際上也很少，我卻一直弄不明白有什麼辦法可以識別不止一個上載請求，這意味著我對RFC1864仍是欠了解的，既然有更可靠的東東，就不要太偏心自已的東西了，結果把用了幾年的DoUploadBean徹底地埋葬了。
