如何通过 Web 服务返回文件

发布于 2024-08-02 10:13:03 字数 1708 浏览 9 评论 0原文

我正在开发一个 Web 服务,用户可以输入参数并可以选择以各种文件格式(xml、html(在屏幕上)、csv 等)返回数据。

如果服务器生成文件内容(因此没有实际文件),则不能选择返回该文件的 URL。那么如何才能做到这一点呢?我知道有 xml 属性来指示元素中的数据是二进制的,但这不会触发浏览器将数据下载为文件。

XML/Web 服务是否有某种与Content Disposition 相当的东西?

一个非常相关的说明:

Can javascript/AJAX trigger a browser to download a file?我知道 js 本身没有能力“生成”文件(从某种意义上说,浏览器将下载一个字符串作为具有给定文件名的文件”,但是如果 ajax 函数调用脚本并且脚本回复有什么情况呢?标题设置为下载吗?

我将尝试最后一部分,但想知道是否已经有任何可靠的信息。


更多详细信息:

首先,感谢所有回复的人。 我想

我可能会尝试更多地解释一下这种情况,以将涵盖答案的所有评论/疑虑/建议联系起来。

我管理一个内部员工网站的项目,该项目主要涉及日程安排查看。至少有 4 个不同的 PHP 脚本在 MySQL 数据库中查询基本相同的数据,在一种情况下,它会提取按任务分组的每日计划,在另一种情况下,它会查询一个数据。整周的日程安排和按人分组。在另一个例子中,它只查询一个人的每周日程安排。在某些情况下,它输出数据,例如每个人、每天或职位的每小时总计,而在其他情况下,它只提供数据库中存储的数据。

我开始对这个项目的某些方面感到内疚。显然,我可以将大量数据获取合并到一个包含的脚本中。我可能应该使用面向对象的 PHP 来处理结果。我更专注于解决这个混乱的问题,而不是确保数据安全可靠以及数据库的压力最小并得到优化。我什至不确定如何真正知道查询是否已优化。

除了上面提到的愧疚之外,我真的开始感到困惑了。在试图整理事情的过程中,我发现自己陷入了一个困境,一个修复程序把一些工作正常的东西搞砸了。

因此,我认为一个好的解决方案是创建一个 Web 服务,它可以简化整个过程,并迫使我有一个逻辑(甚至是 API)来获取数据,并且对于任何尝试获取数据的人来说会更有用。当我最终不再是首席开发人员时接手。另外,它将使整个事情变得更加便携,无论是升级还是站点后端的转变(有一天它可能会在使用 Cold Fusion 的 Windows 服务器上,但一想到这个我就感到不寒而栗)以及其他可能想要连接的软件与数据库。

但问题在于:

这个项目的整个起源是基于这样一个事实:我们之前的调度解决方案是上传由我们使用的非常昂贵的企业级调度软件生成的非常丑陋且无语义的 HTML 报告。对于这个丑陋的 HTML 报告以及生成该报告的软件,我们遇到的第一个问题是没有可以将 .ics“icalendar”文件导入 Outlook 或 Google 日历的选项。我的个人使命是找出一种方法将这些糟糕的报告转化为 ics 文件,从而开始讲述我为什么开始学习 PHP、正则表达式和 MySQL 的故事。

因此,如果您还没有感到无聊和睡着,我认为 Web 服务是简化计划流程的最佳选择,但如果我最终不得不使用纯 PHP/MySQL 来获取数据中最有价值的部分(日历文件)然后我倾向于放弃整个事情并继续解开结。

顺便说一句,我确实明白,使用 Web 服务的脚本可以创建 ics 文件,并且当用户请求时可以简单地避免 AJAX。再次感谢所有让我更清楚这一点的人。我只是希望 Web 服务能够尽可能地处理数据库返回的所有内容,以便在 HTML/JS/PHP 和数据库之间有清晰的划分。

再次感谢!

I am working on a Web Service where the user would input parameters and have the option of have the data returned in various file formats (xml, html (on screen), csv, etc.).

If the server generates the file content (and therefor there is no actual file), then returning a URL to the file is not an option. So how can this be done? I know there are xml attributes to indicate that the data within an element is binary, but that won't trigger the browser to download the data as a file.

Is there some equivalent of Content Disposition for XML/Web Services?

On a very related note:

Can javascript/AJAX trigger a browser to download a file? I know that js alone doesn't have the ability to "generate" files (in the sense that the browser will download a string as a file with a given file name" but what if an ajax function calls a script and the script reply has Headers set to download?

I'll experiment with that last part, but would like to know if there is any solid info already out there.


More Details:

First, thank you to everyone who has responded. All of the answers have been really helpful and educational.

I thought I might try to explain a bit more about the situation to tie up all of the comments/concerns/suggestions that span the answers.

I manage a project for an internal staff web site. The project deals mainly with schedule viewing and modification. There are at least 4 different PHP scripts which query a MySQL DB for essentially the same data. The queries vary slightly based on the context. In one case it pulls a daily schedule which groups by the assignment, in another it queries a full week's schedule and groups by person. In yet another it queries for just one person's weekly schedule. In some it outputs data like hourly totals per person or day or position, and in others it just gives what is stored in the DB.

I have started to feel guilty about certain aspects of the project. Obviously I can combine a lot of the data fetching into one included script. I probably ought to be using object-oriented PHP to handle the results. And I have been more focused on making this mess work than making sure the data is safe and secure and that the stress on the DB is minimal and optimized. I'm not even sure how to really know if the queries ARE optimized.

And in addition to the above mentioned guilt, I've really started to get confused. In trying to neaten things up, I've found myself tangled up in a knot where one fix screws up something that was working fine.

So, I thought a good solution would be to create a Web Service that would simplify the entire process and force me to have a logic (an API, even) to how the data is fetched, and would be more useful for anyone who tried to take over when I eventually am not the lead developer. Plus it would make the whole thing more portable, for both upgrades and shifts in the site's back-end (some day it might be on a Windows server using Cold Fusion but I shudder at the thought) and for other software that may want to connect with the database.

But here's the rub:

The entire genesis of this project was based on the fact that our previous scheduling solution was to upload the very ugly and non-semantic HTML report generated by the very expensive enterprise-level scheduling software we use. The number one problem we had with this hideous HTML report and the software that generated it was that there was no option for a .ics "icalendar" file that we could import into Outlook or Google Calendar. I made it my personal mission to figure out a way to turn those awful reports INTO ics files, and thus begins the story on why I started learning PHP, regex, and MySQL.

So, if you aren't bored and asleep yet, I think a Web Service is the best option for simplifying and streamlining the schedule process, but if I end up having to use plain PHP/MySQL to get the most valuable part of the data (the calendar files) then I'm inclined to just ditch the whole thing and keep untangling the knot.

I do understand, by the way, that the script that uses the Web Service can create the ics file and that the AJAX can simply be avoided when that is what the user is requesting. Again, thanks to all that have made this more clear to me. I just want the web service to handle everything returned by the DB as possible on its end to have a sense of a clear partition between the HTML/JS/PHP and the database.

Thanks again!

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(6

故事和酒 2024-08-09 10:13:03

要让浏览器下载文件,您可以执行以下操作:

window.location = "http://example.com/webservice-file-url";

并使用标题:

Content-Disposition: attachment; filename="filename.ext"

如果您希望用户在屏幕上查看和下载之间进行选择,只需使用条件:

if (requested_format == 'html') {
    //get an html version and show it on screen
    ajaxRequestForHTML();
} else {
    //download the file
    window.location = "http://example.com/webservice-file-url";
}

To have the browser download the file, you can do this:

window.location = "http://example.com/webservice-file-url";

And use the header:

Content-Disposition: attachment; filename="filename.ext"

If you want the user to choose between viewing on-screen and downloading, just use a conditional:

if (requested_format == 'html') {
    //get an html version and show it on screen
    ajaxRequestForHTML();
} else {
    //download the file
    window.location = "http://example.com/webservice-file-url";
}
左耳近心 2024-08-09 10:13:03

恐怕这行不通。 AJAX 调用不会将其响应标头传递给浏览器。如果更改标头,您唯一能做的就是 AJAX 调用可能会失败,因为标头将无法被识别。

我看到的唯一解决方案是返回文件的 URL 并打开新的 JS 窗口来触发下载。

I'm afraid that will not work. AJAX calls doesn't pass their response headers to the browser. The only thing you can if you change the headers is that your AJAX call may fail because the headers won't be recognized.

The only solution I see is to return a URL to a file and open new JS window that will trigger that download.

吲‖鸣 2024-08-09 10:13:03

从 Web 服务返回一个字节数组。如果您想将文件发送到服务,情况也是如此。

Return a byte array from the web service. The same if you want to send files to the service.

厌味 2024-08-09 10:13:03

在典型的浏览器环境中,JavaScript 无法(出于安全原因)访问剪贴板或文件系统。有关一些讨论,请参阅 clipboard-image-directly-save- in-to-client-side-using-javascript,或类似问题

但也有例外,例如 can-javascript-access-a-filesystem

In a typical browser environment, JavaScript cannot (for security reasons) access the clipboard or the filesystem. For some discussion see clipboard-image-directly-save-in-to-client-side-using-javascript, or similar questions.

There are exceptions, for example can-javascript-access-a-filesystem.

够钟 2024-08-09 10:13:03

Web 服务的要点是它们不应该由浏览器直接访问 - 它们是供其他 Web 应用程序使用的 API。因此,您可能应该编写一个用户友好的前端,它调用 Web 服务并将数据作为 HTTP 响应中的文件提供。这将触发浏览器将其下载为文件。

The point of Web Services is that they are not meant to be accessed directly by a browser - they are an API for other web applications to use. Thus you should probably write a user-friendly front-end which calls the web service and serves up the data as a file within a HTTP response. That will trigger the browser to download it as a file.

缺⑴份安定 2024-08-09 10:13:03

您确定要将此作为一项网络服务吗?一个带有参数表单字段的普通网页怎么样,它只是将数据作为文件返回,并具有适当的内容配置?


根据您的更新,我非常确定您不希望 Web 服务返回 .ics 文件。您想要的是一个脚本,该脚本将使用查询字符串接受一些参数,然后使用“附件”内容配置返回文件。这将导致提示用户打开 .ics 文件。

现在,您还有一个好主意,重构几个类似的脚本以减少冗余和维护。然而,我很担心你所说的每一个改变都会破坏一些东西。在开始重构之前,您需要至少为自己构建一个小型测试套件,最好是自动化的。这样,您就可以在每次小的更改后运行测试,看看是否破坏了任何内容。这样,当你破坏某些东西时,你只能破坏一个小时的价值。

我建议使用包含的脚本或 PHP 具有的任何重用机制(我不了解 PHP)来重构 PHP 脚本。然后您可能会发现一些通用代码可以适当地实现为 Web 服务。

Are you sure you want this to be a web service? How about a normal web page, with form fields for the parameters, which just returns the data as a file, with the appropriate content-disposition?


Based on your update, I'm pretty certain that you do not want a web service to return the .ics file. What you want is a script that will accept some parameters using the query string, and which will then return the file, using the "Attachment" content-disposition. This will cause the user to be prompted to open the .ics file.

Now, you also have the great idea to refactor your several similar scripts to reduce redundancy and maintenance. However, I'm concerned about what you said about every change breaking something. Before you start refactoring, you need to build yourself at least a small test suite, preferably automated. That way, you'd run the tests after every small change, to see if you'd broken anything yet. This way, when you break something, you can only have broken an hour's worth.

I would recommend refactoring the PHP scripts using included scripts or whatever mechanisms PHP has for reuse (I don't know PHP). You may then find that some of the common code would be appropriately implemented as a web service.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文