0

背景：
我们的软件以常见的可疑格式（HTML、PDF 等）为客户生成报告，每个报告都可以包含该报告独有的图表和其他图形。对于 PDF，一切都保存在一个地方 - PDF 文件本身。HTML 比较棘手，因为报告基本上是超过 1 个文件的总和。这些文件可通过 Tomcat 通过 HTTP 获得。

问题：
我真的很想有一个整洁的环境并将 HTML 报告包装到一个文件中。有 MTHML、数据 URI 和几种格式需要考虑。这个很好的问题表明，由于缺乏对这些格式的跨浏览器支持，ZIP 是一个很好的解决方案。这对我很有吸引力，因为我还可以将 zip 作为“您可以通过电子邮件发送的 HTML 报告”选项提供下载。（过去，用户抱怨在他们开始通过电子邮件发送 HTML 报告时丢失了图形）

解决方案似乎很简单。一个请求进来了，我找到合适的 zip，在网络服务器的某个地方解压它，将请求指向新的 HTML 文件，大约一天后再次整理一切。

但有些事情似乎不太对劲。我有一种直觉，这不是一个好的解决方案，它有一些根本性的问题，或者可能存在我目前看不到的更好的方法。

任何人都可以建议这是好还是坏，并提供替代解决方案？

编辑以获取更多背景信息！
报告需要保留在服务器上。我们的客户是站点的用户，单个报告的可见性可能与站点中的每个人一样广泛。创建过程涉及用户选择报告的标准，并将其提交到服务器以进行创建。从数据库中提取数据并构建文档。占位符记录进入数据库，文档本身存储在文件服务器的某个地方。我希望更整洁的是“文件服务器上的文档”部分 - 压缩也意味着使用的磁盘空间更少！。创建报告后，任何可以看到它的人都可以使用它。

4

3 回答 3

1

我原以为计划是 zip 文件最终在客户端上，而不是留在服务器上。

在不了解您的架构的情况下，我猜想采用这样的方法：

  • 用户请求报告
  • 服务器将报告显示为 HTML
  • 用户可能会调整一些参数，重复请求
  • 服务器将报告显示为 HTML（重复直到用户满意）
  • 在每个 HTML 报告中，都有一个“以 zip 格式下载”链接
  • 用户点击链接
  • 服务器重新生成报告，将其存储在 zip 文件中并提供给用户
  • 用户将 zip 文件保存在某处，通过电子邮件发送等 - 根本不涉及服务器

当然，这依赖于能够重新运行报告以生成 zip 文件。每次生成一些 HTML 时，您都可以生成一个 zip 文件，但如果您不需要这样做，那就太浪费了，并且需要清理等。

也许我误解了你……如果这听起来不合适，你能更新你的问题吗？

编辑：好的，看到您的问题的更新后，我很想将每个报告的文件存储在单独的目录中（例如，使用 GUID 作为目录名称）。许多文件系统支持文件系统级别的压缩，因此“过早压缩”可能不会节省太多磁盘空间，并且会使提取单个文件变得更加困难。然后，如果用户请求 zip，您只需要在那个时候构建 zip 文件，可能只是在内存中，然后再提供它。

于 2009-03-02T07:21:00.523 回答
1

创建报告后，任何可以看到它的人都可以使用它。

这很能说明问题 - 这意味着报告是可共享的，并且您还希望“缓存”报告以便不必重新生成。

做到这一点的一种方法是找出一种将参数散列在一起的方法，这样不同的参数组合（导致不同的报告）散列到不同的值。然后，您可以使用这些散列作为密钥，以 zip 格式存储在磁盘中的大量报告缓存中（可能文件名是散列？）

这样，每次有人请求报告时，您都会对参数进行哈希处理，并检查该报告是否已经生成，然后以 zip 下载的形式提供，或者您可以将其解压缩并按照正常方式提供 html . 如果报告不存在，生成它并压缩它，确保以后能够识别它是由这些参数生成的（即，记录散列）。

需要注意的一件事是文件系统写入往往是非原子的，所以如果你不小心，你会重新生成报告两次，这很糟糕，但幸运的是，在你的情况下，并没有太大的危害。为避免，您可以使用单个线程来执行此操作（较慢），或实施某种锁定。

于 2009-03-02T10:10:00.007 回答
0

您不需要在文件系统上物理创建 zip 文件。在内存中创建 zips 并没有错，将其流式传输到浏览器并让 GC 负责释放临时 zip 占用的内存。这当然会引入问题，因为每次发出请求时不断地重新创建 zip 可能效率低下。但是根据您的需要等来判断这些事情。

于 2009-03-02T07:37:53.617 回答