背景
我们的软件以通常的可疑格式（HTML，PDF等）为客户生成报告，每个报告可以包含该报告特有的图表和其他图形。对于PDF，everthing保存在一个地方 - PDF文件本身。 HTML很棘手，因为报告基本上是多个文件的总和。这些文件可以通过Tomcat通过HTTP获得。
问题：
我真的想拥有一个整洁的环境并将HTML报告包装到一个文件中。有MTHML，数据URI，需要考虑的几种格式。 This excellent question认为，由于缺乏对这些格式的交叉支持，ZIP是一个简洁的解决方案。这对我很有吸引力，因为我也可以提供下载的zip作为“你可以发送电子邮件的HTML报告”选项。 （在过去，用户抱怨在设置电子邮件HTML报告时丢失图形）
解决方案似乎很简单。一个请求进来，我找到了相应的zip，在Web服务器的某处解压缩，将请求指向新的HTML文件，并在一天左右后再整理一切。
但有些事情似乎并不正确。我有点直觉觉得它不是一个好的解决方案，它有一些内在的错误，或者可能是一种我目前看不到的更好的方法。
有人可以建议这是好还是坏，并提供替代解决方案？
修改以获取更多背景信息！
报告需要在服务器上保留。我们的客户是站点上的用户，单个报告的可见性可以与站点中的每个人一样广泛。创建过程涉及用户选择报告的标准，并将其提交给服务器进行创建。从数据库中提取数据并构建文档。占位符记录进入数据库，文档本身存储在某个文件服务器上。这是'文件服务器'部分的文档，我想更整洁 - 压缩也意味着使用更少的磁盘空间！创建报告后，任何可以查看报告的人都可以使用该报告。
答案 0 :(得分：1)
我原以为计划是zip文件最终会出现在客户端而不是停留在服务器上。
如果不了解您的架构，我会猜测这样的方法：
当然，这依赖于能够重新运行报告以生成zip文件。每次生成一些HTML时，都可以生成一个zip文件，但如果你不需要这样做，并且需要清理等，那就太浪费了。
也许我误会了你...如果这听起来不合适，你能否更新你的问题？
编辑：好的，看到你的问题的更新，我很想将每个报告的文件存储在一个单独的目录中（例如使用GUID作为目录名）。许多文件系统支持文件系统级别的压缩，因此“过早压缩”可能不会节省太多磁盘空间，并且会使得提取单个文件更加困难。然后，如果用户请求一个zip，你只需要在服务它之前构建zip文件，可能只是在内存中。答案 1 :(得分：1)
创建报告后，确实如此 任何能够看到它的人都可以使用。
这很有说服力 - 这意味着报告是可共享的，并且您还希望“缓存”报告，以便不必重新生成报告。
这样做的一种方法是找出一种将参数散列在一起的方法，使得不同的参数组合（导致不同的报告）散列到不同的值。那么，你可以使用那些哈希作为密钥进入zip中存储在磁盘中的大型缓存报告（可能是文件的名称是哈希？）
这样，每当有人请求报告时，您都会对参数进行哈希处理，并检查该报告是否已生成，并以zip下载的方式提供，或者，您可以将其解压缩，然后提供html按照正常情况。如果报告不存在，生成它并压缩它，请确保以后能够通过这些参数生成它（即记录哈希值）。
要注意的一件事是文件系统写入往往是非原子的，所以如果你不小心，你会重新生成报告两次，这很糟糕，但幸运的是你的情况，而不是太< / em>有害。要避免，您可以使用单个线程来执行此操作（较慢），或实现某种锁定。
答案 2 :(得分：0)
您不需要在文件系统上物理创建zip文件。在内存中创建拉链没有任何问题，将其流式传输到浏览器并让GC负责释放临时zip所占用的内存。这当然会引入问题，因为每次发出请求时连续重新创建zip都可能是无效的。然而，根据您的需要判断这些事情等等。