Ajax响应给出了一个损坏的COM pressed（.tgz的）文件 [英] AJAX response gives a corrupted compressed (.tgz) file

问题描述

我们正在实施一个客户端Web应用程序，通过XMLHtt prequests（和AJAX引擎）的服务器专用通信。

We are implementing a client-side web application that communicates with the server exclusively via XMLHttpRequests (and AJAX engine).

在XHR反应通常是纯文本的，但在这种情况下，服务器发送COM pressed在.tgz文件类型数据的一些XML。我们知道肯定是服务器发送数据是正确的，因为如果我们使用HTTP命令行客户端，如卷曲，将作为响应文件是有效的，并且包含预期的数据。

The XHR responses usually are plain text with some XML on it but in this case, the server is sending compressed data in .tgz file type. We know for sure that the data that the server is sending is correct because if we use an HTTP command-line client such as curl, the file sent as response is valid and contains the expected data.

然而，使AJAX调用和blobing在一个可下载的文件的响应时，我们得到的文件是大小（高于）正确的不同，它不是由DECOM presser识别。它提供了以下错误：

However, when making an AJAX call and "blobing" the response in a downloadable file, the file we obtain is different in size (higher) than the correct one and it is not recognized by the decompresser. It Gives the following error:

gzip: stdin: not in gzip format
/bin/gtar: Child returned status 1
/bin/gtar: Error is not recoverable: exiting now

在code我使用的是以下内容：

The code I'm using is the following:

*$.AJAX*.done(function(data){
    window.URL = window.webkitURL || window.URL;
    var contentType = 'application/x-compressed-tar';
    var file = new Blob([data], {type: contentType});
    var a = document.createElement('a'),
    ev = document.createEvent("MouseEvents");
    a.download = "browser_download2.tgz";
    a.href = window.URL.createObjectURL(file);
    ev.initMouseEvent("click", true, false, self, 0, 0, 0, 0, 0,
            false, false, false, false, 0, null);
    a.dispatchEvent(ev);
});

我可以避免用来制作AJAX调用，但是让我们假设，这不是问题，因为我没有得到答复的参数。我用这个的contentType，因为是由卷曲获得的显示相同的人，但我尝试了不同的人。在code可能看起来有点有点怪异，所以我会desglosse给你：我基本上创建一个链接，我连接到​​它的文件的下载链接和名称（这是一个肮脏的方式是能够命名该文件）。最后，我几乎点击链接。

I avoided the parameters used to make the AJAX call, but let's assume that this is not the problem as I correctly receive an answer. I used this contentType because is the same one displayed by the obtained by curl but I tried different ones. The code may look a little bit weird so I'll desglosse it for you: I'm basically creating a link and I'm attaching to it the download link and the name of the file (it's a dirty way to be able to name the file). Finally I'm virtually clicking the link.

我比较正确的TGZ文件并通过浏览器与一个十六进制观众获得一个和我观察到的已损坏的文件（EF，BF和BD，一直以来该文件）模式的重复不是present在正确的。

I compared the correct tgz file and the one obtained via browser with a hex viewer and I observed the repetition of patterns in the corrupted one (EF, BF and BD, all along the file) that is not present in the correct one.

因此​​，我认为一些可能的原因：

Therefore I think about some possible causes:

（一）浏览器添加额外字符或者响应   头仍然是下载的文件研究。

(a) The browser is adding extra characters or maybe the response header is still in the downloaded file.

（二）文件已被部分DECOM pressed，因为当我检查   请求头，我可以说出接受编码：gzip，紧缩;   虽然我不知道，如果浏览器（Firefox在我的情况）   自动DECOM presses数据。

(b) The file has been partially decompressed because when I inspect the request Header I can state "Accept-Encoding: gzip, deflate"; although I don't know if the browser (Firefox in my case) automatically decompresses data.

（三）我使用到BLOB数据的code是不正确的;虽然   它acomplished以及与另一个纯/文本文件的目的   场合。

(c) The code that I'm using to blob the data is not correct; although it acomplished well the aim with a plain/text file in another occasion.

修改

我还为你提供的十六进制检查链接：

I also provide you the links to the hex inspection:

（一）损坏的文件： http://en.webhex.net/view/278aac05820c34dfbdd2217c03970dd9/ 0 （二）（presumably）正确的文件： http://en.webhex.net/view/4a01894b814c17d2ec71ba49ac48e683

(a) Corrupted file: http://en.webhex.net/view/278aac05820c34dfbdd2217c03970dd9/0 (b) (Presumably) correct file: http://en.webhex.net/view/4a01894b814c17d2ec71ba49ac48e683

推荐答案

我不知道这是否线程会为别人有帮助的，但以防万一我想通了事业和我的问题可能的解决方案。

I don't know if this thread will be helpful for somebody, but just in case I figured out the cause and a possible solution for my problem.

的原因

在统一code / ASCII格式的默认JavaScript变量存储信息;他们不是ppared的正确存储二进制数据$ P $，这就是为什么人们可以很容易地看到错误的字符间preTED（这也解释了为什么EF，BF等的重复，在十六进制查看器，它代表观察的ASCII / UNI code错误的字符）。

Default Javascript variables store information in Unicode/ASCII format; they are not prepared for storing binary data correctly and this is why one can easily see wrong characters interpreted (this also explains why repetitions of EF, BF, etc. were observed in the Hex Viewer, which stand for wrong characters of ASCII/Unicode).

解决方案

最后一个版本的浏览器实现了所谓的类型数组。它们的JavaScript阵列可以存储在不同的格式的数据（也二进制）。然后，如果一个指定XMLHtt prequest响应是二进制格式，数据将被正确地存储，并且当blobed到一个文件，该文件将不被损坏。退房code我用：

The last browser versions implement the so called typed arrays. They are javascript arrays that can store data in different formats (also binary). Then, if one specifies that the XMLHttpRequest response is in binary format, data will be correctly stored and, when blobed into a file, the file will not be corrupted. Check out the code I used:

var xhr = new XMLHttpRequest();
xhr.open('POST', url, true);
xhr.responseType = 'arraybuffer';

请注意，关键是要界定responseType为arraybuffer。这可能是也是我决定不使用jQuery的AJAX了有趣的注意到。它实现了不良此功能，并尝试一切我做解析jQuery的都白费了（overrideMimeType描述的其他地方在我的情况下，没有工作）。相反，老平原XMLHttRquest工作pretty的很好。

Notice that the key point is to define the responseType as "arraybuffer". It may be also interesting noticing that I decided not to use Jquery for the AJAX anymore. It poorly implements this feature and all attempts I did to parse Jquery were in vain (overrideMimeType described somewhere else didn't work in my case). Instead, old plain XMLHttRquest worked pretty nicely.

这篇关于Ajax响应给出了一个损坏的COM pressed（.tgz的）文件的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！